Les méthodes ''agiles'' de management de projets

HAL Id: pastel-00683828https://pastel.archives-ouvertes.fr/pastel-00683828

Submitted on 30 Mar 2012

HAL is a multi-disciplinary open accessarchive for the deposit and dissemination of sci-entific research documents, whether they are pub-lished or not. The documents may come fromteaching and research institutions in France orabroad, or from public or private research centers.

L’archive ouverte pluridisciplinaire HAL, estdestinée au dépôt et à la diffusion de documentsscientifiques de niveau recherche, publiés ou non,émanant des établissements d’enseignement et derecherche français ou étrangers, des laboratoirespublics ou privés.

Les méthodes ”agiles” de management de projetsinformatiques : une analyse ”par la pratique”

Carine Khalil

To cite this version:Carine Khalil. Les méthodes ”agiles” de management de projets informatiques : une analyse ”par lapratique”. Gestion et management. Télécom ParisTech, 2011. Français. �pastel-00683828�

https://pastel.archives-ouvertes.fr/pastel-00683828

https://hal.archives-ouvertes.fr

N°: 2009 ENAM XXXX

Télécom ParisTech Grande école de l’Institut Télécom – membre fondateur de ParisTech

46, rue Barrault – 75634 Paris Cedex 13 – Tél. + 33 (0)1 45 81 77 77 – www.telecom-paristech.fr

TT

HHEE

SS

EE

présentée et soutenue publiquement par

Carine KHALIL

06 Décembre 2011

Les méthodes « agiles » de management de projets informatiques : une analyse « par la pratique »

Directeur de thèse : Valérie FERNANDEZ Co-encadrement de la thèse : Jérôme DENIS

T

H

È

S

E

Jury Mme Bénédicte GEFFROY, Professeur, Sciences de Gestion, École des Mines de Nantes Rapporteur M. Marc BIDAN, Professeur, Sciences de Gestion, Université de Nantes Rapporteur Mme Carine DOMINGUEZ-PERY, Professeur, Sciences de Gestion, Université Pierre Mendes France Examinatrice M. Jérôme DENIS, Maître de conférences, Sociologie, Télécom ParisTech, LTCI Co-directeur Mme Valérie FERNANDEZ, Professeur, Sciences de Gestion, Télécom ParisTech, LTCI Directrice.

Doctorat ParisTech

T H È S E

pour obtenir le grade de docteur délivré par

Télécom ParisTech Spécialité “ Sciences de Gestion ”

Les méthodes « agiles » de management de projets informatiques : une analyse « par la pratique »

RÉSUMÉ :

Jusqu’à la fin des années 90, les approches dominantes de développement de projets informatiques étaient basées sur la planification et le découpage extensifs du projet en lots séquentiels. Face aux besoins d’adaptabilité et de réactivité imposés par un marché technologique de plus en plus concurrentiel, les méthodes « classiques » ont été remises en cause par de nouvelles méthodes qualifiées d’« agile ». Ces dernières sont généralement décrites comme étant itératives, incrémentales, encourageant l’auto-organisation et s’adaptant au changement. La philosophie des méthodes « agiles » s’inscrit dans l’école japonaise du « lean » développé dans les années 1980. Elle pose de façon centrale la question du sens collectif, et ce dans une perspective interactionniste (Koenig, 2003) où la création de sens se fait de manière processuelle par l’intermédiaire de la communication entre les intervenants. Participant d’une philosophie d’organizing (Weick, 1995), les méthodes agiles ont souvent été analysées dans des configurations organisationnelles « simples » où des modes de coordination de type « adhocratique » (Mintzberg, 1984) peuvent facilement être mis en place. Qu’en est-il pour des structures de management de projet plus complexes ? Plus généralement, comment ce type « d’innovation managériale » peut-il être mis en œuvre dans une démarche structurée de management pour constituer un dispositif formalisé favorisant l’organizing ?

Les méthodes « 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 qu’elles sous-tendent, soit, de leur contextualisation interne (David, 1996). L’objet de cette thèse de doctorat est d’aborder ces questions en articulant une analyse critique de la littérature consacrée aux méthodes agiles, et une étude de cas instrumentale menée dans la perspective de l’approche « par la pratique » (Gherardi, 2000, 2001 ; Whittington, 2003 ; Antonacopoulou, 2006 ; Jarzabkowski, 2004), d’une durée de 17 mois, réalisée dans une entité appartenant à un large groupe français de télécommunication ayant décidé de mettre en œuvre une démarche managériale basée sur des pratiques « agiles ».

Nos résultats permettent d’envisager la démarche « agile » comme un « construit social » continu, guidé non pas par l’application mécanique de méthodes stabilisées, mais par des problématiques de plausibilité, d’identité organisationnelle et par les présuppositions avancées par des acteurs « énactant » leur réalité organisationnelle. Nous montrons qu’en construisant le sens des méthodes qu’ils cherchent à mettre en place, les acteurs identifient non seulement des dysfonctionnements spécifiques à la démarche (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 explorées de la mise en œuvre des méthodes « agiles ».

Mots clés : Méthodes Agiles, Innovations Managériales, Management de Projet, Structure Matricielle, Sensemaking.

Télécom ParisTech n’entend donner aucune approbation ni improbation aux opinions émises dans cette thèse. Ces

opinions doivent être considérées comme propres à

l’auteur.

A ceux qui ont rendu cette thèse possible

RReemmeerrcciieemmeennttss

J’exprime ma gratitude et ma considération les plus sincères à toutes les personnes qui

m’ont de près ou de loin, aidée et soutenue durant la réalisation de ce travail et sans qui, il

n’aurait pas vu le jour. Mes remerciements s’adressent particulièrement à :

Valérie Fernandez, professeur à Télécom ParisTech, ma directrice de thèse. Je tiens à la

remercier, de m’avoir donné la chance de compter parmi ses doctorants. Je lui suis

reconnaissante pour la confiance et le temps qu’elle m’a accordés, pour ses directives, ses

encouragements et pour son soutien le long de cette aventure.

Jérôme Denis, maître de conférences en sociologie à Télécom ParisTech, mon co-directeur de

thèse. Je souhaite lui exprimer ma gratitude et le remercier pour sa grande disponibilité et ses

conseils stimulants tout au long de ces trois années.

Les membres du Jury d’avoir accepté d’évaluer ce travail de thèse. J’en suis très honorée. Mes

premiers remerciements iront à Madame Bénédicte Geffroy et Monsieur Marc Bidan, les

rapporteurs de ce travail de thèse. Je remercie également Madame Carine Dominguez-Pery

d’avoir accepté d’examiner ce travail.

Thomas Houy, maître de conférences à Télécom ParisTech, qui a contribué par ses

nombreuses remarques et suggestions à améliorer la qualité de ce travail de thèse. Je lui en

suis très reconnaissante.

M. Thierry Fraize, responsable qualité à la direction Nextv chez Orange. Je souhaite le

remercier de m’avoir accueillie au sein de son équipe et d’avoir répondu à toutes mes

questions.

7

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

professeur Albert David pour ses précieux conseils. Je tiens à le remercier également d’avoir

évalué mon travail mi-parcours.

Je remercie chaudement ma chère famille qui m’a soutenue depuis mon arrivée en France et

qui m’a permis de faire cette thèse dans des bonnes conditions. Aujourd'hui je lui offre ce

travail.

Je remercie mes amis et en particulier Amélie Mauler, ma colocataire, pour son soutien et sa

patience à mon égard.

8

TTaabbllee ddeess mmaattiièèrreess

Table des matières --------------------------------------------------------------------------------------------- 8 Liste des figures ---------------------------------------------------------------------------------------------- 10

Liste des tableaux -------------------------------------------------------------------------------------------- 11

Introduction générale --------------------------------------------------------------------------------------- 12

Première partie : De la question des méthodes « agiles » comme « innovations managériales » 20

Chapitre I : Présentation des méthodes « agiles » : principes et instruments de gestion ---------- 21

1. Des méthodes classiques de management de projet aux méthodes « agiles » ---------------------- 22

1.1 Les méthodes « classiques » : une démarche « lourde » de conduite de projet --------------- 22 1.2 Les méthodes « agiles » : une nouvelle tendance managériale -------------------------------- 24 1.3 Les sources d’inspiration des méthodes « agiles » ---------------------------------------------- 28

2. Présentation des méthodes « agiles » ------------------------------------------------------------------ 35 2.1 La méthode « scrum » ----------------------------------------------------------------------------- 36 2.2 La méthode « Extreme Programming » ---------------------------------------------------------- 41

2.3 Le lean développement ---------------------------------------------------------------------------- 48 2.4 « Scrum », « xp » et le développement « lean » : différences et complémentarité ----------- 58

Chapitre II : Analyse de la mise en pratique des « innovations managériales »-------------------- 63

1. Les pratiques « agiles » les plus référencées : avantages et limites --------------------------------- 64

1.1 Les pratiques d’ingénierie ------------------------------------------------------------------------- 65 1.2 Les pratiques de collaboration et de coordination----------------------------------------------- 66 1.3 Les outils de support au management ------------------------------------------------------------ 70

2. Les méthodes « agiles » v/s méthodes « classiques » : quelles méthodes privilégier ? ------------ 71 3. L’application des pratiques « agiles » dans un environnement géodistribué ----------------------- 75

3.1 Les principaux défis du développement « agile » distribué ------------------------------------ 76

3.2 Les recommandations des praticiens face aux défis remontés --------------------------------- 78 3.3 Regard complémentaires des experts sur le développement « agile » globalisé-------------- 82

Chapitre III : Stratégie de recherche : une approche « par la pratique » --------------------------- 86

1. La « fabrique de la stratégie » : champ de recherche émergent en sciences sociales -------------- 91

1.1 Le strategizing : à l’intersection des pratiques, praxis et praticiens :-------------------------- 92 1.2 Qui sont les stratégistes et que font-ils ? --------------------------------------------------------- 94

2. Le modèle du sensemaking ----------------------------------------------------------------------------- 97 2.1 Les propriétés du sensemaking ------------------------------------------------------------------ 101

2.2 L’organisation appréhendée comme un processus d’organizing ----------------------------- 103

9

Deuxième partie : De la fabrique d'une « innovation managériale » : la construction d'une

démarche « agile » ------------------------------------------------------------------------------------------ 107

Chapitre IV : Conduire une approche « par la pratique » ------------------------------------------- 108

1. Présentation « à plat » du cas d’entreprise étudié ---------------------------------------------------- 109

1.1 Description du contexte d’étude ----------------------------------------------------------------- 109 1.2 Mise en place de la démarche « lean » ---------------------------------------------------------- 115

2. Démarche d’investigation ------------------------------------------------------------------------------ 119 2.1 Choix d’une étude longitudinale----------------------------------------------------------------- 119 2.2 Procédés de collecte de données ----------------------------------------------------------------- 120

2.3 Choix d’une méthode d’analyse thématique---------------------------------------------------- 127 2.4 Triangulation des données et des chercheurs --------------------------------------------------- 133

Chapitre V : Variables de création de sens ------------------------------------------------------------- 136

1. Le gaspillage dans les projets pilotés par Nextv ----------------------------------------------------- 137

1.1 Analyse et classification des dysfonctionnements par type de gaspillage ------------------- 138 1.2 Démarche plausible de résolution des dysfonctionnements ----------------------------------- 146

2. Facteurs d’influence de la démarche « 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 mobilisées ------------------------------------------------------------------------ 159 2.5 Les parties prenantes du projet « lean »--------------------------------------------------------- 162

Chapitre VI : Discussion ----------------------------------------------------------------------------------- 169

Conclusion générale ---------------------------------------------------------------------------------------- 189

1. Résumé des principaux résultats de recherche ------------------------------------------------------- 189 2. Les apports de ce travail de recherche ---------------------------------------------------------------- 197 3. Limites et pistes futures -------------------------------------------------------------------------------- 198

Bibliographie ------------------------------------------------------------------------------------------------ 201

Annexes ------------------------------------------------------------------------------------------------------- 215

10

LLiissttee ddeess ffiigguurreess

Figure I: Processus de développement « scrum » ........................................................................ 41

Figure II : Processus de développement « XP » ............................................................................. 48

Figure III: « Jonglage » entre trois taches de délai d'une semaine chacune ................................... 57

Figure IV: Parties constitutives de la « fabrique » de la stratégie ................................................... 94

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

Figure VI : Grille d’analyse du sensemaking.................................................................................. 105

Figure VII : Structure macro-organisationnelle de l’entité Nextv ................................................... 110

Figure VIII : Cycle de vie des projets à DPS ..................................................................................... 111

Figure IX : Structure de type « lightweight » ................................................................................ 114

Figure X : Déroulement du projet « lean » .................................................................................. 119

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

11

LLiissttee ddeess ttaabblleeaauuxx

Tableau 1: Comparaison des concepts de l'agile manufacturing v/s méthodes « agiles » ............... 31

Tableau 2: Les pratiques « XP » ..................................................................................................... 42

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

Tableau 4 : Différences entre « XP » et « scrum » ........................................................................... 58

Tableau 5: Éléments structurant des approches : « scrum », « xp » et « lean » .............................. 61

Tableau 6 : Défis majeurs du développement « agile » dans un environnement globalisé .............. 78

Tableau 7 : Recommandations face aux défis rencontrés dans un environnement globalisé ........... 81

Tableau 8 : Les études basées sur la « pratique » ........................................................................... 91

Tableau 9: Intervention des acteurs métiers dans le cycle de vie du projet .................................. 113

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

Tableau 11: Principes et pratiques adoptés ................................................................................... 116

Tableau 12: Projets pilotes retenus ............................................................................................... 117

Tableau 13: Plans d'actions validés par le Codir ............................................................................. 118

Tableau 14 : Tableau descriptif des réunions réalisées .................................................................... 122

Tableau 15 : Ateliers organisés par l’équipe «lean »........................................................................ 124

Tableau 16 : Recension des entretiens réalisés ............................................................................... 125

Tableau 17: Les causes de la surproduction ................................................................................... 139

Tableau 18: Les causes des temps d’attente .................................................................................. 140

Tableau 19: Les causes des transports inutiles............................................................................... 141

Tableau 20: Les causes du travail supplémentaire ......................................................................... 142

Tableau 21: Les causes de l’inventaire ........................................................................................... 143

Tableau 22: Les causes des mouvements inutiles .......................................................................... 144

Tableau 23: Les causes des défauts ............................................................................................... 145

Tableau 24 : PDCA mobilisé par l’équipe « lean » ........................................................................... 149

Introduction générale

12

IInnttrroodduuccttiioonn ggéénnéérraallee

Nombre de modèles1 de développement de logiciels et de standards de management de

projets a été élaboré au cours de ces quatre dernières décennies. De sérieux problèmes de

qualité et de productivité ont été rencontrés par les sociétés informatiques les amenant au fil

du temps à repenser leurs modes de développement et de gestion de projets informatiques2.

Jusqu’à la fin des années 1990, les méthodes3 dominantes en développement de logiciels

étaient celles basées sur le découpage en lots séquentiels. À chaque phase, correspond un

ensemble d’activités ou de tâches à réaliser et à piloter, ainsi que des décisions à prendre. Le

livrable est produit à la fin du processus. Ce processus de développement a été symbolisé par

la course de relais où les différents services fonctionnels se relaient tour à tour (Takeushi &

Nonaka, 1986 ; Midler, 1993b). L’approche la plus représentative de ce type de

développement est le modèle de la « cascade ». Universellement connu et utilisé, il se base sur

l’anticipation des demandes des clients, la définition complète du produit et la documentation

exhaustive. Toutefois, depuis quelques années, les principes de découpages linéaires et de

management de projets informatiques portés par les méthodes « classiques » sont de plus en

plus remis en cause. Les sociétés informatiques se trouvent aujourd’hui confrontées à de

fortes pression et concurrence sur un marché caractérisé par une diversité des offres

technologiques, une instabilité des demandes et une réduction des délais de mise sur le

marché. Le changement permanent des fonctionnalités à développer et l’effet « tunnel » causé

1Nous désignons par modèle de développement le découpage d’un projet ou le modèle de cycle de vie d’un

projet. 2Un système informatique est un « ensemble organisé d’objets techniques-matériels, logiciels, applications- dont

la mise en œuvre réalise l’infrastructure d’un système d’information » (Morley, 2006, p. 15). Dans cette thèse,

nous traitons des projets de développement de systèmes informatiques. 3Pour définir le terme « méthode » nous nous référons à la définition du Larousse : « un ensemble ordonné de

manière logique de principes, de règles, d'étapes, qui constitue un moyen pour parvenir à un résultat ».


13

par les projets en « cascade » ont amené les praticiens à remettre en question ce modèle de

développement et à se focaliser sur les évolutions rapides et constantes du marché

technologique. Comme la planification et l’organisation ex ante du processus de

développement s’avèrent, de nos jours, difficiles à réaliser, de nouvelles approches, plus

« flexibles », dénommées « agiles4 », ont été développées ; elles se sont progressivement

diffusées au niveau des industries de logiciels.

A quoi le terme « agilité » renvoie-t-il précisément ? A quelle(s) forme(s) d’agilité ? Sur quels

principes gestionnaires les méthodes « agiles » de développement et de management de projet

se basent-elles ? Comment sont-elles appliquées au sein des industries de logiciels ? Existe-t-

il un référentiel permettant de structurer la conduite d’un projet « agile » ?

En très peu d’années, la notion d’« agilité » a connu un succès considérable au niveau des

industries de développement de logiciels. Comme en témoignent les multiples colloques et

publications consacrés à cette thématique, de nombreuses sociétés informatiques aspirent

aujourd’hui à rompre avec les méthodes « classiques » et à devenir « agile ». Une enquête

internationale5, menée en 2008 auprès de 642 professionnels du développement d’applications

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 méthodes « agiles ».

Ces méthodes sont généralement décrites comme étant itératives, incrémentales, encourageant

l’auto-organisation et s’adaptant au changement. Contrairement aux approches « classiques »,

elles n’exigent qu’un formalisme « léger » et renvoient à une représentation « souple » des

pratiques de développement et de management favorisant le « bricolage » et l’ajustement

continu au contexte des projets.

En effet, ces formes innovantes de développement de logiciels reposent sur un ensemble de

pratiques d’ingénierie et de gestion de projet bien définies ainsi que sur une philosophie

gestionnaire qui visent, d’une part, à améliorer l’adaptabilité et la réactivité des équipes de

développement et d’autre part, à réduire, voire à éliminer les divers types de gaspillages (les

4Littéralement, le terme « agile » implique « l’habilité à bouger de façon légère et gracieuse et de s’adapter

rapidement » (http://www.merriam-webster.com/). Nous reviendrons sur cette notion, de façon plus détaillée,

dans le chapitre (I) de cette thèse. 5http://www.ambysoft.com/surveys/agileFebruary2008.html.

http://www.merriam-webster.com/


14

fonctionnalités inutiles, les anomalies tardivement identifiées, le « retravail », les temps

d’attente, dus au chevauchement entre les phases d’un projet, etc.) souvent rencontrés dans les

projets informatiques. Comme nous le verrons dans le cadre de cette thèse6, cette notion de

gaspillage se trouve au cœur des préoccupations des « agilistes » et en particulier des

partisans de l’approche lean7.

Malgré la littérature foisonnante sur le concept d’agilité, la transition vers une organisation

« agile » constitue un réel défi. A l’heure actuelle, le contexte d’utilisation des outils

« agiles » demeure flou. L’analyse de la littérature parue sur le sujet souligne des positions

contradictoires des praticiens vis-à-vis de l’applicabilité des pratiques et instruments de

gestion portés par ces approches de développement et de management de projet. Les

méthodes « agiles » articulent de nouveaux concepts et dispositifs managériaux sans

participer toutefois d’un modèle unifié de gestion. Elles ne semblent pas s’appuyer sur une

démarche structurée 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 gestionnaire9 qu’elles sous-tendent soit, de leur contextualisation10 interne (David,

1996).

Le caractère « souple » des outils « agiles » leur confère la capacité de s’adapter facilement

aux modes de fonctionnement des équipes, essentiellement, de taille réduite (moins de 10

personnes). En effet, ces méthodes renvoient implicitement à des configurations

6(Chapitre I, section 2) 7Littéralement, lean signifie « mince ». A l’heure actuelle, il n’existe pas de consensus qui différencie

clairement, en développement informatique, l’approche lean des méthodes « agiles ». D’aucuns confondent ces

deux concepts, d’autres considèrent que le lean renvoie à un ensemble de principes concernant l’organisation au

sens global du terme dépassant ainsi les activités de développement. Pour cette raison, nous avons décidé

d’aborder, tout au long de cette thèse, l’agilité comme un concept « parapluie » regroupant les principes et les

pratiques issus des méthodes « agiles » et de l’approche lean. Nous reviendrons sur la distinction entre ces deux notions à la fin du chapitre (I). 8Le substrat technique est « l’abstraction qui permet à un outil de gestion de fonctionner » (David, 1996, p.7). Il

s’agit de la dimension concrète de l’innovation (les réunions de planification de l’itération, le plan de l’itération,

le tableau blanc, les post-it, les tests unitaires, etc.). 9Une philosophie managériale correspond à la signification gestionnaire de l’innovation managériale, à ses

aspects logiques et rationnels (la conformité du produit par rapport aux demandes des clients, la création d’un

environnement collaboratif, la réduction de la complexité du système, etc.). 10Par contextualisation, l’auteur entend « un état ou un processus particulier de transformation réciproque de

l'innovation par les acteurs et des acteurs par l'innovation. Le degré de contextualisation interne peut être défini

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).


15

organisationnelles « simples » où des modes de coordination de type « adhocratique »

(Mintzberg, 1984) peuvent facilement être mis en place. Elles semblent participer d’une

philosophie d’organizing où les acteurs sont impliqués dans des processus d’ajustement,

d’expérimentation, d’apprentissage et d’amélioration continus. L’instabilité de

l’environnement pousse les équipes « agiles » à s’interroger régulièrement sur la façon

d’améliorer leurs comportements par rapport aux situations rencontrées. La mise en œuvre

des outils « agiles » relève particulièrement des compétences des individus, de leurs échanges

et collaboration continus et de leur aptitude à s’adapter rapidement à de nouvelles situations.

Si l’application de ces méthodes a reçu des échos très positifs au niveau des équipes de taille

réduite, les résultats 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 à réaliser. Parmi les études empiriques ayant traité de la mise en pratique de

ces « innovations managériales », rares sont celles qui se sont focalisées sur leur application

dans des structures organisationnelles « complexes11 ». Nous constatons par conséquent, une

véritable lacune dans la littérature consacrée à ce sujet. D’autant plus, qu’aujourd’hui, la

majorité des organisations, s’inscrivant dans des structures complexes, peine à implémenter,

au sein de leurs équipes, ce type de pratiques de développement et de management de projet.

La philosophie des méthodes « agiles »semble ainsi poser de façon centrale la question du

sens collectif, et ce dans une perspective interactionniste (Koenig, 2003) où la création de

sens se fait de manière processuelle par l’intermédiaire de la communication entre les

intervenants. Dans cette optique, les dynamiques d’organizing auxquelles ces méthodes

renvoient peuvent être appréhendées comme des séquences continues d’interactions entre les

acteurs d’un projet. Cela nous amène à nous interroger sur la manière dont ce type

« d’innovation managériale » (David, 1996) peut être mis en œuvre dans une démarche

structurée de management pour constituer un dispositif formalisé d’organizing.

L’objet de cette thèse de doctorat en sciences de gestion est de répondre à cette problématique

de recherche en articulant une analyse critique de la littérature consacrée aux méthodes

« agiles » et une étude de cas (David, 2000) menée dans la perspective de l’approche « par la

11Par « complexe » nous désignons une structure organisationnelle matricielle, de grande taille dans laquelle les

projets menés impliquent des acteurs métiers transverses et géodistribués.


16

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

Antonacopoulou, 2006 ; Jarzabkowski & Kaplan, 2008). Cette dernière met en avant l’action

humaine pour comprendre le fonctionnement des groupes et les liens qu’ils entretiennent avec

l’organisation et la société (Rouleau, Allard-Poesi & Warnier, 2007).

Le choix de privilégier une approche « par la pratique » s’explique d’une part, par le manque

de connaissances sur la manière dont les méthodes « agiles » sont appliquées dans des

configurations organisationnelles complexes et d’autre part, par notre volonté de voir ce que

font concrètement les acteurs impliqués dans la « fabrication » et la mise en œuvre de ces

méthodes émergentes de management de projet. A cette fin, l’approche par la pratique se

présente comme un angle de recherche pertinent pour examiner de près la « construction »

d’une démarche « agile » par les responsables de sa mise en œuvre. L’attention est, dès lors,

centrée sur les conversations des managers, leurs interprétations et leurs interactions par le

biais desquelles ils parviennent à faire sens des méthodes « agiles » présentées dans la

littérature académique et professionnelle et de l’environnement dans lequel elles sont

implémentées.

Afin d’interroger le plus finement possible la manière dont les méthodes « agiles » sont

interprétées et appliquées dans un contexte particulier, nous avons suivi, pendant 17 mois, la

mise en œuvre d’une démarche managériale basée sur des pratiques « agiles12 » dans une

entité, appartenant à un groupe français de télécommunication, responsable du pilotage et de

la livraison des produits de télévision numérique par câble, satellite et sur le réseau IP. Les

raisons ayant amené la direction de l’entité observée à faire évoluer ses méthodes de gestion

projet en empruntant la voie de l’agilité s’expliquent principalement par le dépassement des

coûts et des délais de ses projets et la non-conformité des produits livrés aux attentes des

clients.

Cette étude de cas, qui constitue le cœur empirique de notre travail de recherche, nous a

permis d’examiner en profondeur la manière dont ces méthodes peuvent être développées et

12Dans ce travail, l’agilité est appréhendée comme un concept « parapluie » regroupant les principes et les

pratiques relevant de l’ensemble des méthodes « agiles » inclus l’approche du développement lean issue du

monde industriel.


17

mises en œuvre, par un groupe de managers13, au sein d’un contexte organisationnel

caractérisé par des conditions physiques, techniques et structurelles spécifiques.

Les observations réalisées ont eu notamment pour objectif d’analyser la démarche de

« fabrication » d’une stratégie « agile » et de sa mise en œuvre dans une organisation

caractérisée par des équipes instables, rattachées à plusieurs projets et dispersées

géographiquement.

La structure de la thèse

Ce travail comprend deux parties :

La première partie de cette thèse est fondée sur une revue de la littérature sur les méthodes de

management de projet de type « agile » en tant qu’« innovations managériales ». Elle est

composée de trois chapitres. Le chapitre (I) présente et analyse les méthodes « agiles » du

point de vue des substrats techniques et de la philosophie gestionnaire qu’elles sous-

entendent. Le chapitre (II), met en perspective nombre de travaux rendant compte de

l’implémentation de ces méthodes émergentes de management de projet au sein d’entreprises.

A la lumière de ces deux volets d’analyse, le chapitre (III) présente la stratégie de recherche

que nous avons retenue : cerner la question de la contextualisation interne de ces

« innovations managériales » au travers d’une approche « par la pratique ».

La seconde partie est consacrée à l’analyse de la construction d’une démarche « agile » de

management de projet : le cas d’une « fabrique » de stratégie « agile ». Elle se subdivise

également en trois chapitres : le chapitre (IV) présente l’organisation dans laquelle s’est

déroulé notre travail de terrain et précise notre appareillage analytique. Le chapitre (V) rend

compte de nos observations et analyses de l’étude de cas réalisée durant 17 mois. Enfin le

chapitre (VI), est centré sur la mise en discussion de celles-ci.

13Nous précisons que la démarche managériale lancée par la direction générale a été présentée comme une

démarche lean. Par conséquent, le groupe d’acteurs désignés responsables de la mise en place de cette démarche

s’est attribué l’appellation d’équipe lean. Néanmoins cette démarche repose sur des outils issus des méthodes

« agiles » de développement informatique et du lean management.


18

La conclusion est l’occasion de revenir sur les principaux résultats obtenus, de présenter les

limites de cette thèse et de proposer d’éventuelles pistes de recherche futures.

19

20

La première partie de cette thèse expose les éléments des méthodes de management de projet

de type « agile » en tant qu’« innovations managériales ».

Le chapitre (I) présente les méthodes « agiles ». Trois méthodes « agiles » ont été retenues : la

méthode scrum, la méthode extreme programming et le lean development.

Le chapitre (II), met en perspective nombre de travaux rendant compte de l’implémentation

de ces méthodes émergentes de management de projet au sein des entreprises.

Le chapitre (III) présente la stratégie de recherche qui vise à cerner la question de la

contextualisation interne de ces « innovations managériales » au travers d’une approche

d’analyse « par la pratique ».

PPAARRTTIIEE II :: DDEE LLAA QQUUEESSTTIIOONN DDEESS MMEETTHHOODDEESS

«« AAGGIILLEESS »» CCOOMMMMEE «« IINNNNOOVVAATTIIOONNSS

MMAANNAAGGEERRIIAALLEESS »»

21

CChhaappiittrree II :: PPrréésseennttaattiioonn ddeess mméétthhooddeess «« aaggiilleess »» ::

pprriinncciippeess eett iinnssttrruummeennttss ddee ggeessttiioonn

Ce chapitre est consacré à la présentation des méthodes « agiles » du point de vue des

substrats techniques et de la philosophie gestionnaire qu’elles sous-entendent. Il se divise en

deux sections.

Dans la première section, nous définissons la notion d’agilité, nous présentons les causes de

l’intérêt actuel pour ces nouvelles approches de développement et de management de projet

informatique et leurs principales sources d’inspiration.

Dans la seconde section, nous présentons trois approches « agiles » (la méthode scrum, la

méthode extreme programming et le development lean) ayant fait l’objet de nombreux

travaux empiriques. Nous décrirons les pratiques et instruments de gestion portés par chacune

d’elles. A la fin de cette section, nous montrons comment ces trois approches offrent un bon

panorama du mouvement « agile ».

Chapitre I : Présentation des méthodes « agiles » : principes et instruments de gestion

22

« L’agilité est avant tout une réponse à l’élargissement et au durcissement des

environnements concurrentiels qui permet d’insuffler à l’organisation réactivité et

performance14 ». Appliquée au monde des logiciels, la notion d’agilité renvoie à la capacité

d’adaptation des sociétés informatiques aux demandes évolutives des clients, arrivant le plus

souvent en cours de projet et à une meilleure maîtrise du triptyque « coût/qualité/périmètre

fonctionnel ». Ces méthodes constituent une nouvelle logique de développement de projets

informatiques, décrites comme étant itératives, incrémentales, encourageant l’auto-

organisation et l’adaptation au changement.

Avant d’approfondir davantage cette notion d’agilité et ses principales sources d’inspiration,

nous souhaitons revenir sur les limites des méthodes « classiques » de management de projet

qui semblent avoir participé à l’émergence du mouvement « agile ».

1. Des méthodes classiques de management de projet aux méthodes « agiles »

1.1 Les méthodes « classiques » : une démarche « lourde » de conduite de projet

Les approches « classiques » de management de projet s’accordent sur l’hypothèse selon

laquelle les dépenses augmentent dramatiquement lorsque des rectifications sont effectuées

durant la phase d’implémentation. Dans cette perspective, les changements survenant après le

passage de la phase préliminaire du projet sont limités en vue de tenir les délais et respecter

les coûts préalablement fixés (Highsmith & Cockburn, 2001). Des contrats « rigides » sont

élaborés avec le client, précisant, de manière très fixe, le périmètre et le coût de la solution

(Paetsch, Eberlein & Maurer, 2003). L’accent est donc mis sur la phase de planification

durant laquelle se fait la définition de l’ensemble des besoins à implémenter. Le plan détaillé

constitue le fil conducteur, indispensable au projet. Beaucoup de temps et d’efforts sont ainsi

consacrés pour prévoir la totalité des demandes et réduire les changements éventuels (Sillitti,

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

http://www.rad.fr/


23

Ceschi, Russo & Succi, 2005 ; Hilkka, Tuure & Matti, 2005). On estime que le client est

capable de déterminer, dès la phase initiale, l’ensemble de ses attentes à l’égard de la solution.

La documentation, quant à elle, occupe une place essentielle dans le développement

« classique » de logiciels. Elle comprend la mémoire de toutes les micros-décisions

opérationnalisées (documentation conceptuelle, documentation du marketing, documentation

du codage, les codes, les documents d’installation, etc.), matérialise l’avancement des travaux

et constitue un support de communication entre les différents intervenants.

Cependant, les principes soutenus par ces modèles renvoient à des problèmes variés. Une part

non négligeable de l’enveloppe budgétaire est consacrée aux étapes d’analyse et de prévision

des besoins. Dans cette logique, la planification extensive et les décisions prises en amont

prennent le pas sur l’intégration progressive des changements. Or, à la lecture des travaux sur

les limites des approches « classiques », un résultat semble être partagé par la majorité des

spécialistes en informatique : l’anticipation complète des besoins est difficile à réaliser car

d’un côté, le client, lui même, ne sait pas ce qu’il veut et d’un autre, l’environnement, 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 d’organiser en amont l’ensemble du processus de

développement (Sillitti, Ceschi, Russo & Succi, 2005 ; Morien, 2005). Selon plusieurs études,

de nombreux projets logiciels sont abandonnés avant d’être mis en production entraînant des

pertes de plusieurs milliards de dollars (Standish group, 1995). Les principaux facteurs

d’échec de ces projets sont liés à une attitude prédictive inadaptée (mauvaises estimations de

la productivité des équipes, des délais et des coûts), à l’évolution constante des besoins et à

une faible implication des utilisateurs.

D’autres difficultés renvoyant à la « rigidité » de ces modèles « classiques » concernent le

traitement des changements et la conformité aux demandes exprimées. Tout d’abord,

l’intégration et le traitement des modifications sont longs et coûteux. Ils impliquent des

retours en arrière à des métiers qui sont déjà passés à d’autres tâches (Garel, 2003). Ensuite, la

séparation entre les acteurs de l’amont (les concepteurs, le marketing) et ceux de l’aval

(développeurs) génère des barrières de communication et conduit à des désaccords dans la

définition et le recueil des besoins (Al Rawas & Easterbrook, 1996 ; Garel, 2003). En outre,

l’intervention successive de différents acteurs métiers (analystes, concepteurs, développeurs,


24

etc.) engendrent des pertes d’informations importantes. De fait, les principes de gestion de

projet informatique et de développement valorisés par les méthodes « classiques » ont été

remis en question.

1.2 Les méthodes « agiles » : une nouvelle tendance managériale

Le secteur informatique participe d’une évolution générale qu’ont connue les industries de

logiciels, dans les vingt dernières années. Cette évolution se trouve à l’origine de la rapidité et

de la complexité des projets informatiques : instabilité et obsolescence des demandes, fortes

exigences des clients, accélération du marché technologique, diversification des offres, etc.

Comme nous l’avons déjà précisé, l’anticipation des besoins des clients et la définition

complète de l’ensemble des demandes sont devenues très risquées. Dans un tel contexte, les

soucis de réactivité, de réduction des délais de mise sur le marché et d’adaptabilité se sont

progressivement imposés.

Comment transformer les pratiques d’ingénierie et les modes de management pour produire

plus rapidement les applications informatiques? Comment concilier la qualité des produits et

les délais de livraison ? Comment rendre les logiciels conformes aux attentes évolutives des

clients ? Comment concilier la dialectique entre le niveau de connaissances acquis et les

capacités d’actions dans un projet ? C’est en répondant à cet ensemble de questions qu’un

groupe de professionnels et d’experts en matière de développement informatique a mis en

œuvre, à la fin des années 1990, un ensemble de méthodes classées sous le qualificatif

« agile ».

1.2.1 Vers un consensus autour de la définition de l’agilité

Depuis la fin des années 1990, un nombre croissant de professionnels du développement de

logiciels se sont intéressés au concept d’agilité et ont tenté, à travers divers articles et

ouvrages, d’y apporter une définition. Pour Erickson et ses collègues (Erickson, Lyytinen &

Siau, 2005), l’« agilité » permet de s’emparer de la rigidité des méthodes de développement

« traditionnelles » et incite à répondre, de manière très rapide, aux changements de

l’environnement et aux contraintes imposées par les délais, toujours plus courts, de livraison

de projets. Dans une même optique, d’autres auteurs ont apparenté le développement « agile »

aux notions de flexibilité, de rétroaction et d’adaptation au changement rapide et continu.


25

Pour ces personnes, les méthodes « agiles » ont été mises en place dans le but d’intégrer le

changement plutôt que de le freiner ou de le détourner. Elles constituent un moyen pour les

sociétés de développement de survivre dans un environnement instable (Abrahamsson, Salo &

Ronkainen, 2002 ; Williams & Cockburn; 2003 ; Beck & Andres, 2004). D’autres définitions

ont, quant à elles, mis l’accent sur l’aspect humain. Du point de vue de leurs auteurs,

l’imprévisibilité de l’environnement est surmontée à travers les individus et leur créativité

(Dyba, 2000 ; Beck, 2004). Si l’ensemble de ces définitions s’accordent sur les principes

d’adaptabilité et de flexibilité, elles ne permettent pas d’avoir une vision précise de ce que

représente concrètement le concept d’agilité en matière de développement et de management

de projets informatiques.

1.2.1.1 Le manifeste « agile »

Les méthodes « agiles » aspirent à améliorer la réactivité et l’adaptabilité des sociétés de

logiciels aux fluctuations environnementales. En 2001, le mouvement « agile » a fait l’objet

d’un accord entre dix-sept experts du développement de logiciels défendant une organisation

de projets informatiques moins structurée et plus légère que les méthodologies en vigueur, sur

un ensemble de valeurs et principes consignés dans un manifeste « agile15 ».

Les réflexions et les retours d’expériences des professionnels de l’informatique les ont

amenés à valoriser :

- Les individus et les interactions plutôt que les processus et les outils ;

- L’application fonctionnelle plutôt que la documentation compréhensive ;

- La collaboration avec le client plutôt que la négociation des contrats ;

- La réponse au changement plutôt que le suivi d’un plan.

Si les méthodes « agiles » privilégient les échanges fréquents entre les membres d’un projet,

elles ne rejettent pas toutefois les outils méthodologiques en l’occurrence, la planification.

Dans cette optique, les « agilistes » reconnaissent l’utilité des plans mais ne s’y conforment

pas « aveuglement ». Ces derniers sont sujets aux changements et doivent être définis de

15La définition officielle du développement « agile » a été retenue dans un manifeste signée par 17

méthodologistes en développement 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.


26

manière itérative. La planification fait donc l’objet d’échanges informels et d’ajustements

mutuels entre les acteurs projets.

En ce qui concerne le processus de développement, il ne renvoie pas à un contrat « fixe »

entre le client et les acteurs projets. Il s’appuie, en revanche, sur un ensemble d’activités

(réunion de planification du livrable, réunion de planification des itérations, etc.) et d’artefacts

« flexibles » (product backlog16, sprint backlog17, user-stories18) précisant les engagements des

deux parties. Nous reviendrons un peu plus bas sur les instruments de gestion portés par ces

méthodes émergentes.

Conformément aux valeurs soutenues par les fondateurs du mouvement « agile », la

documentation compréhensive est perçue comme une source majeure de gaspillage.

Néanmoins, elle ne peut être entièrement éliminée et par conséquent, elle doit être repensée

différemment. A cet effet, la documentation ne constitue plus une activité à part, nécessitant

un investissement en termes de temps et de ressources mais résulte des activités de

développement menées : « story-cards19 », les tests, les codes, « product-backlog », etc.

Après avoir présenté les valeurs fondamentales du mouvement « agile » il apparaît utile de

dresser la liste des principes qui en découlent : la livraison rapide de logiciels utiles et de

qualité ; l’adaptation aux changements et aux demandes tardives des clients ; la collaboration

et les interactions continues entre les parties prenantes du projet ; la construction d’un projet

autour d’individus bien motivés ; la production d’une application fonctionnelle permettant de

mesurer progressivement l’avancement du projet ; la qualité de la conception et l’excellence

technique; l’auto-organisation des équipes; l’amélioration continue de l’efficacité de l’équipe

et la simplicité. L’annexe (I) reprend les principes « agiles » tels qu’ils sont mentionnés dans

le manifeste.

Divers questionnements méritent toutefois d’être traités : pourquoi faut-il impliquer le client

dans le processus de développement ? Quel est l’intérêt de livrer rapidement des solutions

16C’est un document d’analyse détaillé qui liste l’ensemble des fonctionnalités à implémenter. Les items notés

sur le « product-backlog » peuvent contenir les critères, les fonctionnalités, la fixation des bugs, les défauts, etc. 17C’est le point de départ de chaque sprint ou itération. Le « sprint-backlog » contient la liste des tâches à réaliser

dans la prochaine itération afin de convertir les items du « product-backlog » en un incrément livrable. 18Il s’agit des demandes fonctionnelles et des besoins des utilisateurs qui sont généralement écrits par les

utilisateurs. 19Ils représentent des cartes sur lesquelles sont marqués les scénarios ou les « histoires des utilisateurs ».


27

fonctionnelles capables d’intégrer les changements continus ? Quels sont les avantages d’un

développement itératif et incrémental ? Les travaux ayant traité de ces questions seront

présentés dans le chapitre (II).

1.2.2 Les enjeux du développement « agile » de logiciels

L’attention actuelle accordée au développement « agile » procède d’une double explication :

les enjeux de réactivité et les avantages du développement rapide. Ces enjeux ont déjà été à

l’origine d’autres modèles d’organisation et de management de projets en général, à titre

d’exemple, le modèle d’ingénierie concourante, que nous présenterons brièvement.

La saturation des marchés, l’hétérogénéité des demandes et les difficultés d’anticipation des

besoins ont transformé les systèmes de production des industries manufacturières. Le modèle

de l’économie réactive s’est ainsi imposé au niveau de ces industries remettant en cause les

modèles de la standardisation20 et de variété21. Dans une économie de concurrence, les

entreprises modifient leur système productif pour réduire les délais de mise sur le marché et

gagner en réactivité22. A cet effet, de nouvelles stratégies ont été adoptées par les

organisations à la recherche d’un avantage compétitif durable: la stratégie de niche pour

capter les demandes les plus exigües et la stratégie d’obsolescence (Garel, 2003). On postule

que les demandes sont volatiles et se transforment rapidement.

Bien que cette hypothèse soit également soutenue par les « agilistes », les stratégies de

réponse adoptées par ces derniers s’avèrent différentes. Si l’ingénierie concourante repose sur

une logique d’offre proactive, les méthodes « agiles », quand à elles, mettent l’accent sur

l’adaptation aux besoins émergents des clients. Le processus de développement relève d’une

collaboration forte entre le client et l’équipe de développement.

Par ailleurs, le développement rapide de produits, valorisé tant par l’ingénierie concourante

que par les approches « agiles », présente des avantages : d’une part, le client a peu de chance

de changer son avis si le produit lui est livré rapidement et d’autre part, les coûts et les

20Ce modèle renvoie à la production de masse des biens ayant de longs cycles de vie. En période de croissance

stable ce modèle s’avère efficace (Garel, 2003). L’objectif de l’entreprise est de répondre, sans souci premier de

délai ni de qualité, à une forte demande du marché en proposant des produits standardisés à bas prix. 21Ce modèle renvoie à la diversification des offres pour répondre aux besoins variés des clients. Ce modèle

présuppose que les demandes sont facilement identifiables et prévisibles. 22La réactivité signifie « la capacité à reconfigurer rapidement ses ressources de production et la capacité à

répondre rapidement aux exigences des consommateurs » (Cohendet & al, 1992 dans Garel, 2003, p.39).


28

dépenses supplémentaires liés à la découverte tardive de défaillances sont limités. Les cycles

de développement courts procurent une vision concrète et progressive par rapport à la partie

développée réduisant ainsi les risques de non-conformité aux attentes (Poppendieck, 2006).

Les enjeux ayant conduit les industries manufacturières à changer de modèle de production

s’apparentent à ceux des modèles émergents de développement informatique. A ce titre, il est

utile de revenir sur les approches managériales qui ont inspiré les fondateurs des méthodes

« agiles ».

1.3 Les sources d’inspiration des méthodes « agiles »

1.3.1 Transposition du modèle Toyota au développement de logiciels

Les années 1980 et 1990 témoignent de la transformation des systèmes d’organisation

largement inspirés du taylorisme et du fordisme. L’expansion des principes de gestion issus

du modèle japonais, connu aujourd’hui sous le système de production Toyota (TPS), semble

être à l’origine d’un tel changement. Les concepts clés dont relève ce système renvoient

principalement à l’autonomation et à la production juste à temps. L’autonomation regroupe un

ensemble d’outils (l’andon qui consiste à arrêter automatiquement la production en cas de

problème) et de méthodes (pareto des causes, la méthode des 5 Pourquoi) dont le but est

d’inciter l’ensemble des employés d’une entreprise à améliorer ex ante la qualité des produits

et des services vendus plutôt que d’éliminer ex post les rebus. Le principe de juste-à-temps,

quant à lui, consiste à organiser son entreprise de telle sorte qu’elle puisse livrer exactement et

au bon moment la quantité de biens souhaités par ses clients. La production est tirée par la

demande. En d’autres termes elle est déclenchée par les demandes des clients (Houy, 2009).

Après le succès spectaculaire du Système de Production Toyota traduit sous le terme de lean

management23, de nombreux constructeurs de véhicules ont tenté de reproduire, au sein de

leur organisation, l’ensemble des principes et pratiques relevant de cette approche

managériale dans le but d’améliorer la performance et la productivité de leur système de

production. La réussite commerciale affichée par les industries lean et leur forte médiatisation

23Littéralement lean signifie « maigre ». Le lean management qualifie un ensemble de pratiques managériales

inspirées du Toyota Production System (TPS). Brièvement, on peut représenter le lean management comme un

ensemble de principes et de procédures qui consistent à gérer au plus juste les processus de production (à

produire la quantité exacte au bon moment) et à éliminer tout ce qui ne crée pas de valeur. Cette approche de

développement est présentée dans la section suivante (II).


29

n’ont fait qu’élargir l’expansion de ce système à différents secteurs, dépassant ainsi son

domaine d’application initial, celui de la production industrielle. Il n’est donc pas surprenant

que le lean finisse par intéresser le marché des industries de logiciels en pleine mutation et

croissance. L’industrie japonaise, capable de livrer très rapidement des produits de haute

qualité, va constituer une base empirique et théorique pour le management des projets

informatiques. Divers facteurs de vitesse de développement de projet ont été exposés par

Imaii et alii en 1985 (Imaii & alii en 1985 dans Garel, 2003) dont certains ont été repris par

les « agilistes » : l’auto-organisation des équipes, le multi-apprentissage, l’ajustement mutuel,

le partage d’informations dans un environnement de travail ouvert et le regroupement des

acteurs dans un même espace physique.

1.3.2 L’agile manufacturing

L’« agile manufacturing » a été créé dans les années 1990 par des chercheurs américains, de

Lehigh University, chargés d’améliorer la performance des industries américaines. Les

défaillances du système de production de masse et les menaces des pays industrialisés d’Asie

ont poussé les firmes américaines à changer leur mode de production et à emprunter la voie de

l’ « agilité ». Un rapport, publié par les chercheurs de l’institut Iacocca, intitulé « 21st

Century Manufacturing Enterprise Strategy » (Nagel, Dove, Goldman & Preiss, 1991),

présente les caractéristiques de l’agile manufacturing. Bien que divers chercheurs ont tenté de

définir l’agile manufacturing, il n’existe pas à l’heure actuelle une définition universelle. A

cet effet, nous présentons trois définitions de l’agilité organisationnelle qui relèvent de

différentes dates de publications.

L’agile manufacturing a tout d’abord été défini comme une entreprise robuste, adaptative

avec une capacité de reconfiguration rapide pour répondre aux opportunités du marché. Une

telle entreprise est fondée sur des processus et des structures appropriés ainsi que sur un

système coordonné de personnes, d’organisation et de technologies permettant d’acquérir une

performance compétitive supérieure à 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


30

performance by delivering capabilities that surpass those obtained from current enterprise

practices » (Kidd, 1995, p.3).

Dans une même perspective, Gunasekaran (1998) décrit l’agile manufacturing comme la

capacité de survivre et de prospérer dans un environnement compétitif et instable. Les

entreprises « agiles » sont capables de réagir rapidement aux changements des marchés qui

eux sont régis 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 définition plus récente identifie l’agile manufacturing comme la capacité de

répondre à un marché turbulent soumis aux exigences des clients en termes de réduction de

coûts et de délais.

« 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 définitions partagent toutes une caractéristique commune : elles mettent l’accent sur les

concepts de réactivité24 et d’adaptabilité25 de l’industrie manufacturière. En ce sens, l’agilité

renvoie à la capacité d’une organisation à mettre en œuvre des ajustements rapides et

efficaces pour répondre à l’évolution des demandes des clients de plus en plus exigeants.

Il nous paraît ainsi judicieux de comparer les concepts de l’agile manufacturing à ceux des

méthodes « agiles » (tableau 1)26.

24Cf. page 27. 25L’adaptabilité est la capacité du système de production d’une entreprise à rajuster ou modifier les coûts de

performance en fonction de la demande (Katayama & Bennett, 1999). 26Ce tableau comparatif se base sur une étude réalisée par Kettunen (Kettunen, 2009).


31

Tableau 1: Comparaison des concepts de l'agile manufacturing v/s méthodes « agiles »

Concepts Agile manufacturing Méthode « agiles »

Réponse rapide

aux changements

Capacité de l’entreprise à transformer rapidement les informations collectées en

décisions actionnables (Gunasekaran, Yusuf, 2002).

Capacité de s’adapter aux changements à travers de courts

cycles de développement.

Cycles de développement

rapides

Développement rapide basé sur de courts cycles concept-to-cash (Goldman, Nagel &

Preiss, 2005 dans Kettunen, 2009).

Cycles courts ne dépassant pas les quelques semaines. Les itérations

sont fixées dans le temps.

Reconfiguration

Capacité d’une entreprise à reconfigurer sa structure organisationnelle et ses processus

et à réorienter sa production ainsi que ses ressources afin de mieux répondre aux

changements

(Gunasekaran, Yusuf, 2002).

Reconfiguration au niveau du

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

Pro-activité

Saisir les nouvelles opportunités ou

provoquer des « ruptures » par le biais de l’innovation

(Yusuf, Sarhadi & Gunasekaran, 1999)

Adaptation aux besoins émergents des clients et réduction des activités

d’anticipation.

Qualité

La qualité renvoie à la valeur ajoutée perçue par le client. Il n’existe pas de compromis

précis sur la qualité (Liker, 2004 dans Kettunen, 2009).

La qualité est considérée comme une norme. Recours à des pratiques

d’ingénierie pour améliorer la qualité (tests unitaires, intégration

continue).

Stratégie des processus

industriels

Les capacités industrielles sont déterminées en fonction des objectifs stratégiques. Les

industries agiles sont du type make-to-order 27

(Narasimhan, Swink & Kim, 2006)

Les méthodes de développement agiles sont de nature engineering to

order 28 : les fonctionnalités sont

redéfinies et stabilisées durant la conception du produit.

Leadership

Le management scientifique est remplacé par le principe d’empowerment. Les

personnes disposent d’une autonomie,

accordée par leur hiérarchie, pour organiser leur travail.

(Gunasekaran, Yusuf, 2002).

Renforcement et auto-organisation

des équipes.

27La production se fait suite à une demande bien précise. 28Il s’agit d’une méthode de développement dans laquelle la conception de l’ensemble ou d’une partie du produit

se fait selon l’ordre du client.


32

Entreprise guidée

par les connaissances

Les connaissances collectives constituent un

avantage compétitif pour l’organisation (Yusuf, Sarhadi & Gunasekaran, 1999).

La circulation libre de l’information

et les connaissances tacites sont valorisées.

Prises de

décisions

L’autorité est distribuée, les prises de risque et le partage de connaissances sont

encouragés. (Shafer, 1997 dans Kettunen, 2009).

La responsabilité est partagée entre les membres d’une équipe de

développement agile. la collaboration et la communication

fréquente sont encouragées.

Ce tableau permet de comprendre les fondements de la notion d’agilité qui se trouvent à

l’origine des transformations des industries manufacturières et des industries de logiciels.

Malgré le rapprochement que nous avons pu constater entre les deux approches d’agilité,

certaines différenciations subtiles méritent d’être soulignées.

Tout d’abord, les stratégies adoptées pour maîtriser et répondre aux changements sont

différentes : les fondateurs de l’agile manufacturing valorisent non seulement la réactivité à

l’égard des changements mais aussi la « proaction » qui est d’ailleurs encouragée par

l’ingénierie concourante. En revanche, le développement « agile » cherche à s’adapter aux

besoins émergents du client en favorisant la collaboration étroite avec celui-ci ; l’anticipation

des évènements futurs n’étant pas privilégiée.

Ensuite, les stratégies des processus industriels diffèrent d’un modèle à un autre. Si l’agile

manufacturing exige une définition précise de la demande avant le lancement de la

production, le développement « agile », quand à lui, se base sur une définition vague des

fonctionnalités à implémenter qui seront détaillées puis développées, en fonction de leur

priorité, au fur et à mesure de l’avancement du projet.

En outre l’agile manufacturing ne semble pas s’appuyer sur des pratiques spécifiques

destinées à améliorer la qualité. Cette dernière renvoie à la valeur ajoutée perçue par le client.

Quant aux méthodes « agiles », en particulier la méthode « extreme programming », elle

repose sur des pratiques d’ingénierie (le développement conduit par les tests, l’intégration

continue, le « nettoyage » quotidien des codes) qui cherchent à anticiper les défauts et les

bugs et à améliorer la lisibilité des codes et sa maintenabilité.


33

1.3.3 Le développement itératif et incrémental

D’autres sources, plus rarement citées, semblent également avoir inspiré les auteurs du

courant « agile » : le développement itératif et l’implication des utilisateurs.

Le développement itératif et incrémental remonte aux travaux de Walter Shewhart29 en 1930.

L’avion hypersonic X-15 fut une première étape dans l’application du principe de

développement itératif et incrémental. Ce type de développement a été perçu comme une

contribution majeure au succès du X-15. Ce principe fut ensuite appliqué, en 1960, au

développement de logiciel autour du projet Mercure. Un article a été publié en 1975 décrivant

ce type d’approche.

« 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).

D’autres rapports ont tenté de montrer les avantages liés à ce type de développement. Les

courtes itérations permettent d’avoir un feedback sur les parties développées limitant les

risques de l’« effet tunnel » (longueur des projets) et les problèmes 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 d’implication des utilisateurs, celui-ci a également fait l’objet de rapports

antérieurs.

« 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 d’inspiration montrent bien que contrairement à ce que de nombreux travaux

sous-entendent de nos jours, la notion d’agilité n’est pas récente. Beaucoup de professionnels

29Expert à Bell-Labs, Walter Shewhart proposa, dans les années 1930, les courts cycles « plan-do-study-act »

(PDSA) d’amélioration de la qualité repris par Edward Deming à travers le PDCA (plan-do-check-act).


34

de l’informatique ont déjà eu recours à des pratiques que nous qualifions aujourd’hui

d’ « agile ». A ce titre, il serait intéressant de montrer la place qu’accordent, actuellement, les

industries de logiciels à ces méthodes.

1.3.4 L’intérêt actuel des entreprises pour le développement « agile »

En très peu de temps, la notion d’ « agilité » a connu un grand succès au niveau des industries

de développement de logiciels. Plusieurs études ont déjà été réalisées pour évaluer le taux

d’adoption de ces approches émergentes.

Une enquête internationale30, conduite en 2008 auprès de 642 professionnels du

développement d’applications 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

méthodes « agiles ». Durant la même année, une seconde étude internationale31 a été réalisée

auprès de 3061 employés utilisant ce type de pratiques. Les principaux résultats montrent

que 49% des équipes « agiles » mobilisent la méthode « scrum », et 22% combinent les

méthodes « scrum » et « extreme programming ». En effet, 26% des entreprises utilisent les

méthodes « agiles » depuis deux ans et 7% depuis plus de 5 ans.

Selon un autre rapport d’étude32, publié en 2009, concernant 123 praticiens « agiles », 65%

des participants déclarent recourir à l’intégration continue, 47% aux réunions quotidiennes et

au développement basé sur les tests et 45 % au développement itératif. Ces différentes

pratiques seront présentées en détails dans la section suivante.

Une autre enquête internationale33 à laquelle nous nous sommes intéressés, a été conduite, en

2010, auprès de 4770 participants dont la majorité s’avère des managers de projets. Les

résultats montrent que 40% des organisations utilisent des pratiques « agiles » depuis environ

deux ans et que dans 32% des cas, ces pratiques sont adoptées par de larges organisations

(>250 salariés). Toutefois 65% des personnes interrogées affirment avoir travaillé avec des

équipes « agiles » géographiquement distribuées. Les méthodes « agiles » mobilisées sont la

méthode « scrum » (58%), la combinaison « scrum » et « extreme programming » (17%), le

développement lean (2%). Les participants estiment « très important » le fait que ces 30 http://www.ambysoft.com/surveys/agileFebruary2008.html 31 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

http://www.ambysoft.com/surveys/agileFebruary2008.html

http://www.ambysoft.com/surveys/practices2009.html


35

méthodes améliorent les délais de mise sur le marché (37%), les capacités de gestion du

changement des priorités (36%), la qualité des logiciels (24%), la visibilité du projet (17%),

etc. En revanche, il apparaît que l’échec des projets « agiles » est dû principalement au

manque d’expérience des équipes en développement « agile » (14%), à la culture d’entreprise

(11%), aux pratiques « traditionnelles » déjà existantes (10%) et au manque de support du

management (8%). Les obstacles auxquels font face les organisations relèvent essentiellement

du changement de la culture organisationnelle (51%), de la résistance 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 qu’effectivement la mise en place de ces méthodes

relève d’un phénomène récent auquel s’intéressent les organisations, indépendamment de leur

taille. Il apparaît, qu’à ce jour, les professionnels de développement de logiciels demeurent

moyennement familiers avec ces pratiques de développement émergentes. Si les méthodes

« agiles » peuvent améliorer les délais de mise sur le marché et la productivité des équipes,

elles nécessitent un investissement en termes de développement des équipes, de

sensibilisation au changement organisationnel, d’initiation à l’auto-organisation, aux échanges

et aux suivis réguliers. A la lumière des résultats remontés, divers facteurs semblent entraver

l’adoption de ces méthodes : le manque d’expérience des équipes en développement « agile »,

les difficultés associées aux transitions culturelles, la résistance au changement

organisationnel, la complexité et la taille des projets, etc.

2. Présentation des méthodes « agiles »

Les premières publications sur les méthodes « agiles » apparaissent en 1991 avec le

développement de la méthode RAD34 par James Martin. D’autres méthodes ont ensuite vu le

jour telles que la méthode DSDM35, la famille des méthodologies Cristal36, le développement

34

Rapid Application Development. Cette méthode conjugue le modèle linéaire, structuré en cinq phases

(initialisation, expression des besoins, conception, construction et mise en œuvre) et le modèle itératif propre à la

phase de développement. Si cette méthode met en avant l’implication des utilisateurs et le développement

itératif, elle privilégie néanmoins la documentation extensive (Annexe III). 35Dynamic System Development Methodology. Elle a été mise au point en 1994 dans le but de combler certaines

lacunes de la méthode RAD. Le cycle de vie du projet repose sur cinq phases : étude de faisabilité, étude du

métier, modélisation fonctionnelle, conception-construction et mise en œuvre. Les deux premières phases sont

réalisées de manière séquentielle alors que les trois suivantes s’effectuent de manière itérative facilitant

l’adaptation aux changements des fonctionnalités et des aspects techniques de la solution. Comparée à la

méthode RAD, le modèle DSDM met davantage l’accent sur le caractère itératif des cycles de modélisation

fonctionnelle et de développement. La participation du client est également plus accentuée (Annexe III).


36

conduit par les tests37 », etc. Si l’ensemble des méthodes « agiles » s’appuient sur des

principes et des valeurs communes, elles se démarquent, toutefois, par rapport aux pratiques

et instrumentations de gestion qu’elles mobilisent.

Dans le cadre de ce travail, nous retiendrons principalement trois méthodes qui font l’objet

d’une littérature foisonnante et qui constitueront le cœur de notre revue de la littérature sur le

sujet : l’« extreme programming », le « scrum » et le « lean développement ». Ces méthodes

sont largement diffusées dans les milieux académiques et professionnels ; par ailleurs chacune

d’entre elles représente une forme d’agilité différente mais complémentaire dans la conduite

des projets informatiques. L’ensemble de ces trois approches donne une certaine complétude

à la présentation du courant « agile ».

Dans cette section, nous nous attachons à décrire le contenu de chacune de ces trois méthodes.

Pour ce faire, nous nous appuyons sur les ouvrages de base des auteurs de ces méthodes afin

de comprendre clairement leurs fondements et objectifs respectifs.

2.1 La méthode « scrum »

2.1.1 Principes, pratiques et instrumentations de gestion

Si le terme « scrum » fut popularisé après la publication de l’ouvrage de Ken Schwaber

« agile software development with scrum », en 2001, celui-ci avait déjà fait l’objet d’un article

de Takeuchi et Nonaka en 1986 intitulé « the new new product development game ». Dans cet

article, les auteurs se réfèrent au concept « scrum » pour souligner une approche de

développement permettant d’améliorer la cohésion de l’équipe et la rapidité du processus de

développement « a rugby approach where a team tries to go to the distance as a unit, passing

the ball back and forth-may better serves today’s competitive requirements » (Nonaka &

36Crée par Alistair Cockburn en 1995, la famille de méthodologie « Crystal » estime améliorer la communication

entre les membres des équipes de développement et accélérer la rapidité de livraison des solutions

technologiques (Highsmith & Cockburn, 2001). Son nom renvoie à la variabilité de couleurs reflétées par un

cristal. Plusieurs variétés sont ainsi regroupées dans cette famille : la méthode « Crystal Clear », « Crystal

Orange », « Crystal Red». Le choix d’une méthode dépend du contexte d’application de celle-ci. A titre d’exemple, la méthode « Crystal Clear » basée sur la communication fréquente, la colocalisation des membres de

l’équipe, les livraisons incrémentales (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 méthode « Crystal

Red », privilégiant les processus et la documentation, s’avère plus adaptée à des projets de grande taille

(Cockburn, 2002b). 37« Test driven development » ou le développement conduit par les tests est une méthode de développement de

logiciels qui préconise d’écrire les tests unitaires avant d’écrire les codes du logiciel.


37

Takeushi, 1986, p.2-3). Au sens initial du terme, « scrum » renvoie à une pratique

généralement connue au rugby signifiant la « mêlée38 ». Cette méthode qualifie un ensemble

de rôles, d’instruments de gestion et de pratiques managériales favorisant un environnement

basée sur la transparence39, l’inspection, le suivi40 et l’adaptation41.

2.1.1.1 Les rôles dans la méthode « scrum »

Les membres d’une équipe « scrum » n’ont pas de rôles prédéfinis. Ils sont pluridisciplinaires

et sont capables de réaliser des activités variées (architecture, conception, développement,

test, etc.). Par ailleurs, les responsabilités managériales sont réparties sur trois rôles: le

« scrum-master », le « product-owner » et l’équipe « scrum ».

Le scrum-master : il fait le relais entre le « product-owner » et l’équipe « scrum ». Il ne gère

pas son équipe, qui est autonome mais l’aide à affronter les problèmes qu’elle rencontre et à

réaliser les objectifs fixés. Son rôle consiste à guider l’équipe dans la mise en œuvre de la

méthode « scrum » et à s’assurer qu’elle adhère aux valeurs, aux règles et pratiques soutenues

par la méthode.

Le product-owner : il est responsable de l’identification des demandes à implémenter et de

l’optimisation du retour sur investissement. Il communique la vision du produit à l’équipe de

développement et détermine les fonctionnalités à développer en fixant la date de lancement du

projet. Il est chargé de la maintenance et de la définition des items dans le « product-

backlog » ainsi que de leur priorisation. Il convient ici de préciser qu’un « product-owner » ne

peut jamais être un « scrum-master ».

L’équipe scrum : elle est constituée de quatre à dix personnes au maximum. Elle a pour rôle

de convertir les items du « product-backlog » en fonctionnalités utilisables à la fin de chaque

itération. Bien que les membres de ces équipes sont polyvalents chacun est néanmoins

spécialisé dans une activité précise : programmation, contrôle de la qualité, interface des

38Le principe de base étant d'être toujours prêt à réorienter le projet au fil de son avancement. 39Le principe de transparence consiste à s’assurer que les divers aspects du processus, affectant les résultats du

projet, sont visibles aux personnes chargées de la gestion des résultats. 40Les principes d’inspection et de suivi mettent l’accent sur l’inspection fréquente du processus de

développement afin de déceler tout écart dans les résultats attendus. 41L’adaptation implique que les ajustements doivent être effectués le plutôt possible pour minimiser les risque de

déviation.


38

utilisateurs, architecture, etc. En outre, l’équipe s’auto-organise pour atteindre les objectifs

fixés.

2.1.1.2 Les artefacts « scrum »

La méthode « scrum » repose sur trois principaux artefacts: le carnet du produit « product-

backlog », le carnet de l’itération « sprint-backlog » et le graphique de progression

« burndown chart ».

Le product-backlog : cet outil représente un document listant les fonctionnalités du projet ou

du produit à développer. Les items renseignés dans celui-ci peuvent renvoyer à des

fonctionnalités, des fixations de bugs, des défauts, des tests, etc. Dans tout « product-

backlog », les items sont décrits, estimés et priorisés. 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 départ de chaque itération. Cet outil contient la

liste des tâches à réaliser dans la prochaine itération. Les tâches sont sélectionnées par

l’équipe « scrum » lors de la planification de l’itération à laquelle participent le « scrum-

master » et le « product-owner ». Toutefois, seuls les membres de l’équipe peuvent modifier

le « sprint-backlog » durant l’itération. Une fois les tâches sélectionnées sont achevées, une

nouvelle itération commence (Annexe IV).

Le burndown chart : c’est un graphe permettant de visualiser l’avancement des tâches au fil

du temps. Au cours d’une itération, cet outil permet de mettre en évidence la corrélation entre

la quantité de travail restante à un moment donné et l’avancement de l’équipe projet (Annexe

IV).

Un autre outil intangible qui semble améliorer la communication entre les membres d’une

équipe « scrum » mérite d’être présenté: la notion « done » ou « réalisé ». En effet, l’objectif

de l’équipe « scrum » est de livrer, à la fin de chaque itération, un sous-ensemble du produit

final. Par conséquent, chaque sous-ensemble doit être signalé comme « réalisé » avant qu’il

soit rajouté à l’incrément précédent. Des tests sont également effectués en vue de vérifier la

cohérence et le fonctionnement des incréments rassemblés. Or, la terminologie « done » n’est

pas comprise de la même façon par toutes les personnes impliquées dans un projet. A titre


39

d’exemple, si pour certains développeurs, la notion « done » implique que le code est propre,

correctement remanié, compilé et testé, pour d’autres personnes ce même terme peut signifier

uniquement compilé. Dans cette perspective, les fondateurs de la méthode « scrum » insistent

sur la clarification des connotations des termes pour éviter les incompréhensions et les

conflits éventuels au sein de l’équipe.

Par ailleurs, la méthode « scrum » repose également sur un ensemble de pratiques

managériales visant la planification du projet et l’organisation des équipes : la réunion « pre-

sprint », la planification de l’itération « sprint planning meeting », les réunions quotidiennes

« daily scrum », la revue de l’itération « sprint review meeting » et la rétrospective de

l’itération « sprint rétrospective ».

2.1.1.3 Les pratiques managériales de la méthode « scrum »

Pre-sprint : c’est une réunion de planification de livrable permettant de discuter et répartir les

items du « product-backlog » sur les prochaines itérations. Durant cette réunion, à laquelle

participent les parties prenantes du projet, les coûts, le budget et la date de livraison du

produit sont estimés.

Sprint planning meeting : c’est une réunion, à double phase, organisée par le « scrum-

master ». Dans un premier temps, l’équipe « scrum » décide avec le « product-owner », de

l’objectif de l’itération et des « scénarios » à réaliser. Dans un deuxième temps, le « scrum-

master » et l’équipe « scrum » se réunissent pour se focaliser sur la manière dont l’incrément

sera implémenté: les différentes tâches à réaliser sont ainsi identifiées, estimées et priorisées.

La granularité d'une tâche doit être d'environ un à deux jours de travail.

Daily scrum : la « mêlée » est une réunion quotidienne de quinze minutes où l’équipe

« scrum » se réunit, souvent, au même endroit et au même moment. Durant cette réunion, le

« scrum-master » pose trois questions à chaque membre de l’équipe : qu'est-ce que tu as fait

hier ? Qu'est-ce que tu vas faire aujourd'hui ? Et quelles difficultés as-tu rencontrées ?

L’objectif est de suivre de près le progrès de l’équipe et de résoudre rapidement les problèmes

lors de leur apparition. Les équipes utilisent des minuteurs pour ne pas dépasser les quinze

minutes de la réunion. Si un membre de l’équipe a besoin de discuter d’un sujet qui ne peut

pas être couvert dans ces quinze minutes, il est recommandé qu’il participe à une autre

réunion nommée « side-bar » qui suit le « daily scrum ».


40

Post-sprint meeting : à la fin de chaque itération, le travail de l’équipe est présenté devant le

« product-owner ». Cette réunion permet d’estimer le progrès du projet et sa conformité aux

critères d’acceptation définis par le « product-owner ».

Rétrospective-meeting : après la réunion « post-sprint », l’équipe « scrum » et le « scrum-

master » se réunissent pour évaluer rétrospectivement le déroulement de l’itération : l’équipe

évoque ce qui s’est bien passé et ce qui s’est mal passé et avec le « scrum-master », ils

identifient les améliorations à faire dans les prochaines itérations. Durant cette réunion,

l’équipe est amenée à évoquer les points de succès et d’échecs du projet. Cette réunion est

aussi une occasion pour le « scrum-master » d’observer les obstacles récurrents qui

influencent le fonctionnement de l’équipe.

2.1.1.4 Le modèle de développement « scrum »

Le processus de développement débute par une définition du système à développer. On

postule que la vision de la solution évolue avec l’avancement du projet. Dans cette phase

d’avant jeu « pre-game », les demandes fonctionnelles et non fonctionnelles sont définies et

répertoriées dans le « product-backlog ». Ces demandes sont élaborées par le client, le

marketing ou le développeur représenté par le « product-owner ». A ce stade le nombre de

scénarios, la date et les coûts de livraison ainsi que le contrôle de risques sont revus par

l’équipe de développement. Au cours de cette phase, l’architecture du système est planifiée

par l’équipe « scrum » à partir des éléments du « product-backlog ».

Ensuite, l’itération dont la durée oscille entre une et quatre semaines est initiée par un « sprint

planning meeting » au cours duquel le « product-owner » et l’équipe vont négocier des

« scénarios » à implémenter. Cette réunion ne peut excéder les huit heures. Elle comporte

deux volets de quatre heures chacun : le premier est consacré à la sélection des items du

« product-backlog » et le second consiste à définir et à estimer les tâches à réaliser.

L’estimation relève de la « vélocité42 » de l’équipe de développement et de ses expériences

passées. Si le choix et la priorisation des fonctionnalités à implémenter reviennent au

« product-owner » ils peuvent toutefois être modifiés par l’équipe « scrum ».

42La vélocité renvoie au nombre de scénarios que l’équipe estime être capable de réaliser durant une itération.

Elle peut être déterminée à partir de l’expérience de l’équipe sur le sujet, des projets antérieurs, etc.

http://scrummethodology.com/scrum-product-owner/


41

Dans la phase de jeu « game », une réunion quotidienne « daily scrum », d’une durée de

quinze minutes, a lieu entre les membres de l’équipe « scrum ». A la fin de l’itération, une

revue de l’itération, d’une durée de quatre heures se fait entre l’équipe « scrum » et le

« product-owner ». L’équipe présente au « product-owner » le produit partiel pour avoir son

retour sur les fonctionnalités développées. Après cette réunion, la rétrospective de l’itération

se déroule entre l’équipe et le « scrum-master » où chaque membre est invité à s’exprimer sur

l’itération passée. Ces diverses réunions (daily scrum, sprint planning meeting et sprint

review) relèvent ainsi des pratiques d’inspection et d’adaptation de la méthode « scrum ».

Enfin, la phase d’après-jeu « post-game » qui consiste à clôturer le projet et à livrer le produit

complet et documenté.

La figure (I) illustre le cycle de vie de la méthode « scrum ».

2.2 La méthode « Extreme Programming »

2.2.1 Principes, pratiques et instrumentations de gestion

Contrairement à la méthode « scrum » qui ne couvre aucune technique d’ingénierie, la

méthode « XP », paru en 1999, dans un ouvrage intitulé « Extreme Programming Explained:

Embrace Change » qualifie un ensemble d’outils de coordination et de pratiques d’ingénierie

favorisant l’apprentissage, l’amélioration continue et l’adaptabilité des projets informatiques.

Cette méthode, itérative et incrémentale, revendique son nom au fait que les pratiques de

développement sont poussées à l’extrême. A titre d’exemple, la revue des codes est faite de

Figure I: Processus de développement « scrum »

2 à 4 semaines

Périmètre du produit

Périmètre de l’itération

Produit

partiel

24 heures Itération

« Daily scrum »


42

façon continue, la conception est remaniée tout au long du projet et l’intégration est réalisée

plusieurs fois par jour.

La communication occupe une place centrale dans le processus de développement « XP ».

Elle est médiatisée par un ensemble d’artefacts (« story-cards », « story-board », etc.) et de

pratiques (programmation en paire, réunions quotidiennes, client sur le site, etc.). Les auteurs

de cette méthode estiment que les problèmes majeurs rencontrés dans un projet de

développement sont souvent dus à un manque de communication au niveau de l’équipe. De ce

fait, ils privilégient les rencontres fréquentes entre les membres de l’équipe et avec le client en

vue de favoriser les feedback et les ajustements continus. Par ailleurs, la simplicité des codes

et du design est nécessaire pour améliorer la flexibilité et l’adaptabilité du système et réduire

les coûts. En outre, les membres des équipes « XP » sont amenés à changer de rôle 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 méthode « XP »

La méthode « extreme programming » revoie à un ensemble de principes et de pratiques

allant de la programmation à la collaboration en passant par l’organisation des équipes. Nous

présentons, dans la partie qui suit, les pratiques et principes tels qu’ils sont décrits dans

l’ouvrage de Kent Beck (Beck & Andres, 2004). Par souci de clarté, nous classerons ces

pratiques en fonction de leur visée : gestion de projet, programmation et collaboration

(tableau 2).

Tableau 2: Les pratiques « XP »

Gestion de projet

-Planification itérative (cycle de planification hebdomadaire, réunion hebdomadaire ou « planning game » et réunion

quotidienne ou « stand-up meeting »)

-La livraison itérative et incrémentale.

Programmation

-La conception simple, incrémentale -Les tests unitaires et fonctionnels

-La construction rapide -Le déploiement quotidien -Le remaniement des codes

-L’intégration continue

Collaboration

-La métaphore -La programmation en paire

-L’appropriation collective du code -Les règles de codage

-Le client sur le site


43

Planning game : c’est la réunion effectuée au début de chaque itération entre le client et

l’équipe de développement. Au cours de cette réunion, les demandes fonctionnelles sont

déterminées par le client et sont matérialisées à travers des scénarios d’utilisateurs ou de

« user-stories43» notés sur des « story-cards44 ». A ce stade, l’équipe évalue la charge de travail

relative à chaque scénario en termes de points (le nombre de points est attribué en fonction de

la difficulté du scénario) et communique au client une estimation de sa vélocité 45. Ensuite,

conjointement avec le client, l’équipe décide des scénarios à implémenter dans la prochaine

itération (Beck & Andres, 2004, p.45).

Cycle hebdomadaire : le cycle de planification hebdomadaire consiste à évaluer

l’avancement du projet par rapport aux attentes des parties prenantes; à identifier les

« stories » à implémenter dans le prochain cycle et à décomposer celles-ci en tâches

attribuables aux membres de l’équipe.

Livraisons itératives et incrémentales : le projet est décomposé en plusieurs itérations où

chacune regroupe un ensemble limité de fonctionnalités. La version produite est rajoutée à la

version précédente minimisant ainsi les coûts de déploiement « big deployment have a high

risk and high human and economic costs » (Beck & Andres, 2004, p.63).

Stand-up meeting : c’est une réunion quotidienne de quinze minutes, se déroulant, en

principe, dans un espace ouvert (de type plateau) occupé par les développeurs. Durant ces

réunions, les développeurs sont amenés à partager leurs expériences concernant la journée

précédente et à décider collectivement des tâches futures à réaliser. Les séances de travail en

binômes (le « pair programming ») sont également planifiées au cours de cette réunion.

Conception simple incrémental : la conception est réalisée de façon simple et incrémentale.

Les duplications doivent être éliminées 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 don’t find yourself in the situation where you have to change the code in

several places to add one feature » (Beck & Andres, 2004, p.54).

43Les « user-stories » représentent les besoins fonctionnels. En général, les utilisateurs de l’application finale

écrivent les « user stories » en utilisant leur propre terminologie. 44Les « story-cards » représentent les cartes sur lesquelles est marqué le scénario à implémenter avec une courte

description de celui ci. Ces cartes sont ensuite affichées sur un tableau visible à toute l’équipe (Annexe V). 45Cf. page 40.


44

Tests unitaires et fonctionnels : les tests unitaires concernent chaque classe ou portion de

codes. Ils sont écrits avant la codification et réalisés à chaque intégration. Bien que ces tests

relève d’une vision « micro » de l’application, ils permettent de vérifier si cette dernière se

comporte comme prévu (Beck, 2004). Ces tests sont automatisés et continuellement exécutés

(Beck & Andres, 2004, p. 51). Des modèles de tests unitaires, dits « xUnit », ont été

développés 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 relèvent de la tâche des

clients. Ils sont rédigés et appliqués à chaque itération. Ces tests spécifient ce que

l’application est censée faire du point de vue du client. La fin d’une itération a lieu lorsque

tous les tests sont exécutés.

Construction rapide (en 10 minutes) : les développements rapides, basés sur des tests

automatiques, permettent d’avoir un retour immédiat sur les codes développés « a build that

takes longer than ten minutes will be used much less often, missing the opportunity for

feedback » (Beck & Andres, 2004, p.49).

Déploiement quotidien : les codes développés doivent être quotidiennement mis en

production. La mise en production du logiciel permet d’avoir des retours d’informations sur la

version produite « any gap between what is on a programmer’s desk and what is in

production is a risk » (Beck & Andres, 2004, p.68).

Intégration continue : si certaines sociétés informatiques insistent à ce que l’intégration

quotidienne soit un minimum, les fondateurs de la méthode « 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 à intégrer, de façon 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 à améliorer

régulièrement la qualité du code sans en modifier le comportement. On retravaille le code

pour repartir sur de meilleures bases tout en gardant les mêmes fonctionnalités. Autrement dit,

46A notre connaissance, il n’existe pas de langage spécifique au développement « agile ». Les méthodes

« agiles », en particulier, « scrum » et « XP » sont techno-agnostiques (Antoine Contal, coach « scrum » et

« XP »).


45

il s’agit du « nettoyage » quotidien du code (élimination des duplications et amélioration de sa

lisibilité).

Métaphore : c’est une histoire simple qui décrit le projet et ses fonctionnalités. Elle relève de

l’architecture, du fonctionnement du système, etc. Une métaphore guide le processus de

développement et aide l’équipe à avoir une compréhension commune des éléments essentiels

du projet.

Programmation en paire : la production de codes se fait en binôme à partir de deux

personnes travaillant ensemble sur une seule machine, un clavier et une souris. La rotation des

paires se fait de manière 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 développés ne relèvent pas de la

responsabilité d’une personne précise. Ils sont partagés par toute l’équipe. Chacun des

développeurs peut apporter des modifications à n’importe quelle occasion. Cette pratique

responsabilise l’équipe à l’égard de l’ensemble des codes développés « 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 développement et fait partie de

l’équipe. Son rôle consiste à répondre aux questions de celle-ci, à exécuter les tests

d’acceptation et à s’assurer de la conformité des versions développées. A cet effet, il participe

aux réunions hebdomadaires organisées par l’équipe « XP » (Beck & Andres, 2004, p.61).

Règles de codage : les versions multiples de sources de codes génèrent du gaspillage. De ce

fait, il est important d’avoir une base unique de codes qui permet de réduire 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, d’autres pratiques ont été soulignés par les auteurs de la méthode « XP ». Elles

relèvent des outils du lean management : le recours à l’analyse des causes racines qui permet

de détecter les causes profondes des erreurs dans un système et d’y remédier rapidement. A


46

cet effet, la méthode des cinq pourquoi (5 whys) constitue un moyen pour cerner les causes

racines d’un problème (Beck & Andres, 2004). Un principe complémentaire fut également

mobilisé, celui du « Poka Yoke47 » ou « détrompeur ». En effet, l’écriture des tests unitaires

avant la programmation permet d’alerter les développeurs en cas d’erreurs dans l’application

« the goal is not just that this one defect won’t 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 « détrompeurs » selon la terminologie utilisée dans le lean.

2.2.1.2 Les rôles dans la méthode « XP »

Contrairement à la méthode « scrum » plusieurs rôles sont attribués aux membres d’une

équipe de développement « XP ».

Le programmeur : son rôle est d’écrire les tests unitaires et de développer 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 définition de l’architecture de l’application. Il aide

également le client à écrire et à clarifier les scénarios « user-stories ». En outre, il analyse

l’usage actuel du système et décide des besoins futurs de celui-ci. Il spécifie, en amont,

l’interface utilisateur et il se charge de son amélioration.

Le client : il est chargé d’exprimer ses besoins sous forme de scénarios et d’écrire les tests

fonctionnels. La priorisation des demandes à implémenter relève aussi de sa responsabilité

Le testeur : son rôle consiste d’une part, à assister les clients dans l’écriture et l’exécution des

tests fonctionnels et d’autre part, à « coacher » les développeurs dans les techniques de tests

unitaires.

Le tracker : il donne son feedback sur l’avancement du projet. Il souligne les estimations

effectuées par l’équipe (en termes d’efforts par exemple) et donne son avis sur la pertinence

de celles-ci dans le but d’améliorer les estimations futures. Il trace également la progression

de chaque itération et évalue les possibilités de réaliser les objectifs fixés en prenant en

compte le temps et les ressources disponibles.

47Il s’agit de petits systèmes pratiques qui permettent d’identifier immédiatement que l'on fait de la non-qualité

ou que l'on ne suit pas le standard de travail (lean.enst.fr).


47

Le coach : il a un rôle de soutien technique pour les membres « XP » lors des premières

itérations de livraison. Il guide également l’équipe dans l’application des pratiques et

principes « XP ».

Le manager : son rôle correspond à celui d’un chef de projet. Il assiste son équipe pour

affronter les difficultés rencontrées au cours de l’itération. Il doit rendre des comptes au client

sur la base des informations fournies par le tracker. Le modèle de développement « XP »

2.2.1.3 Le modèle de développement « XP »

La méthode « XP », focalisée sur la partie programmation du projet, propose un modèle de

développement itératif avec une structure à deux niveaux : d’abord des itérations de livraison

puis des itérations de développement. Les premières consistent à livrer des fonctionnalités

complètes au client tandis que les secondes portent sur les scénarios qui contribuent à la

définition d’une fonctionnalité (Morley, 2006).

Le processus est déclenché par une phase d’exploration des besoins durant laquelle le client

élabore les scénarios qu’il souhaite intégrer dans la première livraison. En parallèle, l’équipe

se familiarise avec les outils et les pratiques qui seront utilisés au cours du projet. Une phase

de planification (de quelques jours) est organisée entre l’équipe de développement et le client

pour identifier les scénarios à implémenter dans la première itération de livraison (ne doit pas

excéder les 2 mois). L’itération de livraison est ensuite découpée en plusieurs itérations de

développement de courte durée (1 à 4 semaines).

La première itération consiste à élaborer l’architecture du système général en se basant sur les

scénarios capables de renforcer la structure globale du système. Le client décide des scénarios

à implémenter dans chaque itération. Suite à cela, les tests unitaires sont écrits et automatisés

et les codes sont développés. Par ailleurs, les tests fonctionnels écrits par le client sont

exécutés à la fin de chaque itération de développement. L’itération de livraison prend fin

lorsque tous les scénarios retenus sont développés (figure II). La documentation est rédigée en

phase finale lorsqu’aucune modification n’est acceptée. Toutefois, il convient de préciser

qu’au cours du projet, les scénarios, les estimations et les tests écrits sur les « story-cards »

constituent l’unique source de documentation.


48

2.3 Le développement lean

Le modèle lean provient du best seller des années 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

managériales basées sur deux piliers fondamentaux : la production « juste à temps » et

l’« autonomation » (Houy, 2008).

Le Toyota Production System est désigné comme un système de management qui vise

l’élimination radicale du gaspillage « The Toyota production system is a management system

48Le Toyota Production System était largement ignoré même au Japon jusqu’à la crise de l’huile en 1973 parce

jusqu’qu’à ce jour, les entreprises se développaient rapidement et pouvaient vendre tout ce qu’elles produisaient.

Mais la baisse économique due à la crise d’huile a détruit un grand nombre d’entreprises. Toutefois Toyota a

réussi à s’en sortir rapidement grâce à son système de production juste à temps et à l’intérêt accordé à

l’élimination des gaspillages.

Feedback

Figure II : Processus de développement « XP »

Scénarios

Mis à jour

réguliers

Efforts

estimés

Priorités

Scénarios

pour la prochaine

itération

Base de

données

collective

Intégration

continue

Tests

Livraison (1)

Livraison mise à jour

Livraison finale

Programmation en paire

Analyse

Design

Plan des

tests

Test

Phase d’exploration

Phase de planification

Des itérations à la phase de livraison

Mise en production

Maintenance Phase finale


49

for the absolute elimination of waste…All 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 Taïchi Ohno dans les années 1970, les objectifs

essentiels sur lesquels repose ce système est la réduction des coûts de production et

l’amélioration de la satisfaction des clients. Deux principes sont dès lors mis en avant :

l’élimination du gaspillage ou tout ce qui dépasse la quantité minimale requise en termes de

matériels, d’équipements, d’espace et de temps et par conséquent ne crée pas de la valeur ; et

la valorisation des employés à travers leurs responsabilisation et leur développement continu

(Sugimori, Kusunoki, Cho & Uchikawa, 1977).

Après l’immense succès qu’a connu le système de production Toyota dans les industries

automobiles, traduit, plus tard, sous l’approche du lean management, les principes lean ont été

exportés au-delà de l’industrie automobile et se sont progressivement étendus à d’autres

services et secteurs d’activités. Aujourd’hui, l’application des principes du lean management

au développement informatique est en pleine expansion (Enquête Scrum Alliance 49, 2009).

Mary et Tom Poppendieck se sont beaucoup intéressés à la question d‘application des

principes du lean management au développement de logiciels. Dans leur ouvrage

« Implementing lean software development: from concept to cash », paru en 2006, ils

décrivent les différents principes qui constituent le « lean thinking ». Avant de procéder à la

présentation de ces principes, il apparaît judicieux de préciser que le lean development ne

renvoie pas à une méthodologie de développement et de management de projet analogue aux

méthodes « agiles ». En revanche, le lean souligne une philosophie, une manière de pensée,

basée sur des principes managériaux issus du monde industriel et appliqués au développement

de logiciels. Nous reviendrons sur cette distinction à la fin de ce chapitre.

2.3.1 Les principes du développement lean

L’élimination du gaspillage : les sources de gaspillage renvoie à tout ce qui ne crée pas de la

valeur au client. Une société de développement qui se veut lean est, tout d’abord, amenée à

49http://www.frenchsug.org/download/attachments/591296/Enqu%C3%AAte_m%C3%A9thodes_agiles_2009_F

renchSUG.pdf?version=2


50

déterminer les gaspillages de façon à réduire le « time line » ou le « lead time50 » 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, l’inventaire est considéré comme une vraie source de

gaspillage nécessitant un entretien, un transfert, un stockage, des recherches. Les stocks

rajoutent de la complexité au processus de production car ils risquent de devenir obsolètes, de

cacher des problèmes de qualité et de se perdre. D’où l’intérêt de réduire au maximum la

présence de stocks inutiles. Appliqué au développement de logiciels, le développement de

fonctionnalités 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 générant des surcoûts. Il est donc important de

mettre en place un processus où 20% des codes développés 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). D’autres types

de gaspillages ont été identifiés en développement de logiciels (Poppendieck, 2003, 2006).

La qualité intrinsèque : d’un point de vue lean, les codes développés doivent être, dès le

départ, de bonne qualité. En ce sens, l’organisation est amenée à anticiper les problèmes 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 d’inspection pour

améliorer la qualité des produits: l’inspection visant la prévention des défauts et l’inspection

au moment où les défauts apparaissent (Shigeo Shingo, 1981 dans Poppendieck, 2006). Il est,

primordial de contrôler les conditions de production afin d’éviter l’occurrence des défauts.

Mais lorsque cette possibilité ne se présente pas, il devient indispensable d’inspecter le

produit à chaque étape du processus pour détecter rapidement les défaillances et par

conséquent éviter que ceux-ci affectent toute la ligne de production « If you really want

quality, you don’t 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 d’outils 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).


51

lean : l’Andon51, la culture stop-the-line52, la méthode des 5P53, le pareto des causes54, l’A3

problem solving55.

Les méthodes « agiles » ont elles aussi mis l’accent sur le principe d’anticipation et d’analyse

des processus défaillants. Le développement conduit par les tests, par exemple, permet de

réduire les risques d’erreurs dans les applications développées « 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

didn’t track whether a reported defect was caused by code written before or after TDD »

(Mike Cohn dans Poppendieck, 2006). Cependant, la vérification des codes demeure une

activité indispensable. Les tests fonctionnels, l’intégration continue, le remaniement des codes

ou encore la revue de l’itération constituent des moyens pour identifier, au plutôt, les erreurs

produits et améliorer la qualité du produit final.

Amplifier l’apprentissage : d’un point de vue lean, le développement de logiciels relève

d’un processus continu de création et d’acquisition de connaissances. Si au départ d’un projet,

l’architecture de l’application est globalement conçue, elle ne se précise qu’après le

développement des codes. Dans cette perspective, il apparaît judicieux de réaliser la

conception détaillée en parallèle avec l’activité de programmation. Par ailleurs, divers

pratiques et outils ont été mis en œuvre en vue de favoriser l’apprentissage : les ateliers

kaizen56 qui permettent la résolution collective des problèmes et l’amélioration continue, le

développement itératif et les réunions quotidiennes qui favorisent les feedback continus, l’A3

problem solving qui consiste à capturer les connaissances critiques et à les stocker dans une

base de données accessible à tout le monde.

51Corde d’alerte, située généralement au-dessus de chaque opérateur, qui permet d’envoyer un signal visuel et/ou

sonore à son superviseur pour l’avertir de la présence d’un problème sur la chaîne de production. L’Andon se

trouve au cœur de la démarche de résolution de problèmes (Houy, 2009). 52« Stop-the-line » implique l’arrêt de la chaîne de production au moment où une défaillance dans le système ou

un problème apparait. La production est reprise après la résolution collective du problème. 53La méthode de base de résolution de problèmes du lean. Ohno insiste souvent sur la nécessité de se poser cinq

fois la question "pourquoi?" pour aller au-delà des causes symptomatiques et trouver les causes fondamentales

(lean.enst.fr). 54Outil visuel permettant de visualiser les causes des problèmes et de trouver, en fonction de leur fréquence

d’apparition, celles à traiter en priorité. Cet outil obéit à la loi 20/80 où 20% des causes produisent 80% des effets. 55Document basé sur un format A3 où sont capturées les informations relatives aux problèmes apparus

(Conditions actuelles, objectifs attendus, analyse des causes, contre-mesure, confirmation des résultats, suivi des

actions). 56Organisation des discussions en équipe pour stimuler l'amélioration continue. L'objectif du kaizen est

l'élimination du gaspillage sous toutes ses formes. Il s'agit de rendre les tâches plus simples et plus faciles à

effectuer (lean.enst.fr).


52

MacCormack (cité dans Poppendieck, 2006) identifie quatre éléments clés qui conduisent au

succès d’un projet de développement : (1) les livraisons rapides et minimales de

fonctionnalités testées par le client; (2) les constructions quotidiennes et le feedback rapide

que l’on obtient suite aux tests d’intégration, (3) une équipe ou un chef d’équipe bien

expérimenté capable de prendre les bonnes décisions au bon moment et (4) une architecture

modulaire permettant l’intégration facile de nouvelles fonctionnalités. Nous retrouvons

toutefois ces principes dans les méthodes de développement « agiles » présentées plus haut :

« scrum », « extreme programming ».

Décider le plus tard possible : une entreprise lean estime que, dans un projet de

développement informatique, les décisions doivent être reportées jusqu’à la collecte maximale

d’informations. Elles doivent être réversibles et facilement modifiables. Dans cette

perspective, le développement itératif porté par le courant « agile » consiste à surmonter les

phases d’analyse et d’anticipation « paralysantes » pour s’appuyer sur des solutions concrètes

améliorant ainsi les prises décisions (Poppendieck, 2006). Dans un processus de

développement instable et complexe il est indispensable que l’équipe dispose d’un ensemble

d’options lui permettant de retarder les prises de décisions irréversibles. Pour Taiichi Ohno,

les plans élaborés au départ d’un projet sont facilement modifiables et souvent, les activités

qui en découlent, changent de direction pour répondre aux circonstances et conditions de

l’environnement. De ce fait les entreprises qui se basent sur des plans très détaillés encourent,

de nos jours, le risque d’être dépassées « 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 réduction des délais de livraison permet aux entreprises d’améliorer

leur compétitivité sur le marché technologique. Dans cette optique, le style de développement

itératif et incrémental permet, outre la vérification rapide de la version fonctionnelle

développée, de répondre assez rapidement aux demandes des clients qu’ils n’ont pas le temps

de changer d’avis « We need to figure out how to deliver software so fast that our customers

don’t have time to change their minds » (Poppendieck, 2006, p.34). Souvent les sociétés de

développement informatique ont du mal à conjuguer la rapidité et la qualité des produits

développés. Il est donc important, d’un point de vue lean, de développer les personnes afin

qu’elles soient capables de prendre les bonnes décisions, de répondre rapidement aux

changements et d’améliorer, de façon continue, la qualité des livrables « If you want to go


53

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 sixième principe est mis en avant :

le respect des personnes.

Le respect des personnes : l’une des caractéristiques clés du système de production Toyota

est l’intérêt porté aux personnes et en particulier aux opérationnels œuvrant au « bas de

l’échelle ». Une organisation lean incite à respecter les gens et à les valoriser en les rendant

plus autonomes, les développant et les faisant participer aux décisions. En effet, ce principe

fut également souligné par les partisans de la méthode « scrum » et « XP » qui encouragent

l’auto-organisation des équipes de développement. Dans cette optique, le management

scientifique « taylorien » « the one best way » est remis en cause et remplacé par une

organisation contribuant au développement de ses salariés. Dans une perspective

d’organisation lean, les acteurs sont amenés à mobiliser leurs connaissances et leurs

expériences passées pour réagir plutôt que de se limiter aux consignes standardisées. Pour les

Poppendieck (2006), le « one best way » n’existe pas dans la mesure où chaque processus

nécessite continuellement des améliorations « There is no such thing as one best way »

(Poppendieck, 2006, p.38).

Un dernier principe majeur du lean management renvoie à l’optimisation de l’ensemble de

la chaîne de valeur57 « 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 conséquent l’idée d’optimiser de manière

séparée les différents silos d’une chaîne de valeur ne génère pas forcément des résultats

satisfaisants.

Après la présentation des fondements du « lean thinking » dans le développement

informatique, il nous paraît utile de revenir sur le principe d’élimination de gaspillage qui

constitue l’un des piliers fondamentaux du modèle lean. Les échecs répétitifs dans les projets

informatiques ont conduit les praticiens à s’intéresser de près à leurs causes et conséquences.

Sept types de gaspillage ont dès lors été identifiés. Signalons que ces sources ont tout d’abord

été répertoriées en industrie automobile par Shigeo Shingo pour ensuite être appliquées aux

industries de logiciels (Poppendieck, 2006).

57La chaîne de valeur est l'ensemble des activités indispensables pour la réalisation d'un produit.


54

2.3.2 Les sept sources de gaspillage

En ce qui concerne les sources de gaspillages identifiées en usine, nous retrouvons: la

production excessive, les attentes, les transports inutiles, les processus supplémentaires, le

travail partiellement effectué, les mouvements inutiles et les productions défectueuses. Le

tableau (3) illustre les sept sources de gaspillage identifiées en industrie automobile et

appliquées au développement de logiciels.

Tableau 3: Les sept sources de gaspillage (Poppendieck, 2003; 2006)

Gaspillage en industrie automobile Gaspillage dans le développement

Production excessive (Overproduction)

Trop de fonctionnalités (Extra features)

Attente (Waiting)

Retards (Delays)

Transports inutiles (Transportation)

Transfert (Handoffs)

Processus supplémentaires

(Extra processing)

Réapprentissage, reprogrammation

(Relearning)

Inventaire, stock (In-process inventory)

Travail partiellement fait (Partially done work)

Mouvements inutiles (Motion)

Déplacement, changement de tâches (Task switching)

Production défectueuse (Defects)

Défauts non détectés par les tests (Defects)

En développement de logiciels, la production excessive se manifeste par le développement

de fonctionnalités supplémentaires et de documents inutiles. Comme en industrie automobile,

la surproduction constitue la pire forme de gaspillage induisant des augmentations des coûts

et des complications techniques au niveau du système développé: tests supplémentaires,

maintenance, obsolescence des codes, etc. L’adoption d’un style de développement itératif et

la mise en place d’un système « pull58» limitent la surproduction de fonctionnalités

(Poppendieck, 2006, p.73).

L’attente constitue une deuxième forme de gaspillage se traduisant par des retards dans le

développement et la livraison des produits. Dans une usine, les attentes concernent surtout les

pièces, les outils, les instructions, etc. En revanche, dans une société de développement

informatique, les attentes relèvent de la disponibilité des personnes, des informations

58Ce système initialement adopté chez Toyota consiste à tirer la production par la demande.


55

recherchées, etc. En effet, un projet de grande taille, une mauvaise synchronisation entre les

équipes et/ou une structure hiérarchique « rigide » peuvent générer des temps d’attente dans

les prises de décision et des goulots d’étranglement sur certaines phases du projet. Dans cette

optique, le style de développement itératif et incrémental permet de réduire l’écart entre les

différentes phases du processus et de livrer, rapidement, une version fonctionnelle du produit

(Beck, 1999 dans Poppendieck, 2003).

Les transports inutiles dans l’industrie illustrés par les déplacements physiques de pièces

engendrent des interruptions ou ralentissements dans la chaîne de production, des pertes de

pièces et des goulots d'étranglement (Godefroy & Chabiron, 2006). En développement

informatique, les déplacements inutiles concernent surtout les allers-retours des mails, les

échanges de documents entre les membres d’une équipe entraînant une perte considérable

d’informations 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 réunions quotidiennes de courte durée, la programmation en paire, le partage

collectif de codes, l’implication du client, le management visuel (matérialisé par des tableaux

de bord partagé, des post-it, des graphes, etc.) et les ateliers kaizen peuvent améliorer la

coordination entre les membres d’une équipe, favoriser le transfert de connaissances tacites

(Poppendieck, 2006), diminuer le temps de recherche des informations et créer une vision

commune du projet.

Les étapes supplémentaires dans un processus de développement sont dues aux arrêts et

reprises d’un même travail, aux activités redondantes, à un manque de standardisation et à une

documentation inutile (Poppendieck, 2003). Le réapprentissage et le retravail, entravent le

planning et induisent des retards et une baisse de productivité de l’équipe. A cet effet, la

capitalisation sur les connaissances (A3 problem solving, standardisation et amélioration

continue des bonnes pratiques), les courts cycles de développement, le remaniement des

codes, l’intégration continue et les feedback semblent réduire le retravail et le réapprentissage.

En outre, l’implication du client dans le processus de développement diminue également le

retravail et les modifications au niveau des codes implémentés (Middleton, F laxel &

Cookson, 2005).


56

Les stocks inutiles nécessitent de l’espace et engendre des coûts supplémentaires en industrie

automobile. Quant au développement de logiciels, l’inventaire représente le travail

partiellement effectué, la documentation excessive non utilisée et les codes non testés ou

déployés. Ces formes variées de gaspillage requièrent des investissements financiers, humains

et techniques et encourent le risque d’obsolescence. A cette fin, il semble utile de réduire les

demandes prises en compte, le nombre de codes développés (Middleton, Flaxel & Cookson,

2005) en adoptant de courts cycles de développement (Poppendieck, 2006). En outre, la

communication permanente entre les membres de l’équipe et la création d’un environnement

informatif permettent d’une part, de réduire la documentation et d’une autre, de clarifier les

besoins réels du client. Toutefois, certaines entreprises exigent une traçabilité des

spécifications et des codes, autrement dit, la documentation de ceux-ci. Il est donc

recommandé, dans de telles situations, de convertir les spécifications requises en des tests

exécutables et de recourir à des outils (framework for integrated tests59) permettant de

procurer une traçabilité des codes testés (Poppendieck, 2006).

La multiplication des réunions, l’excès de procédures, les déplacements physiques, la

réalisation de diverses tâches simultanées, constituent une autre forme de gaspillage : les

mouvements inutiles ou motion. En effet, la prise en charge de tâches variées empêchent les

acteurs concernés à réaliser 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) décrit dans l’ouvrage des Poppendieck (2006) :

imaginons qu’une personne décide de réaliser simultanément trois tâches différentes où

chacune est fixée à une durée d’une semaine. Dans le cas idéal, aucune de ces trois tâches ne

sera réalisée dans les délais. Outre le temps perdu en « jonglant » entre les tâches, la valeur

potentielle créée est également anéantie.

Si la polyvalence des membres d’une équipe est valorisée par certaines méthodes « agiles »,

« scrum » par exemple, il semble être important de réduire, au cours d’une itération, la

rotation des individus sur des activités différentes. En outre, les pratiques comme le « client

sur le site », les réunions quotidiennes et le partage virtuel des tableaux de bords, permettent

59Il s’agit d’un outil open source qui automatise les tests fonctionnels des clients. Il intègre le travail des

analystes, des clients, des testeurs et des développeurs.


57

de réduire les réunions de longue durée et les déplacements physiques en assurant un suivi

régulier du projet (Poppendieck, 2006).

Et enfin, un dernier type de gaspillage commun au développement informatique concerne les

défauts non repérés dans les codes, retardant ainsi la livraison de la solution informatique et

augmentant les coûts de développement. A cet effet, les tests unitaires écrits avant le codage

constituent ce qu’on appelle en industrie automobile les « détrompeurs » ou « mistake-

proofing » (Poppendieck, 2006). Ces tests démontrent si les codes fonctionnent comme prévu.

Bien que le « test-driven development » permette de réduire les défauts dans le système, il

n’empêche pas complètement la survenue de ces derniers. Toutefois, la détection rapide d’un

défaut critique après le codage est plus tolérée qu’un défaut minime découvert plus tard dans

le processus de développement (Poppendieck, 2006). Par conséquent, les tests fréquents et

l’intégration continue des codes permettent de déceler rapidement les erreurs et de vérifier

continuellement le fonctionnement de l’ensemble des codes développés et intégrés.

Les types de gaspillages reformulés par les Poppendieck s’apparentent aux problèmes

auxquels les méthodes « agiles », en particulier « scrum » et « extreme programming » ont

tenté de remédier. De fait, nous constatons que les pratiques et outils « agiles » peuvent mettre

en pratique les principes lean et répondre aux diverses formes de muda60 remontés en

développement informatique. L’ensemble de ces trois approches offre un bon panorama du

courant « agile ».

60Terme japonais signifiant gaspillage

Semaine 4

Tache A

Tache B

Tacj Tache C

Semaine 1 Semaine 2 Semaine 3

Figure III: « Jonglage » entre trois taches de délai d'une semaine chacune


58

Toutefois, nous constatons que le lean development représente une approche plus globale que

les méthodes « XP » et « scrum ». Avant de justifier notre propos, il nous paraît opportun de

comparer les méthodes « XP » et « scrum ».

2.4 « Scrum », « xp » et le développement « lean » : différences et complémentarité

Au delà des pratiques d’ingénierie non couvertes par la méthode « scrum », des différences

subtiles existent entre les méthodes « scrum » et « XP ». Le tableau (4) souligne ces

principales dissimilitudes.

Tableau 4 : Différences entre « XP » et « scrum »

Méthode « XP » Méthode « scrum »

Durée de l’itération (1 à 2 semaines) Durée de l’itération (2 à 4 semaines)

Les changements des fonctionnalités durant l’itération ne sont pas acceptés

Possibilités de changements des scénarios ou des fonctionnalités à implémenter au cours de

l’itération

Différents rôles sont attribués aux membres de l’équipe « XP » (programmeur, testeur, coach,

manageur, etc.)

Les membres de l’équipe sont pluridisciplinaires et seuls trois rôles sont définis (« scrum-

master », « product-owner » et l’équipe)

Pratiques managériales, pratiques d’ingénierie et outils de collaboration et de support au

management

Pratiques managériales et outils de collaboration

et de support au management

En revanche, ces deux méthodes valorisent la transparence, l’inspection et l’adaptabilité des

projets informatiques. Elles privilégient le travail d’équipe, les feedback continus et les

ajustements rapides aux changements. Elles concernent particulièrement les équipes de taille

réduite (4 à 10 personnes) où la communication et la coordination, entre les membres d’un

projet, sont faciles à réaliser. Le client se trouve au cœur de ces deux approches. Il participe à

la définition et à la priorisation des fonctionnalités. Si la méthode « scrum » attribue un statut

au représentant du client « product owner », la méthode « XP », quant à elle, se contente de

mettre l’accent sur le rôle qu’il occupe.

Le couplage « scrum » et « XP » semble améliorer très sensiblement la qualité des logiciels

livrés et créer une culture renforçant le sentiment de partage d’objectifs communs. Ces deux

méthodes s’avèrent complémentaires selon certains praticiens (Schwaber & Beedle, 2002 ;


59

Fitzgerald, Hartnett & Conboy, 2006a). Si la méthode « XP » constitue un support pour les

pratiques d’ingénierie et les aspects techniques du logiciel, la méthode « scrum », quant à ses

pratiques, renforce la planification et l’évolution du projet.

Para ailleurs, en ce qui concerne le développement lean, celui-ci s’inscrit dans une perspective

plus globale valorisant essentiellement la détection et l’anticipation des problèmes ainsi que la

réduction des différentes formes de gaspillages.

La démarcation entre l’approche lean et les méthodes « agiles » demeure, à l’heure actuelle,

floue. Alors que pour certains praticiens, le développement lean fait partie des pratiques

« agiles » (Jalali & Wohlin, 2010), pour d’autres, ces deux approches se situent à différents

niveaux : le lean renvoie à une philosophie et à un ensemble de principes tandis que les

méthodes « agiles » se caractérisent par leur pragmatisme (Morien, 2005 ; Poppendieck,

2003 ; 2006). A ce titre, le lean regroupe un ensemble de principes qui guident le

développement « agile » de logiciels et contrairement aux pratiques valorisées par les

méthodes « agiles », les principes qu’il sous-entend sont invariables (Poppendieck, 2006). Il

lean est, dès lors, appréhendé comme un outil indispensable pour guider et adapter les

pratiques « agiles » à différents contextes.

Pour d’autres praticiens en développement de logiciels, ce sont les visées et les périmètres qui

différencient les approches lean et « agiles » (Highsmith, 2002 ; Smits, 2007 ; Serignese,

2011). Selon eux, les méthodes « scrum » et « XP » concernent particulièrement les pratiques

d’ingénierie et de management de projet relatives au développement de logiciels tandis que le

lean, relève d’une approche globale et holistique, s’intéressant à l’organisation dans son

ensemble et allant au-delà des activités de développement informatique. Dans cette optique, le

développement lean est perçu comme le précurseur des méthodes « agiles » (Serignese,

2001). Les principes soutenus par ce premier concernent les différents niveaux d’une

organisation sans toutefois se limiter à un service bien précis. A cet égard, la mise en place

des pratiques « agiles » peut être gouvernée par les principes lean (Ambler, 2009 ; Ambler &

Kroll, 2009 ; Wang, 2011). La gouvernance lean semble faciliter la scalabilité des pratiques

« agiles » et par conséquent leur intégration dans une entreprise (Smits, 2007).

Ainsi, le development lean renvoie à un mode de pensée qu’une organisation va

progressivement intégrer dans sa culture organisationnelle et managériale. Les principes

valorisés par cette approche managériale peuvent être déclinés sous différentes manières en


60

fonction des contextes. Bien que le lean s’appuie sur différents outils exportés de l’industrie

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 méthodes

« agiles » en particulier « scrum » et « XP ».

La description de ces trois approches souligne clairement les fondements à l’origine du

courant « agile ». Le tableau (5) illustre de façon globale les éléments structurants de chacune

des trois approches retenues.

Si de nombreuses sociétés informatiques ambitionnent de mettre en place une démarche de

développement lean, beaucoup d’entre elles ne rencontrent pas les résultats attendus. A

l’instar de l’industrie automobile, la déclinaison des principes lean sur des systèmes

« rigides » et « traditionnels » peut engendrer beaucoup de problèmes et de disruptions au

niveau du système de développement (Womack & Jones, 1990 dans Poppendieck, 2003 ;

Qumer & Henderson-Sellers, 2008).

Afin de clarifier notre compréhension de ces nouvelles formes de développement et de

management de projet informatique, nous proposons d’examiner les résultats des travaux

empiriques qui ont été consacrés à ce sujet.

61Des systèmes d’étiquettes ayant pour objectif d’envoyer une indication aux unités de production en amont de la

chaîne de production pour leur signaler la consommation de leurs produits (Houy, 2009).


61

Tableau 5: Éléments structurant des approches : « scrum », « xp » et « lean »

Scrum (Schwaber, 2004) XP (Beck, 2004) Lean (Poppendieck, 2006)

Principes Transparence, suivi et

adaptation

Principes Communication, simplicité,

feedback, respect et courage.

Principes

Élimination du gaspillage, livraison rapide, qualité intrinsèque, gestion des

compétences, responsabilité des personnes et optimisation de

l’ensemble.

Pratiques managériales Réunions quotidiennes,

réunions de planification de l’itération, revue de

l’itération et rétrospective de l’itération.

Pratiques d’ingénierie Conception simple

Tests unitaires et fonctionnels

Remaniement des codes Déploiement quotidien Intégration continue.

Pratiques issues des méthodes «agiles »et du lean

management

Système pull, développement piloté par les tests,

développement itératif, sessions kaizen.

Pratiques de collaboration Planning game, stand-up

meeting, programmation en

paire, appropriation collective des codes, client sur le site.

Artefacts Product-backlog, sprint-

backlog, burndown charts.

Artefacts Story-cards, story-board, user-

stories.

Artefacts L’andon, value stream mapping, pareto des causes, 5 Pourquoi,

A3 problem solving.

62

63

CChhaappiittrree IIII :: AAnnaallyyssee ddee llaa mmiissee eenn pprraattiiqquuee ddeess

«« iinnnnoovvaattiioonnss mmaannaaggéérriiaalleess »»

Ce chapitre met en perspective nombre de travaux rendant compte de l’implémentation des

méthodes « agiles ». Il comprend trois sections.

Dans la première, nous présentons les principaux résultats de la mise en pratique des

méthodes « agiles ». Nous recensons les résultats concernant les pratiques et outils « agiles »

les plus étudiés et analysés.

Dans la deuxième section, nous examinons les recherches menées auprès d’un échantillon

d’entreprises de type « agile » et « traditionnel ». Les résultats comparent les principaux

problèmes rencontrés par chacune des équipes « agiles » et « classiques ».

Dans la troisième session, nous passons en revue les recherches concernant l’application des

méthodes « agiles » sur des équipes géodistribuées. Nous remontons les principaux défis

rencontrés par ces dernières et les solutions respectives proposées par les experts en

développement de logiciels.

Chapitre II : Analyse de la mise en pratique des « innovations managériales »

64

Si les recherches menées sur les méthodes « agiles » se sont fortement multipliées ces

dernières années, elles n'ont pas toutes la même portée et ne présentent pas la même qualité.

Certains articles descriptifs se sont attachés à décrire l’environnement dans lequel œuvrent les

équipes « agiles » et à analyser les effets d’usage de ces méthodes sur la productivité des

équipes et sur l’organisation en général. Des écrits, davantage prescriptifs, ont posé les règles

d’application des pratiques et outils « agiles ». D’autres études comparatives se sont attachées

à évaluer les divers aspects des projets « agiles » et « classiques ». Des travaux empiriques

récents se sont intéressés, quant à eux, à l’implémentation des méthodes « agiles » au sein

d’équipes de développement distribuées géographiquement.

Les différentes sources retenues pour cette revue de la littérature 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 d’actes

de conférences (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 synthétisons les résultats d’un grand nombre d’études ayant traité de la

mise en pratique des méthodes « agiles ».

1. Les pratiques « agiles » les plus référencées : avantages et limites

Trois éléments structurant des méthodes « agiles » ont fait l’objet de notre analyse

bibliographique. Les pratiques d’ingénierie (le développement piloté par les tests et

l’intégration continue) ; les pratiques de collaboration et de coordination (le développement

itératif, la programmation en paire, le client sur le site et les réunions quotidiennes) et enfin

les outils de collaboration et de support au management (« story-board », le « product-

backlog » et les outils d’analyse collective des causes racines).


65

1.1 Les pratiques d’ingénierie

1.1.1 Le développement piloté par les tests et l’intégration continue

Deux pratiques d’ingénierie, valorisées par la méthode « XP », ont fait l’objet de nombreux

écrits : les tests unitaires et l’intégration continue. Les tests unitaires sont des tests écrits pour

chaque classe ou portion de codes et sont réalisés à chaque intégration ; quand à l’intégration

continue, elle vise à ce que le système, dans son intégralité, soit régulièrement et

fréquemment, assemblé puis testé. Selon certains experts en développement de logiciels, ces

deux pratiques s’avèrent indispensables pour garantir la qualité des codes et augmenter les

chances de réussite du projet (Poppendieck, 2006 ; 2009).

En effet, le développement piloté par les tests semble améliorer la transparence et la qualité

des codes produits (Tessem, 2003 ; Karlström & Runeson, 2005; Lejeune, 2006 ; Petersen &

Wohlin, 2009 ; Poppendieck, 2006, 2009 ; Beavers, 2007 ; Middleton & Joyce, 2010),

procurer un feedback rapide sur les codes développés (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

réduire les coûts liés à la découverte tardive des anomalies (Poppendieck, 2009). Quant à

l’intégration continue, elle permet de résoudre les erreurs dès leurs apparitions et d’éviter les

problèmes résultant des intégrations réalisées à la fin du projet (Simons, 2002). En outre, ces

deux pratiques s’avèrent des mécanismes de communication essentiels pour les équipes

distribuées (Berczuk, 2007).

Toutefois, les tests unitaires et l’intégration continue présentent des limites : d’une part,

l’écriture des tests unitaires n’est pas une tâche facile à réaliser pour les développeurs peu

expérimentés (Melnik & Maurer, 2002), et d’autre part, la création d’un environnement de

tests intégrés nécessite beaucoup d’efforts techniques (Svensson & Host, 2005) spécialement

lorsque les équipes sont distribuées et utilisent des outils de programmation différents

(Paasivaara & Lassenius, 2004).

Ces deux pratiques rappellent deux outils visuels de signalement de problèmes déployés en

industrie automobile chez Toyota : le « Poka-Yoke » et l’« Andon ». Si ces pratiques

d’ingénierie se trouvent au cœur de la démarche de résolution des problèmes chez les

« agilistes », leur efficacité n’est pas toujours garantie. Leur mise en place demeure en effet


66

insuffisamment étudiée, en particulier, dans des structures larges où plusieurs équipes,

rattachées à différentes directions, sont amenées à travailler ensemble sur un même projet.

Le développement conduit par les tests exige que les développeurs aient une vision très

précise des spécifications à développer. Or, souvent, dans une structure complexe, les

personnes chargées de la définition des spécifications sont éloignées des équipes de

développement faisant accroître le risque d’une mauvaise compréhension des exigences.

1.2 Les pratiques de collaboration et de coordination

1.2.1 Le développement itératif

Une autre pratique bien référencée, encourageant la gestion du projet et la collaboration entre

une équipe et ses clients (Highsmith & Cockburn, 2001, Svensson & Host, 2005) est le

développement itératif et incrémental. Cette pratique, basée sur des cycles courts de livraison,

procure un feedback rapide sur les versions développées (Jokela & Abrahamsson, 2004 ;

Kosh, 2004 ; Karlström & Runeson, 2005), facilite le suivi du projet (Begel & Nagappan,

2007), constitue une opportunité d’apprentissage organisationnel (Middleton, Flaxel &

Cookson, 2005 ; Bahli & Zeid, 2005 ; Karlström & Runeson , 2005 ) et permet de répondre

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 problèmes

(Simons, 2002; Svensson & Host, 2005), de réduire les coûts de résolution (Smits, 2007) et la

volatilité des demandes dans un projet (Petersen & Wohlin, 2009).

Pour certains praticiens, les itérations fréquentes, combinées à la voix du client, contribuent à

d’excellents résultats au niveau du développement (Middleton, Flaxel & Cookson, 2005). En

effet, l’implémentation d’un ensemble minimum de fonctionnalités permet de réduire la

complexité et le coût de la base de codes (Poppendieck, 2006). Dans cette même optique, le

recours à la conception incrémentale réduit le nombre des décisions prises en amont (Beck,

2004) et par la suite la quantité de fonctionnalités à implémenter « every line of code costs

money to write and more money to support, it’s better for the developers to be surfing than

writing code that won’t be needed » (Sutherland dans Poppendieck, 2006, p.71).


67

En contrepartie, la coordination des différentes itérations menées en parallèle, sur différents

sites géographiques, est difficile à gérer (Karlström & Runeson, 2005 ; Sutherland, Viktorov,

Blount & Puntikov, 2007).

1.2.2 La programmation en paire

La « programmation en paire » constitue l’une des pratiques « agiles » les plus étudiées.

Comme nous l’avons déjà indiqué dans le chapitre précédent, elle consiste à ce que la

production de codes se fasse en binôme à partir de deux personnes travaillant ensemble sur

une seule machine, un clavier et une souris. Pour certains, cette pratique s’avère un moyen

utile de développement surtout lorsqu’une base unique de code est mise en place et respectée

par les membres de l’équipe (Ilieva, Ivanov & Stefanova, 2004). Elle facilite l’apprentissage

interindividuel (Tessem, 2003), améliore 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 d’une équipe (Melnik & Maurer, 2002) et permet de réduire les coûts de

développement (Cockburn & Williams, 2003) et les besoins en formation (Lindvall, Melis,

Marchesi, Basili, Boehm, Costa, Dangle, Shull, Tesoriero, Williams & Zelkowitz, 2002).

Dans une étude menée, en 2005, auprès de 122 personnes utilisant la programmation en paire

(Mannaro, Melis & Marchesi, 2005), 72 % estiment que cette pratique accélère le processus

de développement.

En revanche, le travail en binôme est perçu comme une pratique fatigante pour les

développeurs (Tessem, 2003 ; Ilieva, Ivanov & Stefanova, 2004), diminuant la productivité de

l’équipe lorsque l’écart au niveau des compétences des personnes travaillant en paire est

grand (Melnik & Maurer, 2002, Svensson & Host, 2005 ; Wellington, Briggs & Girard,

2005).

1.2.3 Les réunions quotidiennes

Pour ce qui est des pratiques de coordination et de collaboration, les réunions quotidiennes

semblent renforcer la communication et le travail collaboratif (Svensson & Host, 2005 ;

Chong, 2005), le partage d’informations (Melnik & Maurer, 2002) et la résolution collective

des problèmes (Robinson & Sharp, 2004, Sharp & Robinson, 2007). Selon certains praticiens,

ce type de réunions permet d’avoir des clarifications rapides sur l’avancement du projet et


68

assure un meilleur contrôle du projet en temps réel (Paasivaara, Durasiewicz & Lassenius,

2009). En effet, la communication en face à face occupe une place centrale dans le processus

de développement. Les échanges fréquents entre les membres d’une équipe semblent faciliter

et accélérer le transfert des idées et des informations. Dans cette perspective, les équipes de

taille réduite sont privilégiées car elles constituent un cadre idéal pour communiquer en

directe (Svensson & Host, 2005 ; Petersen & Wohlin, 2009) réduisant ainsi la documentation

inutile (Petersen & Wohlin, 2009). Certains auteurs ont précisé que les développeurs

s’appuient fortement sur la communication directe, informelle pour corriger les erreurs et les

mauvaises prévisions (Herbsleb & Grinter, 1999).

Dans cette perspective, différents facteurs ont été identifiés affectant la communication au

sein d’une équipe « agile » (Ambler, 2002b): la proximité physique (les personnes travaillant

ensemble dans un même endroit peuvent communiquer plus facilement), la proximité

temporelle (les décalages horaires peuvent entraver la communication), le moral de l’équipe

(la communication et le partage d’information sont plus efficaces lorsque le moral des

membres d’une équipe de développement est élevé), les outils technologiques compliqués

pouvant compliquer la communication et enfin l’anxiété (certaines personnes préfèrent

communiquer par téléphone ou en face-à-face pendant que d’autres privilégient la

communication par mél).

Néanmoins, certains praticiens ont souligné la rigueur et la discipline qu’exigent les réunions

quotidiennes : respect des horaires de la réunion, disponibilité des personnes (Begel &

Nagappan, 2007). De même, ces réunions sont difficiles à implémenter au sein des équipes de

grande taille (Cockburn & Highsmith, 2001 ; Begel & Nagappan, 2007) et géodistribuées

(Kircher, Jain, Corsaro & Levine, 2001 ; Yap, 2005). Une forte synchronisation au niveau des

équipes s’avère indispensable (Yap, 2005 ; Kircher, Jain, Corsaro & Levine, 2001) ainsi

qu’une infrastructure technologique de qualité, favorisant la communication et les échanges à

distance, est fort recommandée (Jensen & Zilmer, 2003 ; Braithwaite & Joyce, 2005 ; Yap,

2005 ; Fowler, 2006).

1.2.4 Le client « sur le site »

Une dernière pratique qui a été appréhendée dans de nombreux travaux de recherche sur les

méthodes « agiles » est l’implication du client sur le site. La collaboration avec le client se

trouve au cœur du manifeste « agile » (Abrahamsson, Salo & Ronkainen, 2002). Ce principe a


69

cependant été décliné sous des pratiques ou rôle propre à une méthode « agile » : « Joint

Application Development » (RAD), « on-site customer » (XP), « product-owner » (scrum),

etc. Cette pratique favorise les feedback continus (Karlström & Runeson, 2005), perfectionne

la qualité du produit (Rising & Janoff, 2000) en réduisant le nombre de fonctionnalités

inutiles et non acceptables (Hilkka, Tuure & Matti, 2005) et améliore la satisfaction des

clients par rapport au produit développé (Mann & Maurer, 2005 ; Sillitti Ceschi, Russo &

Succi, 2005). Les feedback fréquents accélèrent l’apprentissage organisationnel et facilite la

réduction des variations dans les processus et les produits. En outre, les clients semblent

apprécier leur participation active aux projets (Ilieva, Ivanov & Stefanova, 2004). Du point de

vue des développeurs, cette pratique est également perçue comme utile, car leur offrant la

possibilité de consulter le client à n’importe quel moment (Koskela & Abrahamsson, 2004 ;

Svensson & Host, 2005 ; Mann & Maurer, 2005, Karlström & Runeson, 2005) et réduisant les

conflits potentiels (Melnik & Maurer, 2002). Les développeurs estiment important d’avoir

une personne expérimentée prête à accompagner les clients dans le processus « agile » de telle

manière à les préparer et les aider dans la définition des demandes (Mann & Maurer 2005).

Néanmoins, dans un environnement distribué, la proximité entre le client et l’équipe de

développement n’est pas faisable. Certains praticiens ont évoqué le terme de client virtuel,

jouant le rôle du client sur le site et accompagnant l’équipe de développement virtuellement

(Simons, 2002 ; Sutherland, Viktorov, Blount & Puntikov, 2007). Des difficultés ont

également été reportées relevant de l’indisponibilité 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 compétences techniques que celui-ci

doit posséder pour d’un côté, prendre les bonnes décisions dans le choix et la priorisation des

fonctionnalités et d’un autre côté, réaliser l’écriture des tests fonctionnels (Tessem, 2003).

Pour Beck (2004), un client virtuel ou « proxy » peut constituer un gaspillage lorsque les

fonctionnalités développées ne sont pas utilisées ou si les tests spécifiés ne respectent pas les

critères d’acceptation. En outre, certains praticiens ont remis en cause la nécessité d’une

présence permanente du client sur le site de développement. Selon certaines études, seuls 21

% des efforts des clients sont nécessaires pour assister l’équipe de développement (Koskela &

Abrahamsson, 2004). Il semble également difficile qu’un client puisse représenter l’ensemble

des utilisateurs d’une application donnée (Stephen & Rosenberg dans Koskela &

Abrahamsson, 2004).


70

Nous remarquons que malgré les avantages que présente chacune de ces pratiques de

collaboration, leur mise en place, dans un environnement géodistribué, reste difficile. Face à

ce constat, certains questionnements méritent d’être approfondis : comment aligner le mode

collaboratif d’une équipe de développement « agile » au mode de fonctionnement d’autres

équipes impliquées dans un même projet ? Comment réaliser des réunions quotidiennes dans

une équipe dont les membres sont engagés dans différents projets ? Sur quel critère faut-il se

baser pour choisir les participants à ces réunions lorsque les équipes s’avèrent de grande

taille ?

Le concept d’une équipe « agile » consiste en ce que les personnes occupant différents postes

(architectes, développeurs, testeurs, etc.) communiquent régulièrement entre elles, s’auto-

organisent et s’ajustent mutuellement en fonction de l’avancement du projet. Or, lorsque les

équipes recourent à des prestataires externes et à des acteurs métiers intervenant

temporairement sur les projets, le principe de collaboration visé par les « agilistes » perd de

son efficacité.

Si certaines solutions ont été proposées par les experts en ces méthodes de développement

informatique (découpage du projet par module, réduction de la taille des équipes, etc.), leur

mise en place dans des organisations complexes restent néanmoins imprécises et peu

structurées.

1.3 Les outils de support au management

Les travaux de recherches publiés sur le système de production Toyota ont accordé beaucoup

d’importance aux outils visuels de communication capables d’améliorer la transparence au

niveau des systèmes de production : détection des défauts grâce au système alerte « l’andon »,

identification de la quantité des pièces à produire en recourant aux étiquettes « kanban », etc.

Dans le domaine du développement « agile » de logiciels, ces outils visuels renvoient aux

« story-cards » et « story-board ». Leur fonction est d’assurer un environnement informatif en

représentant le flux du travail et en rendant visible et accessible, à tous les membres d’une

équipe, l’avancement du projet. Différentes informations sont habituellement renseignées

correspondant aux étapes « à faire », « en cours », « à relire » et « terminé ». Sur chaque étape

sont affichés les « story-cards » sous forme de « post-it ». (Annexe V)


71

Le « story-board » sur lequel sont affichés les « story-cards » ainsi que le « product-backlog »

semblent créer un environnement informatif améliorant la visibilité du projet (Cockburn,

2002; Robinson & Sharp, 2004 ; Sharp & Robinson, 2007, 2008, Petersen & Wohlin, 2009,

Middleton & Joyce, 2010) et assurer le suivi de l’avancement des projets. Ces outils

permettent d’avoir une vision partagée 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, d’autres instruments de gestion ont été étudiés comme les outils d’identification et

d’analyse des causes racines des problèmes. Ces derniers semblent, à leur tour, éliminer le

travail de correction et améliorer la qualité des fonctionnalités produites (Middleton, Flaxel &

Cookson, 2005).

Toutefois, le partage de ces outils s’avère difficile entre les membres d’une équipe distribuée.

Le remplacement d’artefacts physiques par des artefacts électroniques nécessite des mises à

jour régulières ainsi qu’une infrastructure technologique de qualité favorisant les échanges à

distance (Kircher, Jain, Corsaro & Levine, 2001 ; Danait, 2005, Berczuk, 2007, Paasivaara,

Durasiewicz & Lassenius, 2008, 2009).

Ainsi leur implémentation semble être efficace dans une organisation de type « plateau » où

les acteurs peuvent facilement suivre au quotidien l’évolution du projet et communiquer avec

leurs paires. Qu’en est-il des structures complexes, larges et géodistribuées ? Comment créer

un environnement informatif lorsque les membres d’une équipe sont engagés dans plusieurs

projets, rattachés à différents services fonctionnels et ne travaillent pas au même endroit ?

Quels types d’informations partager virtuellement ? Comment s’assurer que le « story-board »

est mis à jour régulièrement et parcouru par les acteurs projets ?

Bien que ces outils puissent être partagés à distance, leur contrôle est dur à réaliser dans un

environnement virtuel. Bien au contraire, ils peuvent constituer des risques de mauvaises

diffusions de l’information au cas où ils ne sont pas mis à jour correctement et régulièrement.

2. Les méthodes « agiles » v/s méthodes « classiques » : quelles méthodes privilégier ?

Après la publication des premiers ouvrages sur les méthodes « agiles », de nombreux experts

en matière de développement ont tenté de comprendre les rapports qui existent entre ces

méthodes émergentes et les anciennes approches de développement. Plusieurs hypothèses ont


72

été avancées. Si pour certains, les méthodes « agiles » constituent une alternative aux

approches centrées sur les processus ou sur la planification (Murru & Deias & Mugheddu,

2003), elles s’avèrent pour d’autres complémentaires (Turner, 2002 ; Boehm & Turner, 2003 ;

2005 ; Kähkönen & Abrahamsson, 2004). C’est dans cette perspective qu’un modèle

multidimensionnel a été proposé aux industriels afin qu’ils aient la possibilité de sélectionner

l’approche de développement 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 développement d’accroître leur productivité (Agerfalk & Fitzgerald, 2006) et

de s’adapter rapidement aux changements (Highsmith & Cockburn, 2002 ; Chong, 2005) ne

va pas dans le même sens que les résultats observés avec les méthodes « classiques » qui,

quant à elles, défendent l’idée d’un environnement stable où l’intégration des changements

constitue des coûts supplémentaires.

Comme nous l’avons précisé dans notre introduction, les approches « classiques » ont fait

l’objet de nombreuses critiques : mauvaise définition et compréhension des besoins, livraisons

tardives causées par le développement séquentiel, obsolescence des plans et de la

documentation, etc. De fait, les méthodes itératives et incrémentales constituent un moyen

pour répondre à ces problèmes et réduire les risques associés aux activités de définition, en

amont, de l’ensemble du système. Selon certaines études, les entreprises recourant aux

méthodes « agiles » jouissent d’une relation plus satisfaisante avec leurs clients contrairement

aux méthodes « classiques » (Sillitti, Ceschi, Russo & Succi, 2005). Ceci s’explique par le fait

que le client fait partie intégrante de l’équipe de développement. Par conséquent, sa

communication avec celle-ci et sa participation dans le processus de développement améliore

la qualité du système (Hikka, Tuure & Matti, 2005).

Dans cette section, nous examinons les résultats d’enquêtes menées auprès d’un échantillon

d’entreprises de type « agile » et « traditionnel ». Ces enquêtes se donnent pour objectif de

comparer ces deux approches managériales sur le plan organisationnel et managéria l et de

mettre en avant les principaux problèmes rencontrés par chacune des équipes « agiles » et

« classiques ».


73

Dans une enquête menée auprès de seize entreprises dont huit « agiles » et huit

« traditionnelles », 88% des managers « classiques62 » interrogés contre 13% de managers

« agiles », affirment que la variabilité des demandes, qui arrivent en cours du processus de

développement, constitue une vraie source de problèmes (Sillitti Ceschi, Russo & Succi,

2005). En outre, les organisations de type « document-driven » estiment avoir dépensé

beaucoup plus de ressources en termes d’efforts et de temps pour prévoir l’ensemble des

demandes sachant que dans 50% des cas, les fonctionnalités étaient mal comprises. Cette

même enquête a montré que 75% des entreprises « document-driven » recourent à des

contrats « rigides » basés sur une régulation spécifique limitant ainsi les modifications des

demandes. Dans ce type d’organisation, les interactions avec le client se limitent à la première

phase du projet durant laquelle les besoins sont identifiés. A cet effet, un contrat « fixe » est

élaboré pour stabiliser les demandes (Sillitti Ceschi, Russo & Succi, 2005). Or, les

connaissances limitées du client et son incertitude par rapport à ses besoins constituent un

problème majeur dans la définition et la clarification des demandes.

En effet, 75 % des entreprises « agiles » et 100 % des entreprises traditionnelles considèrent

que la spécification des besoins par le client est insatisfaisante. Les principaux problèmes sont

dus au manque de clarté des objectifs, à l’information partielle, aux barrières de langue et aux

problèmes de communication. Conscientes de ces dysfonctionnements, les entreprises

« agiles » adoptent une attitude différente vis-à-vis de leur client et du changement. Par

conséquent, elles recourent au développement itératif permettant au client de mieux spécifier

ses besoins au niveau de chaque itération. D’où les résultats qui montrent que les entreprises

« agiles » ont une meilleure relation avec leur client par rapport aux sociétés

« traditionnelles ».

Une autre étude comparant une entreprise « agile » et une entreprise centrée sur la

planification (Ceschi, Ceschi, Russo & Succi, 2005) a montré que les méthodes « agiles »

permettent d’améliorer les processus de management et de développement ainsi que les

relations avec le client.

Dans cette même logique, deux études se sont attachées à évaluer la productivité de deux

projets similaires, l'un basé sur une méthode de développement « classique » et l'autre sur la

méthode « XP ». La première étude a affiché 42% de gain de productivité pour les équipes

62Les managers « classiques » sont ceux qui appartiennent à des entreprises centrées sur la documentation

« document-driven ».


74

« 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 expérimentale sur quinze équipes utilisant quatre approches différentes (le cycle en

« V », la méthode évolutionnaire, la méthode incrémentale et la méthode « XP ») pour le

développement d’un même logiciel. Les différences significatives relèvent surtout des équipes

utilisant le modèle en « V » et celles recourant à la méthode « XP » : 337% de gains de

productivité ont été affichés pour les équipes « agiles ». Selon cette étude, les développeurs

« agiles » produisent 3.5 fois plus de lignes de codes que les développeurs utilisant la

méthode 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 résultats peut toutefois s’expliquer par

plusieurs facteurs : la manière dont les pratiques « XP » ont été adoptées, le niveau

d'expérience des équipes utilisant cette méthode, leur degré d'acceptation, etc.

Malgré les points de vue partagés sur l’efficacité de ces deux approches de développement,

nous constatons que les méthodes « classiques » se heurtent à divers problèmes sur lesquels

beaucoup d’experts en développement semblent s’accorder. Les entreprises qui se considèrent

capables de contourner les changements ont des difficultés à survivre dans notre

environnement actuel. Néanmoins, peu d’analyses empiriques témoignent aujourd’hui de la

« scalabilité63 » des méthodes « agiles ». Les principes de communication, de suivi et de

contrôle réguliers des projets au sens des « agilistes » sont difficiles à décliner sur des

structures d’équipes de grande taille, géodistribuées.

A ce titre, un ensemble récent d’articles a mis en lumière plusieurs retours d’expériences sur

l’application des méthodes « agiles » dans un environnement global caractérisé par des

équipes de développement distribuées géographiquement. La section suivante est consacrée à

la présentation des résultats de ces écrits.

63La scalabilité des méthodes « agiles » renvoie à leur applicabilité sur des projets et des équipes de grande taille

(http://www.aubryconseil.com/post/Les-echelles de-l-agilité).


75

3. L’application des pratiques « agiles » dans un environnement géodistribué

L’environnement de développement de logiciels est en pleine évolution. La tendance des

sociétés informatiques à s’installer sur de nouveaux marchés de développement moins

coûteux, en l’occurrence la Chine, l‘Inde, le Brésil et les pays de l’est s’accroît. Cette stratégie

de globalisation présente un grand nombre d’avantages : réduction des coûts de main

d’œuvre, diversité des profils et des compétences des développeurs, optimisation du cycle de

travail en travaillant sur différents fuseaux horaires, décomposition du travail en modules

transversaux et indépendants, etc. (Agerfalk & Fitzgerald, 2006). Si la distance géographique

constitue donc une opportunité économique et organisationnelle, elle se heurte à de nombreux

défis : distance temporelle, socioculturelle, technologique, etc.

A cet égard, un ensemble de praticiens a cherché à comprendre comment les principes

« agiles » pouvaient être déclinés sur des équipes distribuées. Bien que de nombreux experts

en développement considèrent que ces pratiques correspondent à des équipes de taille réduite

et colocalisées (Rising & Janoff, 2001 ; Cockburn & Highsmith, 2001 ; Cohen, Lindvall &

Costa, 2004), des recherches ont montré que les méthodes « agiles » et en particulier

« scrum » et « XP » pouvaient être appliquées avec succès sur des équipes larges (Farmer,

2004 ; Paasivaara, Durasiewicz & Lassenius, 2009) et géodistribuées (Kircher, Durasiewicz,

Lassenius, Jain, Corsaro & Levine, 2001 ; Braithwaite & Joyce, 2005 ; Danait, 2005 ;

Berczuk, 2007; Sutherland, Viktorov, Blount & Puntikov, 2007). En outre, de récentes

enquêtes64 menées sur l’adoption des pratiques « agiles » ont montré que celles ci étaient

majoritairement adoptées par de larges organisations. Cependant, les équipes « agiles »

géodistribuées rencontrent des problèmes spécifiques.

La communication est considérée comme un facteur critique pour le succès des projets

« agiles » (Hersleb & Grinter, 1999; Yap, 2005 ; Agerfalk & Fitzgerald, 2006). Lorsque le

développement est effectué sur différents sites, impliquant de larges équipes, les interactions

deviennent plus difficiles à réaliser compliquant ainsi les activités 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 défis majeurs dont relève le développement « agile » dans

un environnement globalisé.

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


76

Nous nous attarderons ici à présenter, d’une part, les obstacles majeurs rencontrés lors de

l’application des méthodes « agiles » dans un environnement géodistribué et, d’autre part, les

solutions respectives proposées par les experts en développement de logiciels. Pour ce faire,

nous nous sommes appuyés sur une revue systématique (Hossain, 2009) qui nous a permis

d’identifier l’ensemble des travaux à explorer et à analyser sur ce sujet.

3.1 Les principaux défis du développement « agile » distribué

Le manque d’interactions a été reporté comme un obstacle majeur auquel sont confrontées les

équipes « agiles » distribuées (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 fréquents entre les membres des équipes « agiles » géodistribuées : barrières de

langue (Yap, 2005 ; Layman, Williams, Damia & Bures, 2006), indisponibilité des équipes,

différents horaires de travail (Kircher, Jane, Corsaro & Levine, 2001, Yap, 2005), etc.

Dans cette section, nous regrouperons les causes des défis auxquels font face les membres des

équipes « agiles » distribuées. Le tableau (6) synthétise les défis majeurs reportés.

3.1.1 L’environnement technique

L’infrastructure technologique dont dispose une organisation semble fortement influencer les

activités de communication et de coordination entre les membres d’une équipe (Kircher, Jane,

Corsaro & Levine, 2001). A ce propos, de nombreux praticiens ont insisté sur la mise en place

d’une infrastructure technologique de qualité pour améliorer 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 développement de logiciels.


77

3.1.2 Les différences culturelles

Une autre difficulté reportée dans la littérature relève des divergences culturelles entre les

équipes travaillant sur des sites géographiques différents. Ces différences peuvent être

significatives et entraîner des incompréhensions et des conflits entre les acteurs. Ces

problèmes relèvent principalement des barrières de langue, des normes culturelles, des règles

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 rôle du client

La participation du client à un projet de développement global n’est pas évidente. Si les

méthodes « agiles » valorisent la collaboration étroite avec le client, celle-ci n’est pas facile à

réaliser lorsque les équipes sont séparées physiquement. Les réunions en face à face et les

échanges réguliers deviennent difficiles (Paasivaara, Durasiewicz & Lassenius, 2008)

conduisant à de mauvaises définitions des demandes et des besoins (Simons, 2002 ;

Paasivaara, Durasiewicz & Lassenius, 2008).

3.1.4 Le management de projet

Les interdépendances au niveau des différentes équipes distribuées peuvent avoir pour

conséquence des problèmes de synchronisation entre elles (Sutherland, Blount & Puntikov,

2007). Pour cela, le contrôle managérial des différents groupes devient une activité difficile à

gérer (Simons, 2002 ; Sutherland, Blount & Puntikov, 2007 ; Paasivaara Durasiewicz &

Lassenius, 2008, 2009). La volatilité des demandes, les changements au niveau des

spécifications et du design nécessitent dès lors des efforts de coordination supplémentaires et

des stratégies managériales (Herbsleb & Moitra, 2001). La division du travail en modules

indépendants comme le proposent certains praticiens se heurte toutefois à des problèmes

techniques liés à l’intégration (Herbsleb & Grinter, 1999 ; Mockus & Herbsleb, 2001). Cette

dernière nécessite une mise en place de règles de développement spécifiques et des outils

technologiques performants permettant une cohérence entre les diverses sources de codes

intégrés.


78

Tableau 6 : Défis majeurs du développement « agile » dans un environnement globalisé

Problèmes majeurs Références

Différents fuseaux horaires

-Asynchronisation des équipes

Hersleb & Grinter, 1999 ; Kircher, Jane, Corsaro & Levine, 2001 ;

Yap, 2005 ; Smits, 2007)

Infrastructure technique

-Faible échanges de données, service de réseau limité

-Manque d’outils collaboratifs

virtuels

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

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

Lassenius, 2008)

Différences culturelles

-Barrière de langue

-Vision non partagée

-Valeurs culturelles

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

(Herbsleb & Moitra, 2001; Yap, 2005)

(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 contrôle managérial

-Difficultés de synchronisation

entre les différents sites

(Kircher, Jane, Corsaro & Levine, 2001)

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

Après avoir identifié les obstacles majeurs, les praticiens ont tenté d’y répondre en proposant

un ensemble de solutions.

3.2 Les recommandations des praticiens face aux défis remontés

3.2.1 Modes de communication multiples

Comme nous l’avons déjà précisé, la communication directe et informelle occupe une place

centrale au niveau des équipes de développement. Il est donc indispensable de disposer d’une

infrastructure technologique de qualité permettant les échanges virtuels rapides (Yap,

2005 ; Braithwaite & Joyce, 2005 ; Agerfalk & Fitzgerald, 2006). Diverses technologies


79

d’information et de communication ont été suggérées 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 d’internet, vidéoconférences, whiteboard65, Twikis66, Instant Messenger67,

XPplanner68, Jira69, etc. Ces outils collaboratifs qui soutiennent les réunions fréquentes entre

les équipes distribuées (Simons, 2002 ; Braithwaite & Joyce, 2005 ; Danait, 2005; Berczuk,

2007 ; Paasivaara, Durasiewicz & Lassenius, 2009) s’avèrent utiles pour contrôler ce qui se

passe sur le site. (Paasivaara, Durasiewicz & Lassenius, 2009). Le partage en ligne d’un

« product-backlog » ou des « user-stories », par exemple, permet de réduire les

incompréhensions et d’accroître la visibilité du projet.

Les visites récurrentes sont également nécessaires, surtout durant les phases critiques du

projet : planification, tests, etc. Les déplacements 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 d’information et de communication

permettent d’améliorer la communication inter-équipes, elles ne remplacent pas la

conversation en face à face. Selon certains praticiens, les méls, bien qu’indispensables pour

les échanges, se heurtent à certaines difficultés. A titre d’exemple, le temps de réponse aux

méls peut être long en raison du décalage horaire et de l’indisponibilité du destinataire. Il

convient alors d’ajuster les horaires de travail en réduisant au maximum le décalage surtout en

phase critique du projet (Simons, 2002 ; Yap, 2005) ou même, de recourir à des règles (le

temps de réponse à un mail ne doit pas excéder les 12 heures par exemple) qui pourraient

éviter les retards (Vax & Michaud, 2008).

3.2.2 Le client virtuel

Les praticiens mettent l’accent sur le besoin d’avoir un client virtuel qui travaille et

communique constamment avec l’équipe de développement. Il doit être représenté par une

65Logiciel permettant aux utilisateurs distribués de collaborer en temps réel et de partager leurs fichiers, graphes,

etc. 66Une plateforme de travail collaboratif permettant de stocker les informations sous forme de pages web et de

pièces jointes. Localisé dans l’intranet, cet outil est sécurisant et efficace pour communiquer les différents

aspects du projet (use-cases, daily program status, burndown charts, etc.). 67La messagerie instantanée ou le dialogue en ligne permet l’échange instantané de messages textuels entre

plusieurs ordinateurs connectés. 68L’XPplanner est un outil de planification et de traçabilité pour les équipes « XP ». 69 Le Jira est un outil collaboratif permettant d’assurer le suivi et la gestion du tableau des tâches, des bugs, des

demandes d’évolution, etc. Les demandes peuvent être affichées sous forme de cartes virtuelles.


80

personne facile d’accès éprouvant un grand intérêt 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 développé afin de

mieux communiquer avec l’équipe de développement (Simons, 2002) et de prendre les

bonnes décisions relatives aux besoins du système développé (Layman, Williams, Damia &

Bures, 2006). Si pour certains, le rôle du client virtuel semble indispensable, il présente

certaines limites : un client virtuel ne peut identifier les changements dans les demandes aussi

rapidement qu’un client présent physiquement avec l’équipe (Simons, 2002). Il peut

également constituer un coût supplémentaire, s’il ne possède pas les connaissances suffisantes

pour prendre les bonnes décisions (Beck, 2004).

3.2.3 Fréquentes visites inter-sites

Les différences culturelles entre les équipes globalement distribuées peuvent être réduites à

travers des rencontres et des échanges fréquents. L’échange culturel peut être réalisé par

l’organisation de voyages inter-sites et les échanges inter-équipes contribuant ainsi à la

création d’une compréhension 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é proposés en vue de contrôler et de suivre au

quotidien l’état d’avancement des projets distribués : la décomposition du projet en modules

indépendants (Herbsleb & Grinter, 1999), la division des équipes en sous-équipes, de taille

réduite, faciles à gérer (Layman, Williams, Damia & Bures, 2006 ; Sutherland, Blount &

Puntikov, 2007 ; Beavers, 2007 ; Paasivaara, Durasiewicz & Lassenius, 2008). La

décomposition en sous-équipes, responsables d’un ensemble limité de fonctionnalités

indépendantes semblent faciliter les activités managériales. Des « mini-scrums » peuvent

également être organisés à un niveau local et des « scrums of scrum » entre les représentants

des chacun des sites (Sutherland, 2001 ; Berczuk, 2007 ; Summers, 2008).

Par ailleurs, il est important d’avoir une équipe équilibrée en termes de taille, de compétences

techniques et d’autorité dans chacune des régions concernées par le projet (Yap, 2005). Cela

permet d’accélérer les processus de prises de décisions et de résoudre rapidement les conflits

émergeant.


81

La majorité des études publiées sur l’application des pratiques « agiles » dans un

environnement global se sont focalisées sur les méthodes « XP » et « scrum ». Ces écrits ont

mis l’accent sur les défis majeurs rencontrés par les équipes « agiles » globalement distribuées

et ont reporté les retours d’expériences qui ressortent de l’applicabilité de ces méthodes dans

de tels environnements. Outre les défis majeurs et les solutions proposées, ces études ne

posent pas, de façon concrète, la manière dont les équipes ont procédé pour implémenter les

pratiques « agiles » au sein de leur contexte. En outre, ces études se sont uniquement

focalisées sur des équipes de développement. L’organisation au sens global du terme n’a pas

été prise en compte. Bien que cette revue de la littérature fournisse un ensemble de solutions

aux problèmes potentiels que les équipes de développement « agiles » distribuées peuvent

rencontrer, elle n’offre pas de modèle de gestion unifié pouvant être appliqué facilement par

des équipes œuvrant dans des conditions similaires. Le tableau (7) synthétise ces diverses

recommandations.

Tableau 7 : Recommandations face aux défis rencontrés dans un environnement globalisé

Recommandations Références

Multiples modes de communication

-Vidéo conférences, wikis, Instant Messenger, Jira, XPplanner

-Réunions en directe

(Simons, 2002 ; Braithwaite & Joyce, 2005 ; Yap, 2005 ; Berczuk, 2007)

(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)

-Fréquentes visites inter-sites (Poole, 2004 ; Sutherland, Blount & Puntikov, 2007)

Management de projet

-Décomposition du projet en modules indépendants

-Décomposition des équipes en équipes

de taille réduite

-Organisation de réunions « scrums of scrum »

(Herbsleb & Grinter, 1999)

(Sutherland, Blount & Puntikov, 2007 ; Paasivaara

Durasiewicz & Lassenius, 2008)

(Berczuk, 2007 ; Summers, 2008)

-Adhésion aux valeurs « agiles »

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

-Sites équilibrés (Yap, 2005)


82

Afin de compléter notre analyse de la littérature, nous souhaitons faire part de la manière dont

certains experts en méthodes de développement perçoivent l’applicabilité de ces méthodes

dans des environnements complexes et géodistribués.

3.3 Regard complémentaires des experts sur le développement « agile » globalisé

Nous conclurons cette section par la transcription de trois entretiens par menés Agerfalk et

Fitzgerald (2006), auprès de spécialistes en méthodes développement : David Parnas, Barry

Boehm et Matthew Simons.

Du point de vue de David Parnas

De nombreux industriels ont tenté de répondre aux difficultés majeures rencontrées dans un

environnement de développement globalisé. Pour David Parnas, les problèmes de

développement de logiciels relèvent généralement d’un déficit de communication entre les

membres des équipes de développement (programmeurs, architectes, etc.) et avec les

utilisateurs. Or face à ce problème, deux écoles de pensées ont émergé: l’une insiste sur le

développement standardisé et reposant sur la planification et la documentation extensive et

l’autre considère que le code est la seule source de documentation nécessaire « 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 défend l’idée selon laquelle une équipe de développement

ne peut uniquement se limiter à la communication orale. Il explique que celle-ci est incapable

de garantir le transfert des informations détaillées nécessaires à la production d’un logiciel de

qualité. Selon lui, il est important de recourir à des moyens permettant de produire une

documentation utile sans que celle-ci soit nécessairement abondante « the real challenge is

not to find ways to avoid documenting but to find ways to produce useful documents-

documents that take time but save more time » (David Parnas dans Agerfalk & Fitzgerald,

2006).

Afin d’avoir une vision plus large de ce sujet, les auteurs (Agerfalk & Fitzgerald, 2006) ont

décidé d’interroger Barry Boehm, fondateur de la méthode en « spirale » basée sur le pilotage

par les risques.


83

Du point de vue de Barry Boehm

Si Barry Boehm confirme le fait que le développement distribué ne relève pas d’un

phénomène récent, il affirme en revanche, qu’avec le développement radical des outils

technologiques, la communication à distance ne constitue plus un problème majeur aux

équipes de développement distribuées.

Pour Boehm, les stratégies d’anticipation des demandes de changement font preuve de peu

d’efficacité surtout lorsque les contextes s’avèrent compétitifs et incertains. A cet effet, les

pratiques « agiles » ont été mises en place pour mieux répondre aux besoins évolutifs du

marché. L’implication du client, les réunions régulières, la programmation en paire et

l’appropriation collective des codes semblent favoriser les échanges de connaissances tacites

contrairement aux activités de documentation. Si Boehm met en valeur les pratiques

soutenues par les méthodes « agiles », il ne renonce pas aux activités de documentation des

approches « traditionnelles ». Il défend le principe selon lequel un projet de développement 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 déterminer l’approche de developpement la plus appropriée

« 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 troisième entretien auquel nous nous sommes intéressés concerne Matthew Simons, le

directeur responsable de thoughtwork en Inde.

Du point de vue de Matthew Simons

Conformément à la vision de David Parnas, Simons estime que le risque d’échec d’un projet

de développement « offshore » est fortement lié à une communication inefficace. Bien que les

pratiques « agiles » soutiennent fortement les processus de communication, elles doivent

encore être complétées par une documentation brève et légère. C’est pourquoi Simons

préconise que la documentation doit comporter les détails clés du projet sans toutefois

excéder les deux pages : description textuelle des fonctionnalités, du contexte, une série de

« test-cases », etc.

Les points de vue de ces spécialistes sont cohérents avec les résultats mitigés de la revue de la

littérature. Les positions contradictoires défendues par les praticiens remettent en cause la


84

généricité de ces approches émergentes. Il nous paraît donc hâtif de tirer des conclusions sur

la portée réelle de ces méthodes et leur applicabilité d’autant plus que les recherches les plus

avancées dans ce domaine concernent les équipes de taille réduite. Les méthodes « agiles »

semblent ainsi difficiles à implémenter dans des contextes complexes, caractérisés par de

larges équipes, géodistribuées.

85

86

CChhaappiittrree IIIIII :: SSttrraattééggiiee ddee rreecchheerrcchhee :: uunnee aapppprroocchhee «« ppaarr

llaa pprraattiiqquuee »»

Ce chapitre est consacré à la présentation de notre stratégie de recherche qui vise à cerner la

question de la contextualisation interne des méthodes « agiles » en tant qu’« innovations

managériales » à travers une étude de cas menée dans la perspective de l’approche « par la

pratique ». Nous décomposons ce chapitre en deux sections.

Nous présentons, dans une première section, la perspective de la « pratique » en nous

focalisant sur l’approche de « la fabrique de la stratégie » qui se présente comme un angle de

recherche pertinent pour examiner les activités des acteurs impliqués dans la « fabrication »

et la mise en œuvre d’une démarche managériale de type « agile ».

Nous exposons, dans une seconde section, le modèle de sensemaking qui nous servira de

grille d’analyse pour mieux saisir la manière dont les acteurs font sens de ces méthodes et de

leur contexte d’application.

Chapitre III : Stratégie de recherche : une approche « par la pratique »

87

Bien que plusieurs ouvrages70 et retours d’expériences attestent de l’applicabilité des

méthodes « agiles » sur des structures d’équipes de grande taille et géodistribuées, la

généricité des modèles d’application des ces pratiques reste peu investiguée et démontrée.

Les études de cas menées sur ces nouvelles pratiques de développement rassemblent des

positionnements contradictoires. Ces méthodes ne s’appuient pas sur une base théorique

stabilisée de management de projet informatique. Le corps de connaissances sur la mise en

œuvre de ces approches émergentes demeure particulièrement flou.

Aujourd’hui, les organisations ne disposent d’aucun modèle de gestion de projet « agile »

formalisé qu’elles peuvent facilement adapter quelque soit leur contexte. Les méthodes

« agiles » invitent à un mode d’organisation qui relève d’une dynamique d’organizing. A ce

stade, une question principale nous paraît légitime :

Comment ce type « d’innovation managériale » peut-il être mis en œuvre dans une démarche

structurée de management pour constituer un dispositif formalisé favorisant l’organizing ?

Ce questionnement nous amène à définir une « stratégie de recherche ». Celle-ci renvoie à

une approche d’analyse « par la pratique » et à une étude de cas instrumentale.

Notre projet de recherche vise à comprendre les modes de « construction » d’une démarche

« agile ». La perspective de la « pratique » peut être considérée comme un angle de

recherche pertinent pour examiner, de façon approfondie, les activités des acteurs impliqués

dans la « fabrication » de ces méthodes de management de projet et leurs interactions

continues avec l’environnement dans lequel ils se trouvent.

Peu d’études ont été menées sur la manière dont les acteurs interprètent et construisent

collectivement les méthodes « agiles » à mettre en œuvre dans des structures

70Il convient de noter que les ouvrages pionniers sur les méthodes « agiles » sont écrits par les fondateurs du

manifeste « agile ». Il est donc évident que chacun des acteurs va promouvoir sa propre méthode de

développement « agile » en soulignant la supériorité de celle-ci sur les autres modèles de développement et de

management de projet informatique.


88

organisationnelles « complexes ». Dans la « boîte à outils » des méthodes « agiles » quelle(s)

instrumentation(s) privilégier ? Comment interviennent les éléments de contingence

organisationnelle dans l’implémentation des principes ingénieriques et managériaux propres

aux méthodes « agiles » ?

Afin de répondre à ces questions, il nous paraît opportun de nous intéresser à une étude de

terrain pour mieux cerner la façon dont les outils classés sous le qualificatif « agile » sont

implémentés au sein des organisations. Le choix d’une étude de cas instrumentale (David,

2000) nous paraît donc pertinent pour analyser, en profondeur, le phénomène de mise en

œuvre de ces méthodes dans des structures organisationnelles « complexes ».

La méthode des cas est un mode d’observation précis de thèmes préalablement définis par le

questionnement (Yin, 1994 dans Wacheux, 1996). Elle suppose une analyse en profondeur

des divers aspects d’une situation pour en faire apparaître les éléments significatifs et les

liens entre eux. Par ailleurs, les études de cas peuvent être classées en trois catégories

(David, 2000) : étude de cas intrinsèque, instrumentale et multiple.

L’étude de cas intrinsèque porte sur un cas à caractère unique ou très rare, suscitant l’intérêt

d’investigation du chercheur. Comme le précise David (2000), dans une étude de cas

intrinsèque, un ensemble de théories est mobilisé non pas « pour elles-mêmes » mais pour

analyser et comprendre le cas étudié. Les finalités de la recherche visent principalement la

compréhension d’un cas spécifique digne d’intérêt. Dans une étude de ce type, le cas est

souvent présélectionné en raison de sa particularité (Stake, 1995). Contrairement à l’étude

intrinsèque, l’étude de cas instrumentale traite d’une question théorique générale dans

l’objectif de fournir une nouvelle compréhension d’un phénomène ou d’affiner une théorie

émergente (David, 2000). L’étude de cas instrumentale est particulièrement préconisée dans

les situations où le chercheur veut illustrer des phénomènes préalablement définis dans un

modèle théorique. Une étude de cas peut également faire l’objet de cas multiples. Elle

consiste à identifier des phénomènes récurrents parmi un certain nombre de situations et a

pour but de parvenir à une meilleure compréhension voire une meilleure théorisation du

phénomène étudié. Elle permet au chercheur d’explorer les différences manifestées au sein

d’un même cas ou entre différents cas.

Dans le cadre de ce travail, nous souhaitons réaliser une étude de cas de type instrumental

dans une organisation souhaitant s’engager dans la voie de l’agilité. Le cas fait l’objet d’une


89

analyse contextualisée mais toujours en vue d’un intérêt externe. Il ne constitue pas l’objectif

ultime de la recherche. Cette approche nous confère une compréhension générale du

phénomène d’implémentation des « innovations managériales» de type « agile » dans un

contexte particulier caractérisé par une complexité organisationnelle. Nous avons donc

identifié un terrain de recherche présentant des traits typiques par rapport à notre objet

d’étude. Notre intention est de saisir la façon dont sont implémentées les pratiques « agiles »

dans un environnement complexe en tant que méthodes de management de projet. Pour ce

faire, nous avons décidé d’aborder le cas sélectionné dans l’approche de la perspective « par

la pratique » en se focalisant sur ce que font concrètement les acteurs chargés de la mise en

place des outils « agiles » de management de projet.

L’organisation sélectionnée pour cette étude de cas œuvre dans un environnement

technologique évolutif soumis à une pression concurrentielle accrue, nécessitant une forte

réactivité et adaptabilité des projets informatiques menés. Ne parvenant pas à respecter les

délais et la qualité imposés par les clients ainsi que les budgets alloués aux projets, la

direction a décidé d’emprunter la voie d’agilité en mettant en place un projet d’amélioration

des modes de fonctionnement de ses équipes. Le cas retenu a pour enjeu de faciliter la

compréhension de quelque chose d’autre que la particularité du cas, en l’occurrence le

développement et la mise en œuvre des pratiques managériales « agiles » dans des

configurations organisationnelles complexes. Nous reviendrons dans le chapitre (IV) sur la

présentation de l’organisation concernée par cette étude de cas.

Dans cette première section, nous rappelons les principaux éléments de l’approche par la

pratique dans laquelle s’inscrit ce travail de thèse.

La perspective de la « pratique » en sciences sociales

Depuis cette dernière décennie nous assistons, en sciences de gestion mais pas seulement, à

un véritable « practice turn ». De nombreux chercheurs en management et en stratégie ont

mis en exergue la notion de « pratique » pour étudier les organisations et comprendre, de

manière approfondie, comment les activités sont menées sur le lieu de travail (Gherardi,

2000, 2001 ; Whittington, 2003 ; 2007 ; Antonacopoulou, 2006 ; Jarzabkowski & Kaplan,

2008). Ces travaux se sont focalisés sur les micro-pratiques, les conversations et les activités

qui se trouvent au cœur des processus organisationnels « the practice notion implies a close


90

attention to the work done by people inside organizational processes…. The practice

perspective focuses on people, routines, and situated activities » (Whittington, 2003, p.118).

Différentes études ont tenté de définir le sens de la notion de « pratique ». Si pour certains

auteurs, cette notion reflète un mode d’apprentissage « people learn by doing through

constant repetition of their activities », pour d’autres elle renvoie à un champ d’activité

« practice is a word able to express the field of activity in which an individual works » ou

encore à la manière dont les activités quotidiennes sont réalisées dans un contexte déterminé

(Corradi & Gherardi & Verzelloni, 2008).

Aujourd’hui, plusieurs approches s’inscrivent 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 d’elles a introduit une pluralité de concepts et de perspectives innovantes pour

appréhender les phénomènes organisationnels en se focalisant sur les pratiques entreprises

par les acteurs en interactions continues avec les éléments de leur contexte matériel 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 collègues ont employé la métaphore de la « caravane »

(« bandwagon ») pour désigner l’existence d’un courant de recherche qu’un 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 » s’accordent sur la vision pragmatique de

la réalité et valorisent, toutes, les activités répétitives (« mundane activity ») des individus,

elles visent néanmoins des objets et thèmes de recherche variés. Parmi les subdivisions de ce

courant renseignées dans l’article « Ten good reasons for assuming a ‘Practice Lens’ in

Organization Studies » (Corradi, Gherardi & Verzelloni, 2008), nous présentons brièvement

cinq, ayant fait l’objet de multiples recherches (tableau 8). Par ailleurs, nous nous focalisons


91

davantage sur le courant de la « fabrique de la stratégie » qui nous apparaît le plus pertinent

dans le cadre de ce travail. Nous reviendrons sur ce choix dans la sous-section suivante.

Tableau 8 : Les études basées sur la « pratique »

« Label » Auteurs Objet de l’approche

La pratique comme une épistémologie : elle lie le travail,

l’apprentissage et l’innovation (« Practice stand-point »)

Brown &

Duguid (1991)

La pratique permet de comprendre les processus d’apprentissage situés. Dans

cette perspective l’apprentissage est le lien entre le travail et l’innovation.

La pratique comme une activité sociale, située.

(« Practice as a social and situated activity »)

Gherardi, Nicolini &

Odella, (1998)

Se focaliser sur les actions situées qui relèvent d’un contexte dans lequel les

relations sociales, matérielles et culturelles ont lieu.

L’approche de la « pratique » pour étudier ce que les gens font

et le produit de leurs actions (« Practice lens »)

Orlikowski,

(2000)

Observer comment les gens « énactent» la technologie et comment en l’utilisant au

cours de leurs actions sociales, ils

contribuent à l’actualiser par une relation récursive qui lie la technologie aux

actions situées et à la structure

organisationnelle.

Le savoir comme accomplissement pratique (« Knowing in practice »)

Gherardi, (2000) ;

Orlikowski,

(2002)

La connaissance n’est pas quelque chose que les gens possèdent dans leurs têtes

mais plutôt quelque chose que les gens font ensemble à travers leurs interactions

humaines et non humaines. La

participation à une pratique est un moyen d’acquérir, modifier et partager une

connaissance.

La stratégie comme pratique : ce

que font les individus («Strategy-as-practice »)

Whittington, (1996, 2006) ;

Jarzabkowski, Balogun &

Seidl, (2007).

Le courant de la « fabrique » de la stratégie cherche à étudier les

innombrables micro-actions à travers lesquelles les acteurs humains organisent

l’activité de manière à générer des

résultats stratégiques.

1. La « fabrique de la stratégie » : champ de recherche émergent en sciences sociales

Un nombre croissant de conférences et de publications récentes ont traité de la perspective

de la stratégie en pratique (cinquante deux articles publiés en 2010 contre un article en 2001,

Egos 2011). Suite à la parution de l’article de Richard Whittington dans Long Range

Planning, en 1996, le courant de « strategy-as-practice » a progressivement été popularisé.

Nous retrouvons, à l’heure actuelle, une variété de travaux de partisans de ce courant,

publiés dans des revues spécialisées dans l’étude des organisations : Organization science,


92

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

Human relations, etc. Un site web, dédié au thème « strategy-as-practice » (www.strategy-

as-practice.org), a également été développé en vue de favoriser les échanges sur le thème de

la « fabrique » de la stratégie. Aujourd’hui, un réseau international de plus de 2000 membres

(praticiens et académiciens) constitue la communauté de « strategy-as-practice » connue

sous l’acronyme (S-As-P).

Le courant de « la fabrique de la stratégie » aborde la stratégie non plus comme une

propriété 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 s’inscrivent dans le courant de la « fabrique de la stratégie » se sont

particulièrement centrés sur les acteurs et leurs interactions avec leur environnement social.

La stratégie comme « pratique » renvoie à ce que font les individus au quotidien (niveau

micro) et aux pratiques socialement définies (niveau macro) sur lesquels ils s’appuient au

cours de leurs actions (Jarzabkowski, Balogun & Seidl, 2007). Des liens explicites sont ainsi

créés entre les actions situées des individus et les contextes institutionnels dans lesquels ils

agissent et auxquels ils contribuent (Jarzabkowski, Balogun & Seidl, 2007). La stratégie

comme « pratique » peut être vue comme un souci « d’humaniser la recherche sur le

management et les organisations » en s’intéressant aux activités les plus fines des individus

qui ont un impact sur la stratégie de l’organisation (Jarzabkowski, Balogun & Seidl, 2007

dans Chanal, 2009). Avant d’aller plus loin et d’expliquer les raisons qui justifient notre

rapprochement de la perspective de la stratégie comme « pratique », il apparaît utile de nous

interroger sur les concepts clés qui fondent cette approche émergente : qu’est-ce qu’une

stratégie dans une perspective de la « pratique » et qu’est ce que le « strategizing »? Qui sont

les stratégistes et que font-ils ?

1.1 Le strategizing : à l’intersection des pratiques, praxis et praticiens :

Dans une perspective de la stratégie comme « pratique », la stratégie est conceptualisée

comme une activité située et socialement accomplie et le « strategizing » renvoie aux

actions, interactions et négociations de multiples acteurs et aux pratiques situées sur lesquels

ils s’appuient, qui a des conséquences en termes de résultats pour la direction et/ou la survie

de l’entreprise (Jarzabkowski, 2005 ; Jarzabkowski, Balogun & Seidl, 2007). De ce point de

vue, toute activité peut être considérée comme stratégique dans la mesure où elle aura des

http://www.strategy-as-practice.org/

http://www.strategy-as-practice.org/


93

conséquences sur l’orientation de l’entreprise. Afin de saisir le sens opérationnel des

concepts de « stratégie » et de « strategizing », nous nous référons au modèle conceptuel de

(Jarzabkowski, Balogun & Seidl, 2007) qui différencie les notions de « pratiques »,

« praxis » et praticiens.

La « praxis » ou ce qui constitue la pratique de la stratégie, relève de l’interconnexion entre

les actions des différents 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 référence au « flux d’actions,

d’opérations et d’activités qui permettent de faire évoluer l’organisation de l’instant (t) à

l’instant (t +1), d’un é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 :

procédures, ressources cognitives, motivationnelles, normes et outils utilisés et partagés par

les individus pour faire de la stratégie (Jarzabkowski, 2011). Ces pratiques (la recherche des

idées, l’identification des opportunités, les routines71, l’écriture des documents formels, la

préparation des présentations, etc.) sont considérées comme une infrastructure à travers

laquelle le processus de « strategizing » a lieu, engendrant un flux continu d’activités

stratégiques représenté par la « pratique » ou « praxis » (Jarzabkowski, 2003). Enfin les

praticiens sont les acteurs qui font le lien entre la « praxis » et les « pratiques ». Ils possèdent

un répertoire de « pratiques » issues de leurs expériences passées et de leur environnement

(culture d’entreprise, outils, règles, etc.) sur lequel ils s’appuient pour s’engager dans

l’action « praxis ». Il est utile de préciser que ces trois concepts sont interconnectés. Il est

donc impossible d’étudier un concept sans toutefois s’intéresser sur certains aspects des deux

autres (Jarzabkowski, Seidl & Balogun, 2007). Le « strategizing » est le point d’intersection

entre la « praxis », les « pratiques » et les praticiens. Si toute question de recherche fait

inévitablement le lien entre ces trois aspects du « strategizing », sur le plan empirique, les

recherchent se focalisent sur l’une des trois zones d’intersection (A, B ou C) (figure IV).

71Les routines sont définies comme « des modèles répétés de comportement qui sont bornés par des règles et

des coutumes et qui ne changent pas beaucoup d’une itération à une autre » (Feldman, 2000 dans Teulier,

2008).


94

Les études qui se situent dans la section (A) s’intéressent à qui est le stratège et quelles sont

les pratiques qu’il mobilise dans sa pratique de la stratégie. Les recherches qui se trouvent

dans la section (B), à l’intersection des pratiques et de la pratique « praxis », s’intéressent à

ce que font les stratèges. Quant aux recherches qui se situent dans la section (C), elles

s’intéressent à la façon dont l’identité du stratège (cadre intermédiaire, les opérationnels,

etc.) peut influencer la pratique de la stratégie. Toutefois, ces études sont encore peu

nombreuses.

L’article de Jarzabkowski (2005) par exemple, s’est intéressé au rôle des réunions dans la

stabilisation et la déstabilisation des activités stratégiques des « top managers ». Pour ce

faire, l’auteure s’est focalisée sur l’analyse des « pratiques » en s’appuyant sur les théories

sociales de la pratique. D’autres chercheurs (Balogun & Johnson, 2005) ont abordé

l’implémentation d’un changement stratégique dans de multiples divisions en s’appuyant sur

la théorie du sensemaking. Afin de mener à terme leur recherche, ils se sont focalisés sur les

activités de création de sens des praticiens et sur leurs interactions sociales.

1.2 Qui sont les stratégistes et que font-ils ?

Pendant longtemps, la stratégie a été considérée comme un processus de formulation « top-

down », réservé aux cadres supérieurs et dirigeants et séparée de l’implémentation. En

revanche, dans une perspective de la stratégie comme « pratique », les cadres intermédiaires

PPrraaxxiiss : flux d’activités situées, socialement accomplies qui,

stratégiquement, affectent la

survie du groupe, de

l’organisation ou de l’industrie. FFaabbrriiqquuee ddee llaa ssttrraattééggiiee

PPrraattiicciieennss :: Les acteurs

qui influencent la

construction de la pratique

au travers de qui ils sont,

la manière dont ils agissent, les ressources

dont ils disposent.

Figure IV: Parties constitutives de la « fabrique » de la stratégie

(Jarzabkowski, Seidl & Balogun, 2007)

PPrraattiiqquueess :: les ressources

cognitives, procédurales,

discursives, motivationnelles et

physiques qui sont combinées,

coordonnées et adaptées pour

construire la pratique.

B C

A


95

et les opérationnels sont considérés comme des acteurs stratégiques importants. Bien que

leur rôle stratégique ne soit pas formalisé, celui-ci est significatif pour la survie de la firme et

sa compétitivité. De ce point de vue, il s’avère essentiel de s’intéresser aux connaissances

sociales, interprétatives et personnelles de ces acteurs à travers lesquelles ils transforment la

stratégie (Balogun, 2003 ; Rouleau, 2005 ; Jarzabkowski, Seidl & Balogun, 2007). Dans une

même optique, les acteurs se trouvant en dehors de l’organisation (prestataires externes,

clients, fournisseurs, etc.) semblent également influencer mais indirectement, la stratégie de

l’entreprise. Toutefois, peu de travaux empiriques ont traité, à l’heure actuelle, du rôle de ces

acteurs et de la manière dont leurs identités professionnelles et leur engagement au sein de

l’entreprise influencent la stratégie de cette dernière. Tout système d’activité peut dès lors

être compris à travers l’examen de la manière dont les pratiques de management traduisent la

stratégie en « pratique » (Jarzabkowski, 2003).

Une question assez récurrente dans les recherches centrées sur la « fabrique de la stratégie »

concerne ce que font les « stratégistes ». Cette question se focalise sur le contenu de la

stratégie comme « pratique » (« doing ») et particulièrement, sur la manière dont la

« pratique » (« doing ») modifie et transforme la stratégie. Se donnant pour objectif de

comprendre le contenu de la « pratique », cette question est théoriquement soutenu par le

concept de « pratiques » exposés plus haut. Autrement dit, elle renvoie aux pratiques

spécifiques, situées, sur lesquels les praticiens s’appuient quand ils font de la stratégie. Ainsi

la perspective de la « fabrique de la stratégie » va au-delà de la classification des pratiques

spécifiques que les praticiens font (réunions, outils analytiques, workshops, etc.) pour

s’intéresser à comment ils les font, en mobilisant leurs savoirs situés et personnels. Afin

d’illustrer ce propos, Jarzabkowski et ses collègues se réfèrent aux chercheurs qui, en

voulant comprendre la conduite d’une réunion, se focalisent sur la manière dont les

interactions discursives et les intérêts manifestés par les acteurs transforment

l’accomplissement social de la stratégie.

Une autre question courante dans les discussions menées sur la « fabrique de la stratégie »

est : quelle est la base théorique des recherches qui s’inscrivent dans cette approche et

comment l’aligner avec les approches sociales et organisationnelles existantes ? L’intérêt

central des études menées dans une perspective de la stratégie comme « pratique » est de

répondre aux questionnements que nous avons posés au début de cette sous-section. Ce

courant ne requiert pas de nouvelles théories mais s’appuient sur un ensemble de théories


96

existantes qui permettent d’explorer la stratégie à partir de trois niveaux d’analyse (praxis,

pratiques, praticiens) et d’avancer les explications sur comment la stratégie est accomplie en

utilisant ces différents niveaux d’analyse. L’objectif commun à toutes ces études est

d’expliquer l’intersection entre la « praxis », les « pratiques » et les praticiens et ses

conséquences au niveau de l’accomplissement de la stratégie.

En ce qui concerne les méthodologie de recherche, certains auteurs s’inscrivant dans le

courant de « la fabrique de la stratégie » (Samra & Fredericks, 2004 dans Jarzabkowski,

Seidl & Balogun, 2007) ont mis en avant les méthodes qualitatives comme

l’ethnométhodologie ou l’analyse conversationnelle pour analyser, de façon très fine, le sens

des épisodes et des flux d’interactions des personnes impliquées dans l’élaboration de la

stratégie, les discussions informelles, les négociations et les usages des outils stratégiques.

Nous inscrivons ce projet de recherche dans le niveau d’analyse (A) au sens de

(Jarzabkowski, Seidl & Balogun, 2007) pour nous intéresser principalement aux

« pratiques » des praticiens et à la manière dont ils « organisent » les méthodes « agiles »

pour aboutir à des résultats stratégiques au sein de leur organisation (amélioration de la

productivité des équipes, réduction des coûts des processus de développement, etc.). Nous

nous focalisons, dès lors, sur les ressources discursives, cognitives et comportementales

mobilisées par ces praticiens. Ces derniers vont contribuer à la « construction » des outils

« agiles » en fonction de qui ils sont et des caractéristiques du contexte dans lequel ils se

trouvent. De fait, il nous a paru opportun de mobiliser la grille d’analyse de sensemaking

(Weick, 1995) pour mieux comprendre comment les praticiens, par le jeu de leurs

interactions, de leurs expériences passées, identité organisationnelle, etc. font sens des

méthodes émergentes dites « agiles » et de leur contexte d’application et par conséquent

contribuent à leur « fabrication ».

L’approche d’analyse « par la pratique » dans laquelle s’inscrit ce travail vise à analyser et à

rendre compte du contexte social dans lequel la « fabrique » de la stratégie a lieu en se

focalisant sur les « pratiques » routinières des acteurs, leurs ressources motivationnelles,

discursives et cognitives mobilisées et combinées. L’action 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 l’organisation et la société.


97

2. Le modèle du sensemaking

Le processus de sensemaking ou de création de sens renvoie au processus social par lequel

les individus et les groupes, projetés dans des interactions ininterrompues, construisent

socialement un sens de ce qu’ils font et de ce qu’ils perçoivent des situations en cours

d’achèvement (Vandangeon-Derumez & Autissier, dans Autissier & Bensebaa, 2006). Le

sensemaking relève du contexte dans lequel une action est située. Par conséquent, pour

comprendre une action, il est important d’appréhender les circonstances ayant contribué à la

création du sens et par la suite influencé l’action même.

Plusieurs chercheurs ont mobilisé la notion de sensemaking pour étudier la manière dont les

individus et les collectifs font sens des phénomènes organisationnels et agissent en

conséquence (Louis, 1980 ; Gioia & Chittipeddi, 1991 ; Sackman, 1991 dans Weick, 1995,

Weick, 1995). Si ces chercheurs s’accordent sur la connotation du terme de sensemaking,

celui-ci a été abordé sous différents angles d’approche. Meryl Louis (1980) offre une vision

plutôt micro-cognitive du sensemaking où celui-ci est perçu comme un processus de

réflexion qui s’appuie sur des comptes rendu rétrospectifs permettant d’expliquer des

évènements imprévus. Il s’agit d’un cycle récurrent composé d’une séquence d’évènements

se déroulant au fil du temps, conduit par les occasions de « surprises72 ». De ce fait, les

individus se trouvent confrontés à des évènements non conformes à leurs attentes et

prédictions, déclenchant un besoin d’explication et d’interprétation des divergences

constatées. Le sens ainsi attribué aux évènements est considéré comme le résultat du

processus de sensemaking, traduit en activités concrètes. Sackman (Sackman 1991 dans

Weick, 1995) évoque le terme de sensemaking pour désigner les mécanismes que les

membres organisationnels utilisent pour attribuer du sens aux évènements. Ces mécanismes

regroupent les règles et les croyances mobilisés par les individus pour percevoir, interpréter

et agir dans un contexte caractérisé par une culture organisationnelle spécifique. De ce point

de vue, les modèles de référence des individus influencent la manière dont les événements

sont perçus et appréhendés. La création de sens reflète ainsi les aspects culturels de

l’organisation. Pour d’autres chercheurs, le sensemaking relève d’une interaction réciproque

entre la recherche d’informations, l’interprétation et l’action (Thomas, Clark & Gioia, 1993).

A ce titre, l’interprétation en tant qu’activité est placée au cœur du processus de

72Il s’agit de l’écart entre les anticipations et les expériences subséquentes. Elles renvoient également aux

réactions affectives d’une personne à l’égard d’un changement, d’un contraste, d’une différence. Les

« surprises » font partie des expériences de l’individu (Louis, 1980).


98

sensemaking. Le cycle de sensemaking débute par la collecte d’information (scanning). Cette

dernière précède l’interprétation et l’action (Daft & Weick, 1984 dans Thomas, Clark &

Gioia, 1993). S’inscrivant dans une approche interprétativiste, Gioia et Chittipeddi (1991) se

sont focalisés sur les processus de sensemaking et de sensegiving des managers impliqués

dans la mise en place du changement stratégique. Si le sensemaking renvoie à la manière

dont les individus pensent et attribuent du sens à des évènements en cours, le sensegiving,

quant à lui, vise à donner un sens particulier au discours et à influencer la manière dont

l’audience 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 Schön, le sensemaking

relève de la manière dont les acteurs pensent au quotidien. Ces derniers sont investis dans

des pratiques quotidiennes dans lesquelles les problèmes ne se présentent pas comme tels

mais sont construits à partir de situations ambigües et instables. Dans cette perspective,

Schön élabore le schéma suivant : poser le problème, sélectionner 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 context in which we

will attend to them » (Schön, 1983, p. 40 dans Weick, 1995). Quant au modèle de

sensemaking de Weick, il a souvent été mobilisé pour comprendre l’effondrement du sens

dans les organisations et la capacité de celles-ci à retrouver leur état initial suite à une

situation d’ambigüité et d’incertitude. Weick s’est beaucoup intéressé à l’analyse des

incidents catastrophiques (Weick & Roberts, 1993; Weick, 1993a) en vue d’appréhender la

manière dont les organisations construisent du sens des situations de crise et « énactent73 »

leur environnement de telle manière à augmenter leurs capacités de résilience 74.

Dans le cadre de cette thèse, nous mobilisons le concept de sensemaking de Weick (1995)

pour comprendre comment les acteurs font sens des conditions dans lesquels ils se trouvent

et s’engagent dans l’action. Cependant notre travail ne concerne pas les situations de crise

mais plutôt des situations problématiques, moins extrêmes, auxquelles les acteurs sont

confrontés. A ce titre, la notion de « problème » nécessite d’être clarifiée. Nous retenons la

définition de (Smith, 1989) où le « problème » renvoie à une situation indésirable et

73Ce concept connote l’idée qu’un organisme s’adapte à son environnement en agissant directement dessus en

vue de le modifier (Weick, 1979). 74La résilience est « un processus d’apprentissage et de découverte, tourné vers la prise en charge de l’imprévu,

tend à réduire la dynamique temporelle de cet apprentissage à une accumulation, un empilement ou un

répertoire d’expériences passées » (Wildavsky, 1988 dans Hollnagel ; Journé & Laroche, 2009).


99

significative pour un agent, pouvant être résolue par celui-ci. Les problèmes représentent

donc une entité conceptuelle qui n’existe pas en tant que telle, mais qui renvoie à une

relation non harmonieuse entre la réalité et les préférences d’une personne.

Alors qu’à l’heure actuelle il n’existe pas d’outils « agiles » de gestion de projet « clés en

mains », les acteurs chargés de leur mise en œuvre sont vraisemblablement confrontés à des

situations problématiques diverses. Il est donc légitime, de nous intéresser 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 : « what’s the story here?» et « now what ? ». Face à

des évènements inintelligibles, les individus essayent de comprendre « c’est quoi

l’histoire ? ». En s’interrogeant sur une situation donnée, 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 départ du sensemaking est donc l’absence « d’ordre intrinsèque» « 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

déclenché par l’attention accordée à un phénomène inhabituel, congruent. Le sens se

construit à partir d’une indétermination qui surgit dans le flux d’expérience. Les perceptions

des signaux ambigus relèvent des expériences passées des individus, de leurs formations, etc.

Les individus vont donc extraire et isoler certains éléments de leur contexte pour lesquels ils

vont donner un sens et donc un certain ordre. Les connaissances des individus leur

permettent de créer du sens des conditions rencontrées et donc de rapporter des éléments de

réponse aux situations problématiques identifiées. Weick évoque le terme « bracketing »

pour désigner l’activité d’extraction d’indices ou de « cues » de l’environnement. Le

« bracketing » permet de simplifier la réalité en délimitant le champ d’intervention des

acteurs « Notice that once bracketing occurs, the world is simplified » (Weick, Sutcliffe &

Obstfeld, 2005, p. 411). Une étiquette ou un « label » est ainsi attribué(e) aux éléments

repérés en vue d’être partagée de façon collective. A ce stade, les acteurs procèdent à

l’interprétation des évènements. Ils mobilisent leurs connaissances, leurs expériences passées

et leurs prédispositions personnelles pour expliquer les « symptômes » des situations et les


100

conditions dans lesquelles ils se trouvent. Toutefois, l’interprétation des phénomènes ne se

limite pas seulement au lien entre les connaissances des individus et la situation concrète

mais relève aussi des relations sociales entre ces derniers.

Ainsi, le sensemaking résulte des interactions, des échanges d’informations, de coordination,

etc. Les émotions, les sentiments, l’intuition et l’imagination, identifiées comme propices à

l’apprentissage contribuent également à la construction du sens. Les activités de création de

sens des phénomènes conduisent les acteurs à s’accorder sur des formes de solutions et

d’actions plausibles. A ce stade, les acteurs tentent de répondre à la question « now what ? »

à travers leurs anticipations des évènements futures.

L’approche organisationnelle du sensemaking de Weick permet de saisir comment les

acteurs organisationnels font sens de leur environnement et participent à sa construction à

partir des représentations qu’ils se donnent de celui-ci.

Dans son modèle, Weick propose d’aller au-delà de l’activité d’interprétation de la réalité,

celle-ci étant une composante du processus de création de sens. L’interprétation est définie

comme une forme d’explication nécessitant une connaissance particulière, une imagination,

une sympathie, etc. (Weick, 1995). Elle est se présente comme une séquence de collecte de

données (balayage des informations), d’interprétation, (attribution des significations aux

données) et d’action (apprentissage). La première étape (balayage de l’information) consiste

à analyser l’environnement à travers une collecte de données qui serait neutre et objective.

L’interprétation consiste ainsi à attribuer des significations aux données collectées et

l’apprentissage intervient dans la dernière étape (Autissier & Bensebaa, 2006). Si

l’interprétation renvoie à un texte déjà écrit mais en attente d’être découvert, l’activité de

sensemaking, quant à elle, concerne à la fois la manière dont le texte est interprété et créé.

L’élément clé qui différencie ces deux notions est donc la manière dont les gens procèdent

pour déterminer ce qui sera soumis à l’interprétation. Afin de comprendre la manière dont

les individus engagés dans de nouvelles « histoires » contribuent à la création de celles-ci,

nous présentons les différentes propriétés du sensemaking (Weick, 1995).


101

2.1 Les propriétés du sensemaking

Dans ses travaux, Weick s’est attardé à la description des différentes propriétés du processus

de sensemaking.

Le contexte social : dans les écrits de Weick, l’unité d’analyse est le groupe. Celui-ci

renvoie à des individus projetés dans des séquences d’interactions au cours desquelles ils

créent un sens de leur environnement (Weick, 1995). Le contexte social constitue le matériau

d’observations des actions menées. L’interaction est le moment où les individus se

construisent une représentation des autres, d’eux mêmes et de leur environnement

(Autissier& Bensebaa, 2006). La création de sens se fait donc à travers les interactions

interindividuelles influençant les comportements et les actions entreprises « human thinking

and social functioning … are essential aspects of one another » (Weick, 1995, p.38). Le sens

créé n’est pas uniquement subjectif mais aussi contraint par le contexte et les objectifs que

les acteurs visent à atteindre (Daft & Weick, 1984 dans Gioia & Chittipeddi, 1991).

L’identité : la création de sens est ancrée dans les multiples identités des individus et des

membres d’un groupe. L’identité individuelle concerne la question « qui suis-je ? » et

l’identité organisationnelle « qui sommes-nous ? ». La création de sens est ainsi influencée

par la personne que nous croyons être et que nous voulons faire apparaître ainsi que par

l’identité organisationnelle et la manière dont celle-ci est représentée. Dans un

environnement turbulent, les personnes sont amenées à créer du sens afin de s’organiser et

d’agir convenablement, de manière plausible. Toutefois, les actions reflètent souvent les

représentations de ce qui se passe conformément avec ce que la personne souhaite être ou

paraître. L’approche de sensemaking s’intéresse à la manière dont les individus construisent

le monde à partir de ce qu’ils sont. Les comportements des individus et leurs modes de

pensée sont ainsi influencés et guidés par leur identité individuelle et organisationnelle.

« C’est à partir de notre identité que s’élabore le processus par lequel nous donnons du

sens. L’identité est constitué d’une multitude de soi entre lesquels les individus circulent »

(Vidaillet, 2003, p.40).

La rétrospection : le sensemaking met en valeur la rétrospection, la manière dont les

individus observent rétrospectivement les évènements passés en leur attribuant un sens. De

ce fait, les individus examinent réflexivement leurs propres actions pour découvrir le sens de


102

ce qu’ils ont fait (Weick, 1979). L’idée dernière la rétrospection dérive de l’analyse des

expériences significatives vécues (Schutz, 1967 dans Weick, 1995). Weick et Schutz

postulent que l’individu ne peut pas donner un sens à l’action tant que celle-ci ne s’est pas

produite. Les personnes ne se rendent pas compte de ce qu’ils font qu’une fois le fait est

accompli « How can i know what i think until i see what i say ? ». La réalité est donc perçue

comme un processus continu d’individus créant du sens rétrospectivement des situations

dans lesquelles ils se trouvent. En général, la rétrospection met l’accent sur la manière dont

les actions réalisées par les individus leur permettent de découvrir leurs préférences,

principes, valeurs, croyances, etc. La rétrospection se nourrit de l’écart entre les intentions

initiales et leur réalisation (Autissier & Bensebaa, 2006).

L’extraction d’indices ou « cues » : dans une situation donnée, les individus ont tendance à

isoler des éléments du flux des évènements. La focalisation sur certains « morceaux » de

l’environnement se fait en fonction des schémas mentaux des individus et de leurs

expériences passées. Les schémas mentaux incarnent les moments passés de socialisation

tandis que les fractions des flux d’expériences renvoient au moment présent. 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 d’identifier

les points d’entrée ou « input » du processus de sensemaking.

La continuité : Afin de mieux comprendre le sensemaking, il est important de se rendre

compte de la manière dont les gens identifient les éléments du flux continu d’évènements

(Weick, 1995). Le sensemaking présuppose que les individus et leur monde évoluent de

façon continue. Dans cette perspective, la notion de fluidité des évènements prévale celle de

la stabilité.

La Plausibilité : le modèle de sensemaking suppose que le raisonnement humain est guidé

par la plausibilité plutôt que l’exactitude « to deal with ambiguity, interdependent people

search for meaning, settle for plausibility and move on » (Weick, Sutcliffe & Obstfeld, 2009,

p.409). En d’autres termes, les individus ont tendance à réduire les dissonances des

évènements en recherchant des explications plausibles, leur permettant d’avancer. Le

processus de sensemaking cherche à décrire la manière dont les choses sont plutôt que la


103

manière dont elles doivent être. Dans une masse d’informations complexes, il est important

de simplifier le réel afin pour pouvoir agir. De ce fait les individus s’appuient sur des actions

qui leur paraissent plausibles et envisageables. Par conséquent, l’accord ne porte pas sur les

finalités mais sur les possibilités d’accéder aux moyens permettant la réalisation des

objectifs. La notion de plausibilité rejoint ici la notion de « satisficing » de Simon (1997). La

rationalité limitée des agents ne leur permet pas de traiter l’ensemble des informations et

donc de calculer les conséquences possibles de chacune des décisions prises. Par conséquent,

ils se contentent de choisir une solution leur permettant de répondre à leurs besoins et

aspirations sans toutefois rechercher la solution optimale.

L’activation ou « enactment » : le sensemaking renvoie à la manière 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 what’s in people’s head and

imposed by them on a stream of events than by trying to describe what is out there » (Weick

1979, p.271). L’environnement est perçu comme socialement construit et interprété. Cette

perspective diffère des descriptions de l’environnement en tant qu’élément concret, externe à

l’organisation. Celui-ci est inventé plutôt que découvert. Les individus agissent ainsi en

fonction de leur compréhension de la situation qu’ils estiment vraie. De ce fait,

l’environnement ne s’impose pas à l’individu mais il est créé par celui-ci à partir de ses

représentations et ses interprétations. De ce fait, l’organisation relève de processus continus

d’interrogation et de création de sens réalisés par des individus en interactions sociales.

2.2 L’organisation appréhendée comme un processus d’organizing

Dans la perspective du sensemaking, l’organisation est vue comme une tentative d’organiser

le flux intrinsèque d’actions humaines, de les orienter vers un certain but à travers une

généralisation et une institutionnalisation des règles et des significations (Tsoukas & Chia,

2002). Les gens s’organisent pour créer 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).


104

Weick (1995) définit l’organizing comme une séquence de changement de l’environnement

impliquant l’activation, la sélection et la rétention (figure V). L’activation ou

l’« enactement » concerne l’activité d’identification d’« indices » et leur attribution de

significations. La sélection renvoie aux choix réalisés entre les interprétations et les options

envisageables. Quant à la rétention, elle consiste à capitaliser sur les solutions sélectionnées.

Le modèle d’organizing s’« enchâsse » dans celui du sensemaking. De ce point de vue,

l’organisation é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 l’organisation se co-construit

ainsi mutuellement.

Synthèse du modèle de sensemaking

Le modèle de sensemaking est une occasion pour étudier comment les individus, confrontés

à des situations problématiques, créent progressivement du sens de celles-ci et mettent en

place des actions plausibles. De ce fait, les acteurs s’appuient sur leurs connaissances et

expériences passées et mobilisent des ressources qui se trouvent à leur disposition.

Cependant, diverses contraintes contextuelles influencent la manière dont le sens est

construit : l’environnement physique immédiat, l’environnement macro-organisationnel,

culturel, réglementaire, social, etc. Par ailleurs, les propriétés caractérisant le processus de

sensemaking mettent en exergue cinq éléments principaux : (1) la nature émergente et

continue de la réalité sociale, (2) la prise en compte des interactions et du contexte sociale

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

AAccttiivvaattiioonn SSéélleeccttiioonn RRéétteennttiioonn CChhaannggeemmeenntt

ééccoollooggiiqquuee

EExxttrraaccttiioonn rrééttrroossppeeccttiivvee

d’indices

MMiissee àà jjoouurr ccoonnttiinnuuee PPllaauussiibbiilliittéé

FFeeeeddbbaacckk ddee llaa sséélleeccttiioonn eet ll’’aaccttiivvaattiioonn


105

dans l'analyse des phénomènes organisationnels, (3) la nature rétrospective des actions

entreprises, (4) la plausibilité des actions mises en œuvre par les individus et (5) l’isolation

de faits contextuels, déclencheurs du processus de sensemaking (figure VI).

IInntteerraaccttiioonn

CCoonntteexxttee

Situation problématique

Extraction des faits ou «cues»

Création de sens/interprétation

Formes d’accords sur des solutions

Actions plausibles

Résilience

EExxppéérriieenncceess SSttrruuccttuurree

FFoorrmmaattiioonnss PPrrééddiissppoossiittiioonnss

ppeerrssoonnnneelllleess RReessssoouurrcceess

IIddeennttiittéé

EExxppéérriieenncceess

RRèègglleess

Figure VI : Grille d’analyse du sensemaking

106

107

La seconde partie est consacrée à l’analyse de la « construction » d’une démarche « agile » de

management de projet : le cas d’une « fabrique » de stratégie « agile ».

Le chapitre (IV) présente l’organisation dans laquelle s’est déroulée l’étude de cas et précise

la méthode de recherche retenue.

Le chapitre (V) rend compte de nos observations et de nos analyses de l’étude de cas réalisée

durant 17 mois.

Le chapitre (VI) est centré sur la mise en discussion des résultats d’analyse.

PPAARRTTIIEE IIII :: DDEE LLAA FFAABBRRIIQQUUEE DD’’UUNNEE

«« IINNNNOOVVAATTIIOONN MMAANNAAGGEERRIIAALLEE »» :: LLAA

CCOONNSSTTRRUUCCTTIIOONN DD’’UUNNEE DDEEMMAARRCCHHEE

«« AAGGIILLEE »»

108

CChhaappiittrree IIVV :: CCoonndduuiirree uunnee aapppprroocchhee «« ppaarr llaa pprraattiiqquuee »»

Ce chapitre se divise en deux sections.

Dans la première section, nous présentons l’entreprise dans laquelle nous avons mené une

étude longitudinale de 17 mois. Nous montrons comment la démarche d’amélioration des

projets a été entreprise par l’équipe responsable. L’implémentation de la démarche « lean » a

fait l’objet de deux phases : une phase pilote (d’août 2009 à janvier 2010) et une phase de

généralisation (de février 2010 à décembre 2010).

Dans une seconde section, nous exposons et justifions notre méthodologie de recherche. La

collecte des données s’est faite à travers des observations semi-participantes et des entretiens

semi-directifs. Le corpus de données a été complété par des documents et des mails échangés

entre les acteurs. Nous nous sommes appuyés sur une démarche inductive pour analyser

l’ensemble des données collectées.

Chapitre IV : Conduire une approche « par la pratique »

109

Nous avons mené une étude de cas au sein d’une direction, d’un grand groupe français

de télécommunication, ayant décidé de mettre en place une démarche d’amélioration de

modes de fonctionnement de ses équipes projets. Pour ce faire, elle s’est basée sur un

ensemble de principes et outils issus des méthodes « agiles75 ».

1. Présentation « à plat » du cas d’entreprise étudié

Nous présentons là les principaux éléments de contexte organisationnel de l’entreprise et du

chantier de management étudié. Nous reviendrons dans le chapitre suivant sur certains

éléments essentiels de ceux-ci afin de les mettre en perspective d’une analyse et d’une

problématisation relatives à notre projet de recherche.

1.1 Description du contexte d’étude

La direction des plateformes de services (DPS), dans laquelle s’est déroulé ce travail de thèse,

fait partie du groupe Orange, l’un des principaux opérateurs de télécommunication au monde

servant 209, 6 millions de clients dans 32 pays. Cet opérateur leader76 (la 50ème marque

mondiale) est implanté dans plus de 220 pays sur les 5 continents. Il développe et

commercialise des produits et services de télécommunications divers : la téléphonie mobile

avec 150,4 millions de clients, le 3G haut débit avec 33.5 millions de clients et l’internet

ADSL avec 13.5 millions de clients. Son chiffre d’affaires a atteint, en fin 2010, 45.5

milliards d’euros.

Au sein du groupe, la direction de plateformes de services (DPS) a pour missions de

concevoir, développer mettre en service et maintenir les plateformes qui supportent les offres

d’Orange (le mobile, la voix sur IP, l’Orange TV, l'administration des livebox, l’accès

internet, etc.) pour toutes les unités du groupe. Elle regroupe plusieurs directions

fonctionnelles qui contribuent au développement et à la livraison de ces plateformes : la

75

Par souci de clarté, nous rappelons que nous avons décidé d’utiliser le terme « agile » pour désigner les

principes et outils issus des méthodes « agiles » et de l’approche de développement lean. 76«World Television Market », décembre 2010 et « World Telecom Market », Janvier 2011.


110

direction de développement (DDP77), la direction de qualification (IEP78), la direction

d’architecture, la direction de maintenance (DIM), la direction Nextv79 qui travaille pour la

télévision ainsi que d’autres directions travaillant sur des projets comme la téléphonie mobile,

la messagerie vocale, etc.

La direction Nextv, concernée par notre étude de cas, est responsable du pilotage et de la

livraison des produits de télévision numérique par câble, satellite et sur le réseau IP. Elle

comprend environ deux cents acteurs métiers (chefs de projet, architectes, managers de

composants, programmeurs, etc.) exerçant leurs activités autour de la plateforme de la

télévision en intervenant sur des projets placés sous sa direction soit sous la direction d’autres

entités. Outre des acteurs internes, les projets pilotés par la direction Nextv impliquent des

acteurs métiers transverses rattachés à d’autres entités de la direction DPS (architectes

logiciels, développeurs, qualifieurs techniques, qualifieurs fonctionnels, responsable de

maintenance, etc.), des acteurs métiers 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 façon globale, la

structure organisationnelle de l’entité investiguée.

77Direction de développement des plateformes 78Intégration Et Performance 79Next Television

Figure VII : Structure macro-organisationnelle de l’entité Nextv

Groupe

Marketing

R&D

RH Groupe

Communication

Autres entités

Développement

(DDP)

Entités

transverses

Qualification

(IEP78)

Architectes

Concepteurs

Autres entités

Direction des plateformes de services

(DPS)

Entité Nextv

(200 collaborateurs internes géodistribués)

Entreprise prestataires

Achat-vente

international

Achat-vente

international Equipe

« lean »

Achat-vente

international Achat-vente international

Achat-vente international


111

1.1.1 Cycle de vie des projets

Les projets sont conduits de manière séquentielle et découpés en jalons80. Ces derniers aident

au contrôle de l'avancement des tâches et constituent un moment décisif pour la poursuite du

projet. Chaque jalon consiste en une ou plusieurs phases allant de l’étude de l’opportunité à

l’activation et la généralisation de la solution développée (figure VIII).

Le mode de gouvernance des projets menés à DPS relève de trois acteurs principaux : le

marketing, le R&D et la direction DPS. La définition et la description des besoins du nouveau

produit ou service se fait par le marketing. Celui-ci va identifier les critères de contenu, de

qualité, de performance et fixer les coûts de réalisation de la nouvelle solution. Quant au

département R&D, il va effectuer un travail de prospection sur les nouvelles tendances

technologiques dans le but d’identifier les solutions techniques les mieux adaptées pour

répondre aux besoins du marketing. Enfin, la direction de DPS se charge de l’industrialisation

et du pilotage des solutions telles qu’elles ont été définies. Ces trois partenaires collaborent

dès la phase initiale du projet (phase T-1), durant laquelle les solutions correspondantes aux

besoins des clients sont bien identifiées et chiffrées. A ce niveau, plusieurs scénarios peuvent

être proposés et soumis à un comité de suivi des activités (CSA) qui prendra en charge la

validation du volume de ressources allouées par les directions contributrices. L’accord du

80Les jalons d’un projet se définissent comme des repères prédéterminés et significatifs dans le cours du projet

(Norme Afnor X50-115).

TT00AA TT11AA TT11XX

Étude

d’opportunité

exploration

Conception

générale

Conception

détaillée

Développement Qualification Assemblage Validation Mise En

Production

(MEP)

Activation

Généralisation

T0 T2 T3 T1 T-1 T-4

Fabriquer la solution Concevoir la

solution

Offrir un

service régulier

Que veut-

on faire Qu’est-ce que

l’on fait Comment

on le fait ? On livre le

produit

On vérifie

le service

On le vend On fait le

bilan

Figure VIII : Cycle de vie des projets à DPS


112

client (donneur d’ordre) et du CSA sur le document d’engagement conduit à la phase de

conception globale de la solution.

Durant cette phase (T0-T0A), les livrables attendus sont les spécifications générales, les

documents d’architecture technique et fonctionnelle (DAT et DAF), le référentiel d’exigences

et la revue de jalon. Une deuxième version du document d’engagement est ainsi rédigée

conduisant à la phase de conception détaillée. Au cours de cette dernière, les spécifications

sont écrites en détail, les documents d’architecture technique et fonctionnelle sont finalisés,

les dossiers d’interface, d’ingénierie et le plan de qualification sont initialisés et enf in le

planning et le budget sont actualisés.

La solution est ensuite développée au cours des phases (T1-T1A) pendant lesquelles les

activités de qualification et d’assemblage sont préparées. Il convient de noter que même si le

plan de qualification est initialisé entre le (T0 et le T1) il sera complété au fur et à mesure de

l’avancement du projet et en fonction des informations dont disposent les équipes (exigences

fonctionnelles et non fonctionnelles, cartographie, évolutions des fonctionnalités, les risques,

la criticité, etc.). Les livrables attendus à la fin de cette phase relèvent d’une version du

produit livré et d’un bilan de tests unitaires. Ce n’est qu’au niveau des phases (T1A et T2) que

l’assemblage et la qualification sont réalisés donnant lieu aux livrables suivants : documents

d’installation, d’exploitation et de supervision, rapports de qualification, scénarios et

stratégies de mise en production, bilan global des tests. La solution est alors testée et validée

avant d’être mise en production (T2).

Entre les phases (T2-T3), la solution est activée techniquement et expérimentée sur un

échantillon d’utilisateurs. Les documents de support de formation, le bilan d’expérimentation

et les documents d’exploitation sont livrés à la fin de cette phase. Ce n’est qu’après une

période de vérification du service régulier (VSR) que la solution est lancée sur le marché

(T3). Au-delà de cette phase la solution est prise en charge par les équipes de maintenance.

Un bilan global est réalisé après une période d’observation des ventes (phase T4).

Si le cycle de vie de projet est commun à toutes les équipes de la direction Nextv, ces

dernières peuvent s’appuyer sur des méthodes managériales différentes. A chaque direction

correspond un mode de fonctionnement adapté à son propre contexte. Nous pouvons donc

retrouver des équipes de développement travaillant en mode « agile » et d’autres équipes

s’appuyant plutôt sur un cycle de développement en « V ».


113

En effet, le développement de projets au sein de DPS renvoie à une approche séquentielle où

chaque phase est matérialisée par un ensemble de livrables prédéfinis. Les projets sont

habituellement d’une longue durée (supérieur à un an minimum) et impliquent un grand

nombre d’acteurs.

D’une manière générale, dans un cycle de vie linéaire, le développement de la solution passe

de métier en métier reflétant l’image de course de relais. Cependant, dans le cas présent, les

phases amont et aval peuvent se recouper. Certaines activités de l’aval sont, par exemple,

anticipées avant l’achèvement de celles de la phase amont. Les acteurs métiers de la première

peuvent être impliqués sur d’autres phases du projet en tant qu’acteurs secondaires et

travailleront en parallèle sans nécessairement organiser leurs relations avec les acteurs en

amont. Prenons pour exemple la qualification. Si la réalisation effective de la qualification n’a

lieu qu’à la phase (T1A), la préparation des opérations de qualification (stratégies de

qualification initialisée, plans de qualification) se fera entre (T0 et T1). Le tableau (9) donne

un aperçu général de l’intervention des acteurs principaux et secondaires dans les phases du

cycle de vie des projets conduits à DPS.

Tableau 9: Intervention des acteurs métiers dans le cycle de vie du projet

Phases

Acteurs

Phase

T-1-T0

Phase

T0-T0A

Phase

T0A-T1

Phase

T1-T1A

Phase

T1A-T2

Phase

T2-T3

Marketing ■ ■

R&D ■

Équipes

d’architectes ■ ■

Équipe de

développement ■

Équipe de

qualification ● ● ● ■

Équipe de

maintenance ● ● ■

■ : acteur principal

● : acteur secondaire


114

1.1.2 Structure des projets

L’entité Nextv couvre l’ensemble du cycle du projet, de la préparation du T-1 jusqu’au T3,

tout en étant chargée du support et de la maintenance. Pour monter un projet à Nextv, le chef

de projet sollicite l’expertise de différents acteurs : acteurs métiers travaillant au sein de son

entité (architectes, manageur de composant, programmeurs), acteurs transverses provisoires

(équipe de développement, équipe de qualification, architectes, équipe de maintenance),

acteurs externes à la direction des plateformes de services (marketing, R&D, support) et des

acteurs rattachés à des entreprises prestataires. L’intervention temporaire des acteurs renvoie à

l’instabilité de l’équipe pilotée par le chef de projet. Au niveau des projets, ce dernier dispose

d’une autorité hiérarchique limitée. Son rôle est d’assurer la coordination de différentes unités

fonctionnelles impliquées dans un projet et de veiller à la réalisation des objectifs dans les

limites temporelles et budgétaires prédéfinies. Les projets sont ainsi développés dans une

structure lightweight selon la terminologie de Clark et Wheelwright (Clark et Wheelwright

dans Midler, 1993). La figure (IX) illustre la structure d’une équipe projet pilotée par l’entité

Nextv.

Figure IX : Structure de type « lightweight »

Prestataires externes

Liaison non hiérarchique

DPS

DDP IEP Architecture Autres directions

métiers

Chefs de projet

métiers

Chef de projet

architecte

Chef de projet

Qualification Chef de projet

développement

Acteurs métiers sur

le projet

Architectes

fonctionnels

Qualifieurs

techniques

Développeurs Coordinateur de

projet à Nextv


115

1.2 Mise en place de la démarche « lean »

Le dépassement des budgets alloués aux projets, le non respect des délais initialement fixés et

la non-conformité des produits aux attentes des clients ont amené la direction de l’entité

Nextv à remettre en question le mode de fonctionnement de ses équipes. Pour ce faire, elle a

décidé de mettre en place une démarche d’amélioration des modes de management de projet

qu’elle qualifiera de projet « lean ». Ce dernier est né de l’intime conviction du directeur

général quant à l’efficacité de la démarche lean et à la lourdeur des autres méthodes

d’amélioration (CMMI81 ou DMAIC82 à titre d’exemple). Par ailleurs, durant cette même

période, le lean management était appliqué avec succès sur les centres d’appel et les services

après ventes du groupe ce qui aurait pu également influencer la décision de la direction

générale. Le lancement du projet « lean » a été officialisé l’été 2009. Il visait la totalité des

collaborateurs de l’entité Nextv (approximativement 200 acteurs internes). Sa réalisation a été

confiée à une équipe, qui s’est attribuée le nom d’équipe « lean », composée initialement,

d’un coach, spécialiste kaizen, chargé d’accompagner les membres de l’équipe, d’un

responsable qualité, désigné directeur du projet « lean » et de trois personnes sélectionnées

par leur management. Toutefois, au cours du projet « lean », un apprenti a été recruté en vue

d’assister l’équipe dans la mise en place de la démarche. En outre, un directeur de projet a

rejoint l’équipe alors qu’un autre membre l’abandonnera quelques semaines plus tard. Le

tableau (10) dresse le profil des acteurs et leurs rôles respectifs dans la démarche

d’amélioration.

Tableau 10: Profil des membres de l'équipe « lean »

Profil des acteurs Rôle des acteurs au sein de la démarche

Senior performance manager, spécialiste kaizen Coach accompagnateur de l’équipe (RB)

Responsable qualité du programme TV à Nextv Directeur du projet « lean » (TR)

Responsable du pôle HPM pays Porteur d’activités sur le plan opérationnel (JP)

Responsable CPM IPTV Porteur d’activités sur le plan opérationnel (ER)

Directeur de projets Easy TV Porteur d’activités sur le plan opérationnel (DT)

Directeur de projet Porteur d’activités sur le plan opérationnel83 (DF)

Apprenti sur la démarche « lean » Assistant du directeur de projet (QR)

81

Capability Maturity Model Integration. Il s’agit d’une approche d’amélioration de la qualité des logiciels. 82C’est un acronyme d’une méthode d’amélioration de la qualité qui consiste en cinq étapes : Définir, Mesurer,

Analyser, Innover et Contrôler. 83Il convient de préciser que cette personne a abandonné le projet quelques semaines après son lancement.


116

Afin de se familiariser avec cette nouvelle démarche managériale, les membres de l’équipe

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 manière dont le

lean fut appliqué au niveau des centres d’appels du groupe. Par ailleurs, les acteurs « lean » se

sont également appuyés sur des articles et présentations traitant du lean dans les industries de

logiciels et des méthodes « agiles » de management de projet informatique.

La démarche entreprise au sein de Nextv se fonde sur quatre principes fondamentaux :

l’élimination du gaspillage, la simplification des modes de fonctionnement des équipes, la

généralisation des meilleures pratiques et la standardisation. La démarche a été présentée, aux

équipes projets de l’entité, comme un changement d’un « état d’esprit »visant l’amélioration

continue.

« Nous recherchons ensemble en permanence l’amélioration dans nos façons de travailler…

et la mettons en œuvre au sein de l’équipe » (TR).

Dans cette perspective, l’équipe « lean » s’est lancée dans la définition et le développement

des pratiques et outils managériaux permettant de répondre aux enjeux de la direction. Les

pratiques retenues relèvent, des méthodes « agiles » et des principes et outils du lean

management. Le tableau (11) synthétise les différents outils et principes sur lesquels l’équipe

« lean » s’est basée pour mener à bien sa démarche.

Tableau 11: Principes et pratiques adoptés dans la démarche « lean »

Principes et outils basés sur les méthodes

« agiles »

(Beck & Andres, 2004 ; Schwaber, 2004)

Principes et outils basés sur le « lean

thinking »

(Poppendieck, 2006)

Daily brief de type « stand-up meeting »ou « daily scrum »

Principe d’amélioration continue : ateliers kaizen, PDCA, QQCQOP, 5 Pourquoi

Partage virtuel des « story-boards » et des indicateurs de performance

Principe d’empowerment des opérationnels et respect des personnes

L’implémentation de la démarche « lean » a fait l’objet de deux phases: une phase pilote

(d’août 2009 à janvier 2010) visant à tester et à vérifier la faisabilité de la démarche sur un

nombre limité d’acteurs projets et une phase de généralisation (de février 2010 à décembre

2010).


117

Durant la phase pilote, sept équipes ont été retenues : trois équipes métiers qui font partie de

l’entité Nextv (architectes, chefs de projets, manageurs de composants) et quatre équipes

projets pilotées par celle-ci. Les projets sélectionnés se trouvent à des niveaux d’avancement

différents (tableau 12).

Tableau 12: Projets pilotes retenus

Projets retenus Phase d’avancement

R3PC Projet en phase de démarrage

FTTH Release 1.0

ZE R2 Projet en phase d’assemblage / qualification

R3ZNE Projet en phase d’assemblage / qualification

Au total, trente personnes, travaillant uniquement au sein de l’entité Nextv mais sur différents

sites géographiques (Paris, Rennes, Blagnac, Guyancourt) ont été concernées par cette phase

pilote menée sous formes d’ateliers.

La première étape a débuté par la mise en place d’ateliers de remontées de

dysfonctionnements sur différents sites géographiques (Paris, Rennes, Blagnac, Guyancourt).

Ils avaient pour mission d’expliquer l’objectif et l’utilité de la démarche « lean » et faire

remonter les problèmes majeurs rencontrés au cours des projets. Ces ateliers ont également

été l’occasion de former les participants aux outils84 d’analyse de dysfonctionnements adoptés

par l’équipe. Par conséquent, quatre ateliers orientés projet et trois ateliers orientés métiers

ont été mis en place. Nous avons, de notre côté, assisté à cinq ateliers de remontées de

dysfonctionnements.

Lors de la deuxième étape de la phase pilote, des « rendez-vous d’information » ont été

organisés, cette fois ci, avec l’ensemble des membres de l’entité Nextv. Leur but est de

sensibiliser les acteurs aux enjeux et objectifs du projet « lean », de les tenir aux courant par

rapport à l’évolution de la démarche et de répondre à leurs questionnements. Des réunions

complémentaires ont été organisées avec le Codir auxquelles nous n’avons pas été conviées.

Ces réunions avaient pour objectifs de discuter et de valider les dysfonctionnements à traiter

et les plans d’action à mettre en place (tableau 13). Parmi les 98 dysfonctionnements

identifiés dans les premiers ateliers, seuls huit ont été retenus en vue d’être traités

84Cf. tableau (11).


118

collectivement. Nous reviendrons infra sur les raisons qui expliquent le choix de ces

dysfonctionnements.

Plusieurs réunions avec les chefs de projet ont succédé aux ateliers de remontées de

dysfonctionnements. Ces réunions se sont données pour objectifs de recueillir les feedback

par rapport à la démarche et à son adaptabilité au contexte des projets. Enfin, lors de la

dernière étape de cette phase pilote un bilan de projet « lean » a été établi et présenté au

Codir.

Tableau 13: Plans d'actions validés par le Codir

Plans d’action Métier concerné

Proposer un plan de formation ciblé pour les chefs de projets Chef de projet

Identifier les informations nécessaires pour la prise de décision aux

passages de jalons : préciser les documents nécessaires et leur contenu Chef de projet

Définir les acteurs, leurs rôles et responsabilités Chef de projet

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

Chef de projet

Complétude et pertinence de la documentation des composants du projet R3 : quantification des charges (préparation, rédaction, lecture) liées à 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 méthode et des critères simples permettant de réguler la demande et de décider rapidement le lancement ou non d’une étude

Architecte

Décrire les livrables attendus de la part des acteurs (architectes, Cdp) et

préciser les informations importantes pour la prise de décision au jalon T-1-T0.

Architecte

En ce qui concerne la phase de généralisation du projet (de février 2010- à décembre 2010),

de nouvelles unités fonctionnelles, externes à l’entité Nextv mais internes à la direction de

plateformes de services (DPS), ont été conviées à intégrer la démarche. De nouveaux plans

d’actions ont dès lors été développés impliquant, cette fois, des acteurs externes à l’entité

Nextv : le marketing, qualification, développement. De nouvelles réunions et formations ont


119

été mises en place pour initier les nouveaux arrivants aux outils85. Des entretiens additionnels

ont été également menés auprès de ces acteurs en vue d’améliorer l’adaptabilité de la

démarche en fonction de leur contexte.

La figure (X) montre le déroulement de la démarche entreprise par l’équipe « lean ».

2. Démarche d’investigation

Notre démarche qualitative mobilise un ensemble de techniques de collecte et d’analyse de

données permettant d’identifier, de comprendre et d’interpréter les évènements dans leur

contexte. Dans la partie qui suit, nous exposons, tout d’abord, notre choix d’étude

longitudinale et les sources de données ayant contribué à la construction de notre cadre

empirique. Ensuite, nous présentons la manière dont nous avons procédé pour analyser

l’ensemble des données rassemblées

2.1 Choix d’une étude longitudinale

Notre étude de cas obéit aux caractéristiques d’un processus de recueil longitudinal (Forgues

& Vandangeon-Derumez, 2003 dans Stake, 1995) : (1) les données collectées relèvent de

85Cf. tableau (11)

Figure X : Déroulement du projet « lean »

Pre-démarrage Phase Pilote Généralisation

Lancement du projet

« lean » par la direction

Identification des équipes pilotes : 3 équipes métiers et

4 équipes projets (5 à 8 personnes/équipe).

Mise en place de la

démarche au niveau des équipes pilotes et bilan de la

phase pilote

Implication de nouvelles équipes dans la démarche : le

marketing, les responsables des équipes de

développement, la

qualification.

Juin 2009-Aout 2009 Septembre2009- Janvier 2010

Février 2010-Décembre 2010


120

deux périodes distinctes, (2) elles nous permettent de retracer l’évolution du cas investigué et

(3) les sujets observés sont comparables d’une période à l’autre.

Nous avons passé dix sept mois sur le terrain de recherche. La focalisation sur un cas

particulier nous a permis de situer le phénomène dans son contexte spécifique, caractérisé

d’un côté, par des conditions physiques, techniques et organisationnelles bien particulières et

de l’autre, par des acteurs en interaction, déterminant et donnant sens à leurs activités. 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

d’appréhender, en profondeur, le contexte dans lequel les évènements y prennent place. Une

présentation synthétique de notre étude longitudinale est illustrée dans la figure (XI).

2.2 Procédés de collecte de données

La recherche empirique est alimentée par diverses sources de collecte de données :

documentation, enregistrement des archives, entretien, observation directe, observation

participante et simulation (Yin, 1990). Le choix entre ces multiples sources de données

dépend tant de l’objet de la recherche que des possibilités offertes par le terrain investigué.

Figure XI : Étude longitudinale

Pre-démarrage Phase Pilote Généralisation

Prise de contact avec

l’équipe chargée du

projet « lean »

Participation aux réunions des membres de l’équipe

« lean » : 23 réunions

(Paris+téléphone)

Participation à 5 ateliers de remontées de

dysfonctionnements

(Paris+Guyancourt+téléphone) et à 3 sessions de

« rendez-vous

d’information »

-1ère vague d’entretiens : 5

entretiens avec les chefs de projets et 1 entretien avec le

directeur du projet

« lean » (Paris+ téléphone).

Participation aux réunions

des membres de l’équipe « lean » : 14 réunions

(Paris+téléphone)

Participation à 2 ateliers de formation (Paris)

2ème vague d’entretiens : 16

entretiens avec les acteurs internes et externes à

l’entité Nextv et 1 entretien

avec le directeur du projet « lean » (Paris+téléphone).

Juin 2009-Aout 2009 Septembre 09- Janvier 2010

Février 2010-Décembre 2010


121

Dans le cadre de ce travail, nous avons mené des observations semi-participantes au sein de

l’entité et conduit des entretiens semi-directifs avec différents profils d’acteurs. Des

documents et présentations ont également été collectés et analysés.

2.2.1 La technique de l’observation semi-participante

D’une manière générale, la présence du chercheur sur le terrain peut se manifester sous deux

formes d’observation : participante, lorsque le chercheur occupe un rôle d’acteur au même

titre que les personnes observées et passive lorsque le chercheur est « autorisé d’être présent

dans l’organisation pour regarder la réalité quotidienne, assister aux évènements pour les

enregistrer et les analyser » (Wacheux, 1996, p.215).

Notre démarche empirique repose sur une observation semi-participante qui nous a permis

d’enrichir considérablement l’analyse et l’interprétation des activités discursives des acteurs .

Le recours à l’observation directe constitue un moyen efficace pour étudier la façon dont se

« fabrique » une stratégie « agile ». Si notre présence sur le terrain de recherche fut en grande

majorité « passive », nous avons néanmoins été amenés, à plusieurs reprises, à partager nos

points de vue et expériences avec le groupe d’acteurs observés. Les observations ont débuté

avec le lancement du projet « lean ». Nous avons participé à trente sept réunions, au total,

dédiées à la construction et à la mise en œuvre de la démarche. Durant ces réunions, nous

avons été sollicités pour répondre à un certain nombre de questions concernant les outils

« agiles » et la manière dont ils sont habituellement appliqués86.

Les tableaux (14) décrit, par ordre chronologique, les objectifs des réunions réalisées et

auxquelles nous avons participé, dès le lancement du projet. Outre les notes de synthèse prises

à la fin de chaque réunion, le suivi de mails échangés entre les acteurs avant les réunions nous

a permis de mieux cerner le contenu de celles-ci et leurs principales visées.

86Les questions posées par l’équipe « lean » concernent les méthodes « agiles », les enseignements et les

préconisations soulignés dans la littérature.


122

Tableau 14 : Tableau descriptif des réunions réalisées

Réunions Objectifs Date Durée

1 -Orientation du sens de la démarche -Identification des équipes pilotes

-Préparation des ateliers de remontées de dysfonctionnements

-Préparation des entretiens à mener auprès de chefs

de projets pilotes

27 Aout 2009 7 heures

2 28 Aout 2009 5 heures

3 -Retour d’expériences sur les entretiens menés avec

deux chefs de projets pilotes 4 Septembre 2009 1 heure

4 -Retour sur les ateliers de remontées de

dysfonctionnements menés -Préparation de la présentation pour le Codir

14 Septembre 2009 2 h30 min

5 -Préparation de la lettre d’information (n°1)

-Retour sur la présentation du Codir 25 Septembre 2009 2 heures

6 -Construction des outils de la démarche « lean » 2 Octobre 2009 3 heures

7 -Construction des outils de la démarche « lean »

(réunions quotidiennes, KPI) 13 Octobre 2009 1 heure

8

-Finaliser la proposition de la démarche « lean » sur

deux projets pilotes (R2ZNE) et (R3PC) -Préparation du reporting pour le Codir

-Finalisation de la lettre d’information (n°1)

16 Octobre 2009 1 h30 min

9 -Préparation du support de présentation des réunions

quotidiennes de type « daily-brief » 20 Octobre 2009 1 h30 min

10 -Préparation du rendez vous d’information sur la

démarche « lean » 22 Octobre 2009 1 heure

11 -Suivre les plans d’action en cours

-Partage des résultats et validation 23 Octobre 2009 1 h30 min

12 -Préparation de la lettre d’information (n°2) 30 Octobre 2009 1 h00 min

13

-Retour sur les sessions de rendez-vous d’information -Retour sur le lancement des réunions quotidiennes

(daily brief) -Préparation de la lettre d’information (n°3)

6 Novembre 2009 1 h30 min

14 -Partage des résultats des actions en cours 20 Novembre 2009 1 heure

15 -Suivre l’avancement des « chantiers » 24 Novembre 2009 1 heure

16 -Préparation de la présentation pour le Codir 27 Novembre 2009 1 heure

17 -Bilan sur les « daily briefs » mis en place au niveau

du projet R3PC 1er Décembre 2009 1 h30 min

18 -Bilan sur les « daily briefs » mis en place au niveau

de l’équipe métier CPM 4 Décembre 2009 1 heure

19 -Retour sur un entretien mené avec un scrum

manager d’une équipe de développement 9 Décembre 2009 3 heures

20 -Partage d’expériences d’une personne chez

Motorola ayant mis en place des pratiques « agiles » 18 Décembre 2009 1 h30 min


123

21 -Bilan des plans d’action 2009

-Préparation de la lettre d’information (n°4) 8 Janvier 2010 1 heure

22

-Préparation de la synthèse du bilan

-Identification de difficultés rencontrées -Préparation du plan de déploiement 2010

-Mise en forme de la présentation au Codir -Finalisation de la lettre d’information (n°4)

14 Janvier 2010 6 heures

23 -Retour sur la réunion avec le Codir

-Préparation du plan de généralisation 2010

-Préparation de la lettre d’information (n°5)

29 Janvier 2010 1 h30 min

24 -Préparation des sessions de formations sur la

démarche « lean » 17 Février 2010 1 h30 min

25 -Revoir et finaliser le contenu et la présentation des

sessions de formation 2 Mars 2010 1 heure

26 -Retour sur les formations mises en place 26 Mars 2010 45

minutes

27 -Planification et préparation des nouvelles sessions

de formation

-Préparation de la lettre d’information (n°6)

2 Avril 2010 1 heure

28 -Préparation du reporting mensuel pour le Codir 16 Avril 2010 1 h30 min

29

-Finaliser la lettre d’information

-Préparation de nouveaux plans d’action à mettre en œuvre (intégration des tests unitaires au niveau de la

qualification)

23 Avril 2010 1 h30 min

30 -Retour sur la lettre d’information

-Préparation des prochaines sessions de formation 30 Avril 2010 1 h30 min

31 -Préparation du bilan du premier semestre

-Préparation des entretiens à réaliser avec les

managers d’équipe

28 Mai 2010 2 heures

32 -Retour sur les entretiens réalisés avec les managers

d’équipe 16 Juin 2010 1 heure

33 -Préparation et validation du bilan du premier

semestre -Préparation pour le semestre 2

8 Juillet 2010 1 h30 min

34 -Partage de l’avancement des actions et propositions

futures 6 Octobre 2010 1 heure

35 -Point sur l’avancement de la démarche 14 Octobre 2010 1 heure

36

-Préparation du bilan 2010

-Préparation des entretiens à mener avec des membres de différentes directions (DDP, IEP, Nextv)

24 Novembre 2010 1 heure

37 -Retour sur les entretiens réalisés

-Premier trame du bilan 2010

-Perspectives 2011

15 Décembre 2010 1 h30 min


124

Au-delà des réunions, nous avons également assisté à des ateliers conduits par les acteurs

« lean » (tableau 15). Durant ces ateliers, nous avons adopté une attitude « passive » (en

posture d’observation) et, dans une perspective ethnographique, nous nous sommes contentés

de transcrire les évènements et de noter nos impressions concernant les situations observées.

Tableau 15 : Ateliers organisés par l’équipe «lean »

Types d’ateliers Acteurs concernés Nombre de

participants Durée

Atelier de remontées de dysfonctionnements (1)

Acteurs intervenant dans le projet R2ZNE

6 participants 3 heures

Atelier de remontées de

dysfonctionnements (2)

Membres des équipes

(CPM87) 5 participants 2 h30 min

Atelier de remontées de dysfonctionnements (3)

Architectes 5 participants 2 h30 min


dysfonctionnements (4) Chefs de projets 5 participants 3 h00 min


dysfonctionnements (5)

Acteurs intervenant dans

le projet R3PC 3 participants 2 h30 min

Atelier de formation (1) Membres des équipes

(CPM) 6 participants 13 heures

Atelier de formation (2) Architectes 6 participants 13 heures

3 réunions de « rendez-

vous d’information »

L’ensemble des membres

de l’entité Nextv

Environs 30

personnes/session 1 heure/session

2.2.2 Technique de l’entretien semi-directif

La réalisation des entretiens semi-directifs avec les acteurs concernés par le projet « lean »

constitue la seconde source de collecte de données sur laquelle repose notre démarche

qualitative.

Dans un premier temps, cinq entretiens ont été conduits avec des chefs de projets. L’ensemble

de ces entretiens a été enregistré. Par mesure de confidentialité, nous présenterons les

entretiens à travers des extraits (verbatim) et ne relèverons pas les noms des personnes

interviewées. Les personnes seront identifiées par deux lettres et leur rôle au sein de

l’organisation sera précisé. Ces entretiens consistent d’une part, à faire état du contexte dans

lequel œuvrent les chefs de projet (les pratiques et outils managériaux utilisés, forme

87Le rôle du CPM consiste à coordonner l’évolution des composants ou briques applicatives qui assurent un

certain nombre de fonctionnalités (briques qui servent de portail pour les utilisateurs, qui font l’interface avec

des applications de facturation, de commande, etc.). La mobilisation d’un même composant par différents

services ou plateformes nécessite un suivi régulier de la part du CPM qui, lui, va veiller à ce que le composant en

question a suivi les mêmes évolutions sur les différentes plateformes.


125

organisationnelle de la gestion de projet, la composition des équipes projets, le rôle du chef de

projet, etc.) et d’autre part, à repérer leurs perceptions à l’égard des outils managériaux

retenus par l’équipe « lean ». Ils constituent un moyen essentiel pour accéder aux

représentations et interprétations des situations par les acteurs. Les perceptions et les

expériences soulignées par les interviewés nous ont permis d’approfondir notre

compréhension de certains éléments peu divulgués durant les observations. Ensuite, un

entretien a été conduit, cette fois-ci avec le directeur de l’équipe « lean ». Cet entretien avait

pour objectif d’approfondir certains aspects liés à la démarche et d’éclairer les subtilités du

contexte et des actions entreprises. Le nombre limité d’entretiens avec les acteurs « lean »

s’explique par les échanges et les discussions informelles que nous avons continuellement

menés avec eux.

Ensuite, durant la phase de généralisation, nous avons réalisé une seconde vague d’entretiens,

cette fois-ci avec des acteurs internes et externes à l’entité Nextv. Nous avons interviewé des

architectes, des directeurs et des chefs de projets, des managers d’équipes de développement

et de qualification. Plus de la moitié des acteurs interrogés n’a pas fait partie de la phase pilote

de la démarche. Ces entretiens visaient d’une part, à développer une image assez précise des

modes managériaux adoptés par les équipes ; et d’autre part, à identifier les perceptions de ces

équipes de la démarche proposée par les acteurs « lean » et de leur collaboration entre elles.

Ces entretiens ont été conduits en présence d’un membre de l’équipe « lean ». 16 entretiens

ont été conduits durant cette seconde phase du projet « lean ».

Au total 21 entretiens d’une durée moyenne d’une heure et demie ont été réalisés (tableau 16).

Tableau 16 : Recension des entretiens réalisés

Acteur Entité Fonction

AM DDP (Développement) Directeur de projet R&D sur les services TV

JPR DDP (Développement) Manager d’équipe de développement

CM DDP (Développement) Manager d’équipe de développement

PC DDP (Développement) Manager d’équipe de développement

FB DDP (Développement) Scrum manager

PM IEP (Qualification) Responsable d’équipe de qualification


126

JF IEP (Qualification) Responsable du domaine d’intégration

FB Entité Nextv Directeur technique des plateformes de services

TV

GC Entité Nextv Directeur technique du projet très haut débit

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 département 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 Chef de projet (ZER2) rattaché à la direction

Grands Projet

PB Entité Nextv Chef de projet (R3PC) rattaché à la direction

Grands Projet

MC Entité Nextv Chef de projet (ZER2) rattaché à la direction

Grands Projet

JMW Entité Nextv Program Management Officer

2.2.3 Sources secondaires de recueil de données

Les documents et les discussions échangées par mèl constituent une source complémentaire

de données nous permettant d’approfondir nos connaissances relatives à notre contexte

d’étude. En effet, nous avons pu avoir accès (1) aux présentations rédigées par les membres

de l’équipe « lean » et diffusées auprès des équipes pilotes, (2) aux rapports de réunions

organisés par l’équipe « lean » avec le Codir, (3) à l’ensemble des mails échangés entre les

membres de l’équipe et ce, dès le lancement du projet. Notre présence sur la liste de diffusion

de l’équipe « lean » nous a permis de suivre en temps réel les questionnements des acteurs,

leurs préoccupations, leur raisonnement, etc.


127

2.3 Choix d’une méthode d’analyse thématique

Bien qu’il n’existe pas de moments particuliers pour commencer l’analyse des données, il est

communément admis de se baser sur une approche méthodique bien précise afin de traiter les

données collectées et d’accroître la validité des résultats. Les données qualitatives engendrent

des descriptions et des explications riches. Leur analyse consiste, tout d’abord, à « réduire les

informations pour les catégoriser, les mettre en relation, avant d’aboutir à une description,

une explication ou une configuration » (Wacheux, 1996, p.227).

Si la démarche d’analyse a commencé dès notre intégration sur le terrain de recherche,

l’organisation et la catégorisation des données s’est faite après la collecte et la retranscription

de celles-ci. Les retranscriptions ont été réalisées au fur et à mesure de nos observations. Un

fichier de synthèse a été élaboré à la fin de chaque observation restituant les informations

essentielles des évènements observés (date, participants, thèmes, principaux éléments

évoqués, etc.). Ces fichiers comprennent également nos intuitions et impressions générales

des phénomènes observés (Annexe XI-XII).

L’historique des évènements a été développé au fur et à mesure de l’avancement du projet. La

présentation chronologique des données nous a permis d’avoir une compréhension

progressive des phénomènes et du contexte appréhendé. Ensuite, nous avons procédé à

l’analyse thématique des données collectées 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 opéré par méthode inductive. Les idées

auxquelles renvoie(nt) chaque mot, phrase et/ou paragraphe du corpus de données ont été

identifiées pour ensuite être classées par catégories 88 puis par thèmes. Le principe de l’analyse

thématique consiste à aboutir à une décontextualisation-recontextualisation du corpus des

données collectées.

Concrètement, comment avons-nous procédé à l’analyse de l’ensemble des données

recueillies et transcrites ?

88Pour définir la notion de catégorie nous nous référons à la définition suivante : « une production textuelle se

présentant sous forme d’une brève expression et permettant de dénommer un phénomène perceptible à travers

une lecture conceptuelle d’un matériau de recherche. (…) À la différence de la « rubrique » ou du « thème », elle

va au-delà de la désignation de contenu pour incarner l’attribution même de la signification » (Paillé &

Muchielli, 2003 dans Blais & Martineau, 2006).


128

Dans un premier temps, nous avons commencé par coder les informations recueillies lors des

réunions auxquelles nous avons assisté « all codes are simply categories of data that

represent a thematic concern » (Gibson & Brown, 2009, p.133). Après plusieurs relectures

des données transcrites nous avons réduit les paragraphes ou les phrases en de simples

étiquettes où chacune renvoie à un sens précis. Nous rappelons ici que notre objet d’étude

consiste à comprendre la manière dont les acteurs, responsables de la mise en œuvre des outils

« agiles », contribuent, par le jeu de leurs interactions, à leur « fabrication ». De fait, l’analyse

des réunions s’est largement imprégnée de la grille d’analyse de sensemaking89 que nous

avons mobilisée pour saisir les pratiques situées de ces acteurs, leur mobilisation des

ressources, leurs activités interprétatives, etc. Cette grille nous a permis d’identifier les

passages critiques et utiles pour notre projet de recherche.

Il apparaît important, lors de l’analyse, que le chercheur ne s’éloigne pas de sa problématique

et de ses questions de recherche. Un ensemble de codes a ainsi été créé renvoyant aux

propriétés de la démarche de construction de sens des « innovations managériales » de type

« agile ». Cette étape s’est, par conséquent, matérialisée par une première vague de codes :

« questionnements des acteurs », « plausibilité de la démarche », « démarche prospective »,

« aspect rétrospectif », « délimitation de la démarche », etc. Nous illustrons cette première

étape de « codage » en nous appuyant sur des extraits de deux réunions codées.

89Cf. chapitre (III).

«« Dans les réunions quotidiennes aujourd’hui soyons réalistes, 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 s’attacher à des choses qu’on peut

gérer... »

Plausibilité Plausibilité

Choix d’acteurs internes Nombre limité de participants

Plausibilité

Illustration I : Analyse d'un extrait d'une réunion de l’équipe « lean »


129

L’ensemble des catégories a été définie de façon itérative et justifiée par des verbatim. Les

données « indexées » ont été réexaminées à plusieurs reprises et classifiées au fur et à mesure

dans des catégories « because code definitions are iterative, applying codes is often cyclical

rather linear » (Brown & Jacobs, 2009, p.136).

Catégorie Définition Verbatim

Plausibilité

Le raisonnement des acteurs est guidé par

la plausibilité plutôt que l’exactitude. Leur périmètre d’intervention se limite aux choses qu’ils estiment être capables de

réaliser.

« soyons réaliste, ne pas faire un

brief avec tout le monde »

« on va se contenter de notre entité… on a s’attacher à des

choses qu’on peut gérer »

Rétrospectif Les acteurs examinent leurs actions

passées pour agir à nouveau

« il est important d’avoir un retour

sur ses points de vue »

Aspect évolutif Lorsque les actions sont continuellement

reconstruites

« notre proposition n’est pas

quelque chose de définitif »

Illustration III : Classification des catégories des illustrations : I et II.

Au cours de l’analyse des réunions, d’autres catégories ont émergé renvoyant aux facteurs

contextuels ayant affecté les choix d’actions mises en œuvre par les acteurs « lean ».

L’analyse des pratiques situées des acteurs concernés par le projet a donné lieu à une

deuxième vague de codes : « taille des projets », « structure organisationnelle », « mode de

management existant », « géodistribution des équipes », « équipes instables », « réduction de

la fréquence des briefs », « culture de non prise de risque », « documentation extensive »,

« faible intérêt des parties prenantes », « manque de temps », etc.

Les catégories extraites de l’exemple suivant renvoient aux difficultés remontées par les

acteurs « lean » par rapport à la mise en place de la démarche.

« Il est important d’avoir un retour sur ses points de vue et perceptions de la

démarche… notre proposition n’est pas quelque chose de définitif, le chef de projet va

pouvoir réagir… » Aspect évolutif Aspect rétrospectif

Aspect rétrospectif

Illustration II : Analyse d’un extrait d’une réunion de l’équipe « lean »


130

Dans un deuxième temps, nous avons codé l’ensemble des entretiens en suivant la même

logique d’analyse. Les idées présentant un même sens ont été classées sous une même

catégorie. Un ensemble de catégories a été créé renvoyant (1) aux déterminants contextuels

qui semblent affecter la mise en œuvre des pratiques « agiles », (2) aux représentations des

acteurs de leur mode managérial, (3) aux perceptions de la collaboration intra et inter-équipes,

(4) aux perceptions de l’utilité de la démarche proposée, etc.

Illustration VI : Catégories renvoyant aux difficultés perçues par les acteurs pilotes

« C’est un gros problème pour nous organiser plus facilement sachant qu’on est

reparti…… En tant que chef de projet, on n'a pas de management d'équipe, on gère

notre équipe sur un projet mais il n’y a personne qui m'est rattachée. Je n'évalue le

travail de personnes par exemple… »

Géolocalisation Complexité organisationnelle

Profil de coordinateur de projet

Illustration V : Analyse d’un extrait d’un entretien avec le chef de projet

« Les personnes qui sont partagées sur plusieurs projets peuvent être sollicitées sur

plusieurs brief… si je vais encore faire ces daily briefs, je vais passer mon temps à faire

des réunions… »

Acteurs métiers transverses

Multiplicité des réunions

Illustration IV : Analyse d’un extrait d’une réunion de l’équipe « lean »

« Il y a un besoin d’implication du top management, à part le directeur général qui est

très sponsor sur le sujet, je n’ai pas l’impression que les autres membres du top

management soient autant impliqués… Le chef de projet est un chef d’orchestre, il ne

maîtrise pas les activités des contributeurs qui ont leurs contraintes et priorités »

Implication du top Management

Profil de coordinateur du projet Indisponibilité


131

Catégories Définition Verbatim

Multiplicité des

réunions Abondance des réunions existantes.

« si je vais encore faire ces daily briefs, je vais passer mon temps à faire des

réunions »

Coordinateur du projet

Autorité limitée du chef de projet. Rôle de coordinateur des différentes unités

fonctionnelles.

« le chef de projet est un chef d’orchestre, il

ne maîtrise pas les activités des contributeurs » ; « on n'a pas de

management d'équipe… il n’y a personne

qui m'est rattachée… Je n'évalue le travail de personnes »

Acteurs métiers Acteurs rattachés à des services

fonctionnels et mobilisés ponctuellement.

« les personnes qui sont partagées sur plusieurs projets peuvent être sollicitées sur plusieurs brief » ; « des contributeurs qui

ont leurs contraintes et priorités »

Equipe

complexe

Equipe de grande taille, dispersée, mobilisant des ressources communes

avec d’autres équipes, composée d’acteurs transverses.

« c’est un gros problème pour nous

organiser plus facilement »

Géolocalisation Si les personnes travaillant sur un

même projet sont dispersées géographiquement

« sachant qu’on est reparti »

Implication de la direction

Support de la direction en termes d’orientation de la démarche, de

moyens

« il y a un besoin d’implication du top management…je n’ai pas l’impression que

les autres membres du top management

soient autant impliqués… »

Illustration VII : Classification des catégories (illustrations IV, V et VI)

En ce qui concerne les altiers de dysfonctionnements, nous avons procédé à la classification

des problèmes en fonction des causes explicites auxquelles chacun renvoie. Ensuite, nous

avons classé ces problèmes en fonction du type de gaspillage90 auquel chacun renvoie.

(Illustration VIII).

90Afin d’identifier les formes des gaspillages générés nous nous sommes basés sur la liste des sept gaspillages

décrite dans l’ouvrage des Poppendieck (2006).

Illustration VIII: Les dysfonctionnements et leurs causes

« Il nous arrive souvent d’arrêter un travail parce qu’il est moins prioritaire et puis on

essaye de le reprendre et donc de se remettre dans le contexte... Certains sujets sont

traités plusieurs fois par les différents niveaux hiérarchiques ce qui entraîne une perte

globale de temps, une dilution de l’information….. »

Arrêt/reprise du travail Absence de stratégie de priorisation

Tâches redondantes Multiplicité des échelons


132

Enfin, les mails échangés entre les acteurs de l’équipe « lean » ont été codés selon la même

méthode d’analyse.

Au fur et à mesure de l’avancement du processus d’analyse les catégories ont été regroupées

par thème créant ainsi une cohérence entre elles (Illustration IX). Des similarités dans les

représentations des acteurs observés et interrogés ont toutefois émergé.

Thème Catégories

Caractéristiques des équipes

Géolocalisation

Acteurs métiers

Complexe

Illustration IX : Regroupement des catégories par thème

Pour ce qui est du regroupement des dysfonctionnements remontés, ceux-ci ont été recensés

dans un tableau à part où ils ont été illustrés par des verbatim.

Dysfonctionnements Effets engendrés Citations

Absence de stratégie de priorisation

Arrêt et reprise d’un même travail

« Il nous arrive souvent d’arrêter un travail

parce qu’il 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…. »

Multiplicité des échelons

hiérarchiques Tâches redondantes

« Certains sujets sont traités plusieurs fois par

les différents niveaux hiérarchiques ce qui entraîne une perte globale de temps… »

Dépendance entre les phases des projets

Temps d’attente

« J’ai tendance à me focaliser sur les

dépendances entre les projets… le problème c’est qu’un retard sur un projet impacte un

autre projet…. »

Illustration X : Regroupement des dysfonctionnements et de leurs effets

Après avoir catégorisé l’ensemble des données textuelles, nous avons procédé à l’explication

de celles-ci : qu’est ce qui a conduit les acteurs à un tel énoncé ? Quel est l’impact de tel ou

tel facteur contextuel ? Pourquoi tel choix d’action ?, etc. Des liens ont été créés entre les

différentes catégories.

Bien que notre analyse thématique se veuille inductive, le cadre conceptuel autour duquel se

construit notre objet de recherche, a fortement influencé le type de catégories identifiées.


133

Cependant, l’agrégation des catégories et l’interprétation de celles-ci dépendent des questions

de recherche, des modèles recherchés, 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 méthode d’analyse adoptée par le

chercheur, l’interprétation relève des connaissances de celui-ci, de ces capacités d’identifier

les commentaires subtils des personnes observées.

2.4 Triangulation des données et des chercheurs

Les définitions et les objectifs du concept de triangulation varient. Denzin (Denzin, 1978 dans

Stake 1995) identifie quatre types de triangulation: (1) triangulation des données qui consiste

à utiliser différentes sources de données : temps, situations et individus ; (2) triangulation des

chercheurs lorsque plusieurs personnes sont impliquées dans la collecte des données et leur

interprétation « 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 troisième forme de

triangulation est celle des « théories 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 quatrième

approche correspond à la triangulation méthodologique : les chercheurs utilisent différentes

méthodes de collecte de données pour étudier un même phénomène « 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 données

(acteurs occupant différents statuts et œuvrant dans différents contextes) et d’instruments de

collecte de données (observations-entretiens-documentation) nous a permis d’enrichir notre

champ de connaissances et d’approfondir nos analyses. En outre, les workshops auxquels

nous avons participé (notamment en forme de data sessions), en présence d’experts en

sciences de gestion, nous ont permis d’accroître la validité des données transcrites et

interprétées. Ces workshops nous ont offert la possibilité de faire part de nos analyses et

interprétations de données. Les retours remontés durant ces workshops ont, d’un côté,


134

participé à valider notre processus d’analyse et d’un autre côté, fait émergé de nouveaux

questionnements et points à investiguer. Par ailleurs, les rapports d’analyse des entretiens

menés auprès des chefs de projets ont été soumis aux membres de l’équipe « lean ». L’accord

de ces derniers sur les données interprétées nous a permis d’accroître la validité de nos

interprétations. Le processus de « member-checking » (Stake, 1995) consiste à ce que les

acteurs, participant à l’étude, examinent les interprétations du chercheur et procurent à celui-

ci des informations et interprétations supplémentaires. Enfin, les entretiens conduits avec le

directeur du projet « lean » furent une occasion de nous assurer de la validité des données

recueillies et de clarifier certains questionnements relatifs à la démarche et au contexte étudié.

135

136

CChhaappiittrree VV :: VVaarriiaabblleess ddee ccrrééaattiioonn ddee sseennss

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

La première expose les dysfonctionnements tels qu’ils ont été remontés par les équipes

projets. L’identification des dysfonctionnements a permis de dresser l’état des lieux des

projets et de légitimer la démarche d’amélioration entreprise.

La seconde met en avant les facteurs d’ordre contextuel tels qu’ils ont été identifiés par les

acteurs organisationnels et qui ont manifestement influencé la manière dont la démarche

managériale a été mise en place.

Chapitre V – Variables de création de sens de la démarche

137

La stratégie de recherche adoptée a pour but de rendre compte de la manière dont les

acteurs responsables de la mise en œuvre des « innovations managériales » que seraient les

méthodes « agiles » font sens de celles-ci et de leur contexte d’application. L’approche

d’analyse « par la pratique » s’est ainsi focalisée sur les pratiques de ces acteurs, la manière

dont ils combinent et coordonnent leurs ressources discursives, motivationnelles et cognitives

pour construire et mettre en place une stratégie managériale de type « agile ».

Nos observations et analyses révèlent que la notion de gaspillage constitue un point d’appui

essentiel pour les acteurs souhaitant s’engager dans une démarche d’amélioration de type

« agile ». Toutefois la « construction » et la mise en œuvre de cette dernière relèvent d’un

ensemble d’éléments d’ordre contextuel.

1. Le gaspillage dans les projets pilotés par Nextv

La mise en place d’ateliers d’identification des dysfonctionnements a constitué le point de

départ de la démarche « lean ». Sept ateliers ont été organisés avec des membres d’équipes

projets91 et d’équipes métiers92 en vue de dresser l’état des lieux des projets. Ces ateliers ont

donné l’occasion aux acteurs « lean » d’examiner le fonctionnement des équipes de l’entité

Nextv, d’en évaluer les faiblesses et de mettre en place une stratégie d’évolution basée sur les

méthodes « agiles ».

Au cours de ces ateliers, les participants ont été amenés à lister les dysfonctionnements, à

mesurer l’ampleur des zones à problèmes en termes de temps perdu (J/H) et à en analyser les

causes racines à travers les outils93 présentés par l’équipe « lean ». Quatre vingt dix-huit

dysfonctionnements ont été soulignés.

91 Cf. tableau (12). 92Chefs de projet, managers de composants, architectes. 93

QQCQOP, la méthode des 5 Pourquoi.

Chapitre V : Variables de création de sens de la démarche

138

Afin de mieux cerner les formes de dysfonctionnements citées, nous les avons classés par

type de gaspillage en nous appuyant sur la liste classique des sources de muda répertoriées par

Shigeo Shingo94 dans l’ouvrage des Poppendieck (2006).

1.1 Analyse et classification des dysfonctionnements par type de gaspillage

La production excessive constitue une première forme de gaspillage présente dans les projets

menés à Nextv. De nombreuses fonctionnalités et documentations sont développées alors

qu’elles se révèlent, par la suite, inutiles. La rareté des occasions de communication entre les

acteurs métiers (réunions hebdomadaires organisées par le chef de projet avec des « bouts »

d’équipes) et l’absence d’un environnement visuel (diffusion des informations par le biais des

reporting, documentation exhaustive des différentes activités) rendent difficile la cohésion

inter-équipes et la création de vision commune du projet (tableau 17). Les acteurs métiers ont

tendance à anticiper certaines activités et à prendre des initiatives sans pour autant les

communiquer systématiquement à leurs paires. L’approche basée sur la planification et

l’anticipation, valorisée par les chefs de projet, semble générer des coûts additionnels: coûts

de qualification et de maintenance de codes inutiles, documentations obsolètes, etc.

Bien que certaines équipes de développement se base sur des cycles itératifs pour

programmer, elles sont parfois amenées à anticiper leurs activités de développement pour

pouvoir répondre aux délais imposés par les chefs de projet qui, selon elles, ont tendance à

sous-estimer la charge du travail requis. Les activités planifiées à l’avance peuvent ainsi

conduire à une production de fonctionnalités inutiles et de charges supplémentaires. Dans une

perspective lean, les processus de développement doivent être à flux tirés: les activités sont

déclenchées en fonction des besoins exprimés durant les phases précédentes. Ce sont les

échanges permanents entre les acteurs métiers et la mise en œuvre d’outils de management

visuel qui permettent d’offrir une vision partagée des besoins. Le déploiement des techniques

« pull », sur l’ensemble des phases du cycle de vie de projet aiderait également les équipes à

produire la quantité exacte des demandes requises en termes de spécifications, 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 décidé de mettre en place des réunions

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


139

quotidiennes et un management visuel instrumentés par un tableau blanc et des indicateurs de

performance.

Tableau 17: Les causes de la surproduction

Types de dysfonctionnements Citations

Manque de vision globale

« 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 d’initiatives des équipes de

développement qui ne sont pas communiquées au CPM voire au projet et qui ont un impact. On a là une optimisation des codes

qui va générer une qualification or ce n’était pas du tout

prévu ».

Pilotage par les délais et anticipation des activités

« moi j’avais un point sur le pilotage par les délais qu’on nous impose...C’est à dire on nous impose en gros une date de

remise de livraison en assemblage sans forcement tenir compte de la charge au niveau de développement pour pouvoir réaliser le périmètre…on se retrouve à anticiper les développements, à

quasiment développer avant le T-1…. il nous arrive donc de faire des développements inutiles »

L’attente renvoie à une deuxième forme de gaspillage remontée lors de ces ateliers. Elle se

manifeste par des acteurs inoccupés, en situation d’attente d’informations précises, de

décisions hiérarchiques, de validation de résultats ou de ressources momentanément

indisponibles. Les acteurs peinent à identifier les interlocuteurs capables de les assister dans

les problèmes rencontrés ou de les aider à répondre à leurs questionnements. Les délais

d’attente sur les phases des projets peuvent ainsi s’expliquer par : la multiplicité des canaux

de communication et de décideurs, la conduite simultanée de plusieurs projets et leur

mobilisation de ressources communes, la dépendance entre les phases d’un projet,

l’indisponibilité des informations recherchées et/ou la faible fiabilité des données disponibles

(tableau 18). Pourtant, dans une organisation lean, le temps consacré à la recherche

d’informations est considéré comme une source de gaspillage majeure qu’il convient

d’éliminer. De fait, les échanges réguliers entre les acteurs (« daily meetings », ateliers

kaizen) peuvent améliorer la collaboration entre les membres de l’équipe et réduire le temps

consacré à la recherche d’informations. La réduction des temps d’attente s’obtient aussi par le

biais d’une meilleure synchronisation entre les acteurs projets : la colocalisation de l’équipe et

l’autonomie accordée aux membres de celle-ci, préconisées par le courant « agile », semblent

réduire ces délais et accélérer les prises de décisions et le déploiement d’actions correctives.

De plus, la simplification des chaînes de décisions et la décomposition des projets en modules


140

indépendants ont été présentées comme des mesures efficaces pour favoriser les échanges

rapides d’informations et éviter qu’une même ressource soit sollicitée par différents acteurs. Il

est tout de même important qu’une information soit disponible au moment exact ; trop tôt, elle

risque d’être modifiée et trop tard, oubliée (Poppendieck, 2006).

Dans le présent contexte, les acteurs « lean » se sont contentés de mettre en place des ateliers

kaizen et des réunions quotidiennes afin d’améliorer la collaboration entre les équipes et la

capitalisation sur les bonnes pratiques. Si ces deux solutions peuvent réduire le temps

consacré à la recherche d’informations, elles peuvent difficilement irradier les temps d’attente

causés par la multiplicité des canaux de communication, les processus « rigides » de prises de

décision et la dépendance entre les phases du projet.

Tableau 18: Les causes des temps d’attente


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 qu’on a en parallèle compliquent la gestion des

ressources » ; « les responsables transverses sont extrêmement

sollicités… c'est vrai qu'on a des gens qui sont à des positions assez cruciales qui se retrouvent quand même un petit peu à cheval sur deux projets qui sont assez pris au chaud » ; « les

développeurs se comportent comme des SSII si on leur donne pas du boulot pendant un mois, ils partent sur un autre sujet ».

Dépendance entre les phases des

projets

« j’ai tendance à me focaliser sur les dépendances entre les projets… le problème c’est qu’un retard sur un projet impacte un

autre projet » ; « lorsqu’on a un retard sur un projet, ça retarde le planning global »

Multiplicité des acteurs « décideurs »

« Les chefs de projet sont en attente du comité des services

d’achats pour les décisions budgétaires donc là les développeurs rentrent dans les problèmes de rapports, de prises de décisions » ;

« aujourd’hui on demande quelque chose on passe par le cpm, le cpm par l’architecte, l’architecte par les 3P ou le market qui demande à ces 5 collègues si c’est bon, etc. et donc ça revient

après 3 semaines et c’est toujours le même circuit….. » ; « après deux semaines du T0, le R&D n’avait toujours pas fourni le

planning….En conséquence on ne sait pas si le T3 annoncé est

réalisable ou pas… »

« Rigidité » du cycle de vie séquentiel

« au fait, on nous propose une solution, nous on va la proposer sur papier côté ingénierie et puis après il faut qu’elle soit

qualifiée par IEP et donc il peut y avoir du temps entre les deux ce qui fait qu’on met plein de temps pour la mettre en œuvre et on

s’en rend compte au final qu’elle ne fonctionne pas…. »


141

Indisponibilité de l’information

recherchée

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

dont dispose cet outil ne sont pas fiables et suffisamment précises pour faire un bon bilan… »

Les transports et manutentions inutiles constituent un troisième type de muda en

développement informatique. Les déplacements physiques des documents et les allers-retours

de mails peuvent ralentir le processus de traitement des demandes et par conséquent les

activités des différents collaborateurs. Au sein de Nextv, les échanges inutiles d’informations

relèvent de la structure des projets, de la multiplicité des acteurs et du manque de clarification

des rôles à l’intérieur de l’organisation. Cette forme de gaspillage rejoint celle présentée plus

haut (l’attente). Citons comme exemple, une activité de développement bloquée par l’attente

d’une décision du marketing. Dans l’entité étudiée, le transfert d’une demande au marketing

doit passer par différents acteurs (chefs de projets, CPM, etc.) avant d’être complètement

traitée (tableau 19). L’information peut alors s’égarer avant d’atteindre son destinataire

engendrant ainsi des attentes et des retards. Il apparaît donc légitime de court-circuiter le trajet

de la demande en diminuant le nombre d’acteurs « décideurs » et de clarifier les rôles et les

responsabilités au sein des équipes projets. Toutefois, ce type de solution n’a pas été envisagé

par les acteurs « lean » principalement en raison du temps et des efforts qu’un tel changement

nécessiterait. Cela dit, il faudrait redéfinir les responsabilités et les rôles de chacun et

convaincre l’organisation de réduire la « rigidité » des processus en créant des liens directs

entre les parties prenantes d’un projet.

Tableau 19: Les causes des transports inutiles


Mauvaise identification des bons interlocuteurs

« tu as des demandes d’évolution qui viennent d’une vision

produit de marketing mais qui remontent par les mauvais tuyaux et donc finalement ça prend du temps pour être traité et priorisé » ; « c’est vrai que parfois les gens se demandent un

peu par qui le projet est piloté…comme je te le disais on a énormément de collaborateurs» ; « on a des lacunes à mettre

des noms sur les personnes travaillant sur une activité ou un composant »

Les étapes supplémentaires en développement de logiciels concernent principalement les

activités redondantes ainsi que les arrêts et reprises d’une même tâche ou activité. Ce type de

gaspillage a souvent été remonté dans les discours des acteurs participant à la démarche pilote

95Il s’agit d’un outil de gestion de base de données.


142

(tableau 20). En effet, la reprise d’une tâche suspendue engendre des pertes de temps

considérables. Elle nécessite des efforts supplémentaires de la part de l’acteur responsable

dans la mesure où celui-ci est amené à se remettre dans les conditions préalables alors qu’il

s’est déjà impliqué dans d’autres tâches. Ces formes de gaspillage sont dues d’une part, au

manque de communication et de vision globale du projet et d’autre part, à l’absence de

stratégies 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 d’études. Dans un tel contexte, les décisions sont souvent

traitées à plusieurs reprises en raison du grand nombre d’acteurs et d’échelons hiérarchiques

impliqués dans les projets. L’instabilité des équipes et l’intervention des acteurs transverses

sur différents projets les conduisent à délaisser une tâche au profit d’une autre. Enfin, la

dispersion géographique des acteurs et l’autorité limitée dont dispose le chef de projet rendent

difficile le contrôle et le suivi régulier des activités effectuées. L’élimination d’un tel

gaspillage pourrait être envisagée par une redéfinition de la structuration des projets et de la

composition des équipes. A l’heure actuelle, les acteurs « lean » sont incapables de s’attarder

sur des éléments qui relèvent de la structure globale des projets et des équipes.

Tableau 20: Les causes du travail supplémentaire

Types de

dysfonctionnements Citations

Absence de stratégie de priorisation

« il nous arrive souvent d’arrêter un travail parce qu’il 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 problème est qu’il nous arrive d’arrêter le déroulement du projet en

phase étude ou développement pour nous mettre sur quelques chose d’autre…ça génère des pertes de temps »

Manque de vision globale

« il y a des difficultés à 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é

d’avoir une vision globale de ce qui va être fait…beaucoup de fois on a

été amené à reprendre la partie étude parce qu’il y a des conclusions qui sont fausses »

Multiplicité des niveaux hiérarchiques

« certains sujets sont traités plusieurs fois par les différents niveaux hiérarchiques ce qui entraîne une perte globale de temps, une dilution de l’information et parfois une mauvaise interprétation vu qu’il manque des

informations et des décisions non comprises »

Planification et

documentation extensives

« on dépense beaucoup d’énergie dans la phase d’étude à faire des estimations, à faire le planning et après on se rencontre qu’on est amené à

faire de nouvelles estimations de planning »

Autorité limitée du chef de projet

« son chef lui a dit de ne plus bosser sur le truc mais sans me prévenir.

Souvent tu leur délègues des trucs et ce n'est pas forcement suivi comme tu attends » ; le chef de projet est un chef d’orchestre, il ne maitrise pas

les activités des contributeurs qui ont leurs contraintes et priorités».


143

Une cinquième forme de gaspillage que nous retrouvons dans les projets relève de

l’inventaire. En industrie automobile l’inventaire renvoie aux stocks inutiles qui génèrent des

gaspillages parce qu’ils occupent un espace physique, nécessitent des déplacements et une

maintenance. Dans le développement informatique, ce type de gaspillage concerne plutôt le

travail partiellement effectué ainsi que la documentation et les fonctionnalités non

nécessaires. Dans le contexte qui nous intéresse, le manque d’échanges réguliers entre les

acteurs, l’absence de stratégies 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 à l’origine de ce gaspillage : la longue durée des projets accroît les

probabilités d’abandon du travail d’une part et les livrables des activités de planification et de

documentation, valorisées par les équipes, risquent l’obsolescence d’autre part. Les reporting

réalisés et les spécifications fonctionnelles détaillées ont un coût considérable en termes de

temps accordé à leur production et de gaspillages liés à leur non utilisation. Selon les acteurs

interrogés, de nombreuses documentations sont produites durant les phases de planification et

de conception d’un produit engendrant des stocks inutiles, particulièrement, lorsque le produit

final n’est pas mis en production. La documentation extensive peut s’expliquer par la culture

de non prise de risque de l’organisation. A cette fin, un plan d’action a été mis en place en vue

de réduire le taux de la documentation.

Tableau 21: Les causes de l’inventaire


Absence de stratégies de priorisation

« il y a des changements de priorité entre les différentes fonctionnalités et entre différents projets…on passe du temps à faire un truc et finalement ils nous demandent de laisser tomber

et de commencer un nouveau truc »

Mauvaise clarification des

demandes du marketing

« les clients changent souvent leurs demandes et nous demandent par conséquent de changer nos priorités, on modifie

le périmètre d’un projet déjà lancé pour intégrer une autre partie …. »

Planification et documentation extensives

« on dépense beaucoup d’énergie dans la phase d’étude à faire des estimations, à faire le planning et après on se rencontre

qu’on est amené à faire de nouvelles estimations de planning et

ça j’estime que c’est un gros problème…»

La multiplication des réunions, les déplacements physiques et la réalisation de diverses tâches

simultanées, constituent une autre forme de gaspillage : les mouvements inutiles. La

distribution physique des membres d’une équipe accroît les probabilités de déplacement des

acteurs entre les sites. Dans un tel contexte, le manque de communication spontanée sera


144

compensée par des réunions de longues durées, organisées à distance, durant lesquelles divers

sujets et problèmes seront abordés et traités. Or, un ensemble de coûts est associé aux

déplacements physiques des acteurs (taxi, train, hôtel, séjour, etc.) et à la communication et

partage virtuel de documents. Dans le présent contexte, le chef de projet organise des réunions

hebdomadaires avec des « bouts » d’équipes métiers en raison de la grande taille des équipes.

Ces réunions nécessitent, dès lors, beaucoup d’efforts en termes de documentation - une

quantité de reporting est ainsi diffusée à la fin de chaque réunion - sans toutefois garantir le

partage d’une vision globale du projet (tableau 22). Les demandes et les exigences sont

souvent mal clarifiées engendrant un « retravail », des retards et des coûts supplémentaires. A

première vue, ce type de gaspillage peut être réduit par des réunions organisées, à distance,

avec l’ensemble des acteurs projets. La mise en place d’outils technologiques performants

pourrait être une solution pour améliorer la qualité de la communication et assurer un partage

rapide de documents. Dans cette optique, l’équipe « lean » a décidé de recourir aux réunions

quotidiennes afin de favoriser les échanges entre les différentes équipes et améliorer la vision

globale du projet.

Tableau 22: Les causes des mouvements inutiles


Multiplicité des reporting

« j’ai un compte rendu global dans lequel je donne les liens vers tous les comptes rendus (reporting) avec les clients, les

opérationnels, les architectes. Ils se trouvent sur Roll et envoyé

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 »

Multiplicité des réunions

« 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 même heure

pour les participants. J'ai plusieurs points d'équipes ».

Enfin un dernier type de gaspillage répertorié en industrie automobile et que nous retrouvons

dans notre terrain de recherche concerne les défauts. Dans une industrie automobile, le

repérage tardif des pièces défectueuses et des rebuts se trouvent à l’origine de nombreux

surcoûts. La grande taille des projets et le pilotage par les délais imposés par les chefs de

projets entraînent les équipes à anticiper leurs activités mettant en péril la qualité de leur

travail. Souvent la solution livrée n’est pas conforme aux attentes des clients. A cet effet, des

surcoûts et des retards de livraison sont engendrés induisant une insatisfaction des clients. La

boîte à outils lean (l’andon, 5 pourquoi, Pareto des causes, A3, etc.) pourrait être utile pour

détecter rapidement les défauts, analyser les causes racines et standardiser les bonnes pratique


145

jusqu’à ce qu’elles soient remplacées par d’autres meilleures pratiques (principe

d’amélioration continue). Au sein de Nextv, les acteurs se plaignent d’une part, de nombreux

bugs qui apparaissent après le développement et d’autre part, de la qualité des documents

produits. Leurs systèmes d’anticipation et de détection rapide des défauts s’avèrent peu

efficaces. Afin de remédier à ce type de difficultés, les acteurs « lean » ont opté pour la mise

en place d’outils96 d’identification et de résolution de problèmes. Les outils qu’ils ont retenus

ne permettent pas d’anticiper les problèmes mais de les identifier et de les résoudre après leur

apparition. D’un point de vue lean, le recours à des « détrompeurs », tels que les tests

unitaires automatisés, les tests fonctionnels, l’intégration continue, etc. permet d’anticiper les

problèmes et de réduire les anomalies. Cependant, la mise en place de ces outils n’a pas été

envisagée par les acteurs « lean ». Cela s’explique par le fait que les équipes concernées par la

démarche n’étaient pas impliquées dans les activités de programmation. D’autres

dysfonctionnements ont été soulignés renvoyant à la dépendance entre les composants, au

manque de capitalisation sur les bonnes pratiques, au manque de communication avec le

client, etc. (tableau 23). Mais ces dysfonctionnements n’ont pas été traités dans la démarche

« lean » pour des raisons liées aux investissements que leur traitement nécessitent en termes

de temps, d’efforts, d’implication du marketing, de support, etc.

Tableau 23: Les causes des défauts

Types de

dysfonctionnements Citations

Grande taille des

projets

« 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 qu’ils attendaient…. »

Dépendance entre les composants

« quand on fait une évolution ça va forcément impliquer un autre composant

et donc quand ça arrive dans le développement ont met en péril la cohérence de l’ensemble de la solution technique au niveau projet »

Faible réactivité face aux problèmes

rencontrés

« s’il y a un bug sur une livraison, l’équipe ne fait rien…. on attend… le temps d’attente est d’un mois…. », « il y a un problème de suivi de bugs… »

Non capitalisation des bonnes pratiques

« il n’ya pas de capitalisation des compétences lors de changement de prestation…» ; « Il y a une difficulté de capitaliser sur les compétences en

cas de changement de prestataire »

Pilotage par les délais

« l’anticipation des développements à partir des délais imposés par le projet sans tenir compte des charges de développement impacte la qualité des

développements : fonctionnalités absentes, beaucoup de bugs, et performance non optimale »

Mauvaise définition des demandes du client

« au niveau de la phase étude, on développe selon les idées des architectes et

des CPM et non pas comme le client veut »

96

La démarche PDCA, la méthode des 5 Pourquoi, le QQCQOP.


146

Multiplicité des interlocuteurs

« il nous arrive souvent de détecter un problème mais on n’a pas un point

d’entrée bien précis… On a plusieurs acteurs mais on ne sait pas qui contacter… » ; « le suivi de la résolution d’un problème est trop long du fait de multiplicité des acteurs engagés ou concernés – je suis d’accord avec toi,

pour moi il y a trop d’acteurs sur un même sujet …».

Manque de fiabilité de la documentation

« on a un vrai problème de déficit 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 Démarche plausible de résolution des dysfonctionnements

D’un point de vue général, les rares occasions d’échanges entre les parties prenantes (chefs de

projets, architectes, marketing, équipes de développement, de qualification, de maintenance,

CPM, etc.) ont affecté la coordination, le suivi et le contrôle de activités réalisées. Des prises

d’initiatives et des changements ont eu lieu tout au long du cycle de vie des projets sans être

communiquée systématiquement, ce qui a eu pour conséquence, l’apparition

d’incompréhensions et d’insatisfactions par rapport aux décisions et actions entreprises. Outre

ce déficit de communication entre les acteurs projets, d’autres facteurs organisationnels et

managériaux se trouvent à l’origine des dysfonctionnements identifiés. Nous les avons

regroupés dans les catégories suivantes : le mode de management, les caractéristiques des

projets et la structure organisationnelle dans laquelle ces derniers sont pilotés.

Le style de management appliqué par les managers de l’entité Nextv repose, en général, sur

une vision séquentielle de projets, des activités de documentation et de planification

extensives et sur un pilotage par les délais. Ce mode managérial, bien que valorisé par

certains chefs de projets, a été remis en cause par différents acteurs de la direction des

plateformes de services (DPS). Il est fort probable qu’il soit à l’origine du manque de

visibilité des projets, des demandes non clarifiées, de la mauvaise qualité des codes

développés et des délais d’attentes. Quant aux caractéristiques des projets, habituellement de

grande taille et de longue durée, elles semblent constituer une source significative de

gaspillage induisant des pertes de temps (en raison de la multiplicité des acteurs

« décideurs »), des surcoûts et des retards (du fait que les changements sont plus coûteux et

difficiles à gérer dans des projets de longue durée). Enfin, d’autres problèmes évoqués

remontent à la structure de type lightweight des projets pilotés par Nextv. L’autorité limitée

dont dispose le chef de projet pour coordonner ses équipes métiers et l’intervention

temporaire de celles-ci dans divers projets, compliquent la gestion des ressources (acteurs


147

sollicités sur différents projets), la capitalisation des connaissances (équipes instables) et la

recherche d’informations (multiplicité des niveaux hiérarchiques et des interlocuteurs).

Les projets tels qu’ils sont menés au sein de la direction des plateformes de services (DPS) et

en particulier au niveau de l’entité Nextv renvoient à différents types de dysfonctionnements

managériaux et organisationnels qui sont liés et se recoupent. Ces dysfonctionnements ne

relèvent pas uniquement des pratiques de management de projet des équipes de l’entité Nextv

mais aussi de l’organisation de la direction dont elle fait partie.

Si les acteurs « lean » se sont attachés à analyser, avec les participants des ateliers, les causes

majeures d’un certain nombre de dysfonctionnements, ils ne sont pas allés au-delà de la

relation binaire entre le problème et la cause initiale. Autrement dit, ils ne se sont pas attardés

sur les origines multiples que chaque problème évoqué peut avoir. Par conséquent,

s’intéresser uniquement à la cause explicite du problème ne conduit pas nécessairement à sa

résolution. Par exemple, un produit non-conforme aux attentes du marketing ne s’explique pas

uniquement par une mauvaise définition de la demande. Il peut résulter d’une mauvaise

gestion des priorités, des changements qui ne sont pas pris en compte, d’une mauvaise

communication entre les architectes et les développeurs, etc.

D’une manière générale, les problèmes remontés au cours de ces ateliers ont été interprétés

comme un manque de communication et d’échanges 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 possibilités d’actions limitées, les difficultés d’implication de certains acteurs

clés, les intérêts personnels et collectifs, etc. De fait les acteurs « lean » se sont contentés des

solutions plausibles qui se trouvent à leur portée. Nous reviendrons dans le chapitre (VI) sur

cette notion de plausibilité. Ainsi, ils se sont attachés à identifier et à définir les outils

« agiles » capables de répondre aux problèmes majeurs retenus : le manque de communication

et de visibilité sur les projets.

« On ne communique pas assez entre nous au sein d’une équipe projet, entre les paires

faisant le même métier. 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'expériences et un enrichissement entre les

personnes…. » (RB) ;


148

« A mon avis, il y a donc un élément essentiel c’est de rendre les acteurs plus concernés par

les interactions… … » (TR) ;

« L’animation par le brief, le tableau de bord et les indicateurs peuvent apporter quelque

chose aux chefs de projets » (TR).

L’identification des dysfonctionnements a constitué un point d’entrée légitime pour justifier la

démarche d’amélioration entreprise par l’équipe « lean ». Cependant, parmi les quatre vingt

dix huit dysfonctionnements cités, seuls huit ont fait l’objet d’une analyse approfondie et, par

conséquent, ont conduit à des plans d’action97 assez relativement précis. Les actions

d’amélioration ont été menées, sous forme d’ateliers animés par différents « porteurs98 » et

dans lesquels est impliqué un certain nombre de contributeurs. Chaque plan d’action vise à

agir de façon ponctuelle sur le dysfonctionnement par lequel le groupe d’acteurs (porteur et

contributeurs) est concerné. Le tableau (24) expose deux problèmes avec leurs plans d’actions

tels qu’ils ont été formulés par les acteurs « lean » et validés subséquemment par le Codir.

Dans le cadre de ce travail, ne nous attarderons pas sur la manière dont le contenu des plans

d’action a été négocié et décidé entre les acteurs « lean » et le Codir et ce, pour deux raisons

principales : (1) nous n’avons pu avoir accès aux réunions organisées entre le Codir et

l’équipe « lean », ce qui nous empêché d’examiner de près la construction et la validation des

plans d’actions ; (2) ces plans d’actions ne constituent pas une fin en soi. En dehors de la

solution ponctuelle à laquelle chacun renvoie, ils se présentent comme un moyen mobilisé par

les acteurs « lean » pour illustrer la méthode99 d’amélioration que les équipes projets sont

invitées à intégrer dans leur mode de fonctionnement. En revanche, nous nous focaliserons

davantage sur les raisons, données par l’équipe « lean », qui expliquent leurs choix quant aux

dysfonctionnements et plans d’actions retenus : (1) la faisabilité des solutions à mettre en

œuvre, (2) le gaspillage en terme (J/H) engendré par chaque problème et (3) les enjeux

politiques du Codir à résoudre les problèmes retenus. Divers facteurs semblent avoir affecté le

choix stratégique des dysfonctionnements à traiter et des solutions100 à mettre en œuvre : les

intérêts collectifs, les possibilités d’action, leurs représentation quant à l’impact des

dysfonctionnements sur les projets, etc. Afin de mieux clarifier ce propos, nous consacrerons,

97Cf. tableau (13). 98Il s’agit d’une personne identifiée par l’équipe « lean » pour se charger de la mise en place de l’action au

niveau d’un groupe de « contributeurs » interne et/ou externe à l’entité qu’il parait important d’impliquer. 99Elle consiste à identifier les dysfonctionnements, à les analyser, à mettre en place des plans de résolution et à

s’améliorer de façon continue. 100Par solutions, nous entendons les outils « lean » présentés dans le tableau (11) et les plans d’actions qui ont

fait l’objet d’un accord entre l’équipe « lean » et le Codir.


149

la section suivante, à la présentation des éléments contextuels à partir desquels les acteurs ont

construit le sens des opportunités à saisir, des difficultés à éviter et des actions à mettre en

place.

Tableau 24 : PDCA mobilisé par l’équipe « lean »

Dysfonctio

nnement

Énoncé claire du

problème à traiter

Quantifica

tion des

problèmes

Causes du

problème

Action

valorisée Porteur

Contrib

uteur

Échéa

nce

1

Beaucoup de RFC101

demandées par les 3P sont étudiées

inutilement entre T-1

et T1 car lors de l'estimation des coûts par les développeurs

il apparaît qu'elles ne sont pas prises en

compte dans le planning

Peut aller jusqu'à

50%

d'études. 17 RFC

demandées

au T-1 pour 3 retenues

pour le

projet ZNE

Accepter trop d'études, Impacts sous

estimés en pré-étude,

fournisseur

trop cher, solution

inadaptée ou

indisponible

Avoir

l’ensemble des RFC

candidates

au « scope »

traduit sous

forme de RFC avant

le T-1

GA SD, DF,

ET. 01/10

2

On prononce le T0

voire le T1 alors que la proposition de solution n'est pas

finalisée.

Impact coût

qualité délais : par exemple la

conception doit être revue en

cours de développe

ment

la phase d'étude n'est

pas finalisée. Document proposition

de solution incomplet

Nommer le Cdp pour

soutenir l'architecte leader au

T-1.

GA SD, DF,

ET. 02/10

2. Facteurs d’influence de la démarche « lean »

2.1 La taille et la distribution des équipes

Lors des discussions des acteurs, la taille des équipes a souvent été abordée comme une

difficulté majeure entravant l’esprit « agile » encouragé par la démarche. Si les managers

d’équipes de taille réduite (les équipes de développement par exemple) considèrent les

pratiques « agiles » tels que le développement itératif, les réunions quotidiennes, les échanges

réguliers, etc. comme un moyen permettant d’améliorer la cohésion de celles-ci et la

satisfaction des parties prenantes du projet, les managers de projets de grande taille semblent,

eux, être plus sceptiques quant à l’application de ces pratiques de collaboration.

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


150

« Je suis positive par rapport à la démarche mais je pense qu’elle est peut être non déclinable

avec un volume d’équipe aussi grand » (DN) ; « Je suis juste sceptique par rapport à la taille

de l’équipe » (DN) ;

« J’aime bien que tout le monde ait une vision globale du projet mais ça va prendre beaucoup

de temps en essayant de réunir toutes les personnes concernées » (CR).

Comme le montrent nos observations, plus une équipe s’agrandit plus il lui devient difficile

de communiquer en direct, d’avoir une collaboration étroite entre ses membres et de

promouvoir le partage de connaissances tacites. L’accroissement de la taille d’une équipe est

habituellement accompagné d’une formalisation des procédures et d’un système de gestion

rigoureux s’éloignant des spécificités organisationnelles propres à une équipe « agile » :

processus longs de prise de décisions, multiplicité des canaux hiérarchiques, etc.

« Il y a de nombreuses instances le long d’un projet, la chaîne de décision est complexe…Par

exemple on a un grand nombre d’interlocuteurs du côté du marketing … il est important

d’avoir un décideur » (CM).

La géodistribution des équipes constitue un autre facteur sur lequel les acteurs se sont attardés

lors de la mise en place des outils « agiles ». Face à des équipes de grande taille et

géodistribuées (40 personnes en moyenne), les membres de l’équipe « lean » ont longuement

négocié les propositions à soumettre aux chefs de projets. Leur but est d’alléger la tâche au

chef de projet en lui mettant à disposition des outils préconstruits facilement adaptables et

applicables à son contexte. A ce titre, les acteurs « lean » se sont attachés à définir la

« bonne » fréquence des réunions de type « daily-scrum », leur contenu, le nombre des

participants, les outils de partage à mettre en place, etc.

« Ma première préoccupation est de voir les chefs de projet avec une proposition construite

sur laquelle ils peuvent réagir » (TR) ; « Il faut quand même avoir assez d’éléments concrets

et précis pour lui montrer comment ça pourrait être mis en œuvre, avec tel contenu, telles

méthodes » (TR) ;

« L’objectif d’aujourd’hui est donc de voir quels seront les acteurs concernés par le brief,

quelle est la bonne fréquence, quels sont les indicateurs, etc. … et donc ne pas arriver avec

une feuille blanche en lui disant débrouille toi avec ces pratiques » (TR).

Les activités discursives prolongées des acteurs « lean » mettent en exergue les difficultés de

déploiement, sur des équipes éclatées géographiquement, des pratiques de collaboration

nécessitant généralement un cadre structuré, une communication permanente et des feedback

continus. Les réunions quotidiennes de quinze minutes, par exemple, semblent inappropriées


151

pour des équipes de grande taille sauf si leur durée se voit prolongée. Mais dans ce cas, ces

réunions dévieront de leur visée initiale et s’éloigneront des principes qu’elles 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 génère une perte de

temps.

« Comment pourrait-on mettre un brief périodique pour ne pas dire quotidien sur les projets

pilotes sachant qu’on est dispersé géographiquement ? » (TR) ;

« Si on se dit que tous les jours on se réunit 15 minutes pour préparer les actions à venir,

quand on est ensemble sur un même lieu, c’est facile, mais quand on est reparti entre

Blagnac, Chatillon c’est déjà différent » (TR) ;

« La délocalisation géographique ne facilite pas le suivi de la performance… C’est déjà

différent dans la mise en place du brief quotidien, on est obligé d’utiliser le téléphone, la

Coop’Net102, et donc ça conduit à un biais… C’est tellement plus facile quand on est au même

endroit, quand le chef de projet, la direction de projet et technique qui travaille ensemble

dans un même endroit » (CR) ;

« L’éclatement des équipes sur des périmètres différents génère de l’entropie et un maximum

d’interactions qui ne sont pas efficaces et beaucoup de perte de temps » (CM).

Dans ces conditions, l’équipe « lean » a décidé conjointement avec les chefs de projets de

mettre en place des réunions plus ou moins régulières en limitant le nombre de participants. A

ce titre, seuls les acteurs impliqués dans la phase sur laquelle se situe le projet seront conviés

à ces réunions. Certes, cette solution permet au chef de projet de réunir les personnes

concernées directement par une phase donnée d’un projet, néanmoins elle ne répond pas à la

visée essentielle des réunions de type « daily-scrum » et « stand-up meeting » où les membres

de l’équipe entière se réunissent quotidiennement pour partager leurs expériences passées,

répondre aux problèmes rencontrés et décider collectivement du travail futur à réaliser. Par

conséquent, elle ne constitue pas un moyen permettant de rendre des comptes réguliers à

l’ensemble de l’équipe. Le manque de vision globale remontée par les acteurs pilotes, ne peut

être pallié par une participation de « bouts d’équipes » à des réunions régulières.

Selon les acteurs observés, la multiplicité des intervenants et leur géodistribution compliquent

l’animation en direct et les échanges entre les différentes personnes. Dans de telles

circonstances, les pratiques « agiles » risquent de perdre leur flexibilité et leur faible coût.

102Coop’Net est le nom de la solution utilisée par les salariés du Groupe Orange pour leurs réunions à distance.

Elle permet de montrer et de partager, à distance, des applications informatiques ou bureautiques, voir tout le

bureau Windows.


152

« Je vois mal comment on peut ne pas réduire le cercle des participants si on veut faire en

quinze minutes et si on veut vraiment se focaliser sur les éléments dérangeants » (DT) ;

« Si demain on doit gérer en direct ou qu’on doit animer l’ensemble des interlocuteurs du

second niveau c’est ingérable… » (PB) ;

« C’est un gros problème pour nous organiser plus facilement sachant qu’on est reparti »

(CR).

Ces observations et analyses nous conduisent à mettre l’accent sur la complexité

d’adaptabilité de ces outils collaboratifs et leur acceptation dans un environnement caractérisé

par des équipes larges, géodistribuées. Bien qu’aujourd’hui médiatée par de nombreuses

technologies d’information et de communication de qualité, la communication à distance

remplace difficilement la communication spontanée et directe entre des individus travaillant

dans un même espace physique. La dispersion géographique a par conséquent une incidence

sur le plan organisationnel et technique : trouver un horaire convenable pour tous, s’assurer

que tout le monde est bien connecté, disposer de services de télécommunication qui

permettent la transmission des images, des données et de la voix sur de longues distances.

Par ailleurs, les acteurs « lean » ont tout de même tenté d’implémenter ces réunions sur un

cercle restreint d’acteurs distribués géographiquement. Celles-ci étaient réalisées par

téléphone et à travers la Coop’Net. D’une manière générale, ces réunions ont connu une faible

participation qui peut être à priori expliquée, à première vue, par l’indisponibilité des

personnes et leur engagement auprès d’autres projets. Cela dit, les acteurs ayant réussi à

maintenir leur participation ont été amenés, à plusieurs reprises, à se connecter depuis leur

téléphone portable et pendant leurs transports, pour échanger sur leurs activités et sur les

problèmes rencontrés. Dans de telles circonstances, l’efficacité des réunions quotidiennes

réalisées peut facilement être remise en question dans la mesure où l’environnement

informatif visé par celle-ci perd de sa valeur.

Certains experts en développement « agile » (Herbsleb & Grinter, 1999 ; Sutherland, Blount

& Puntikov, 2007 ; Paasivaara Durasiewicz & Lassenius, 2008) préconisent la décomposition

du projet en différents modules indépendants où chacun est pris en charge par un nombre

restreint d’acteurs autonomes, capables de communiquer de façon fréquente et de prendre des

décisions. En ce sens, le regroupement des acteurs par module leur permet de communiquer

en direct et de réduire les activités de documentation très coûteuses ainsi que les temps


153

d’attente des décisions et d’informations. Il serait possiblement intéressant de mettre en œuvre

une telle décomposition au sein d’équipes impliquées dans une même activité, en l’occurrence

la programmation. Or, lorsque différentes équipes métiers sont concernées par le projet et

chacune, possède un mode de fonctionnement propre et est engagée dans plusieurs projets

simultanément, la décomposition du projet en différents modules indépendants devient

difficilement envisageable puisqu’elle exige une restructuration organisationnelle et de gros

investissements en termes de temps et de moyens.

2.2 La structure organisationnelle

L’implémentation des pratiques « agiles » n’est pas la même s’il s’agit d’une structure

organisationnelle « adhocratique » ou s’il s’agit d’une structure « complexe » et « rigide ».

Une structure de type « adhocratique »constitue un cadre idéal pour les équipes « agiles » car

elle favorise la communication informelle, la flexibilité et la réactivité. Cependant, le cas qui

nous intéresse se caractérise 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 dépourvu d’influence forte. Ce dernier collabore avec différents acteurs (acteurs

projets, acteurs transverses provisoires, sous-traitants, etc.) et ne dispose pas d’autorité

hiérarchique sur les personnes qu’il gère.

En effet, la structure organisationnelle de l’entité étudiée, affecte les formes d’accords et les

actions entreprises par rapport à la démarche. Les acteurs « lean » ont largement misé sur la

flexibilité des outils « agiles » retenus en vue de les adapter aux contextes des projets.

Revenons sur l’exemple des réunions quotidiennes. Ces dernières ont été détournées de la

manière dont elles sont définies par leurs auteurs (Schwaber, 2004 ; Beck, 2004) et ont été

remplacées par des réunions de fréquence variable (deux à trois fois par semaine) s’éloignant

ainsi de leur finalité principale.

« L’idée du brief quotidien c’est un petit quart d’heure, où le chef de projet connait le boulot

de chacun au jour le jour…. c’est ce qu’on dit dans les méthodes « agiles » mais après est ce

que dans la réalité 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 qu’il suffit au chef de projet d’insister auprès des différents

responsables métiers afin que leurs collaborateurs respectifs participent aux réunions

quotidiennes qu’il pilote. Bien que l’intervention de ces responsables soit une condition


154

nécessaire pour l’implication des acteurs métiers dans ce type de réunions, celle-ci demeure

insuffisante. Dans le cadre de la structure des projets à Nextv, les acteurs métiers sont

sollicités par différents projets. En ce sens, ils peuvent être amenés à participer à plusieurs

réunions en parallèle. Ainsi l’animation de réunions quotidiennes avec l’ensemble de l’équipe

devient difficile à envisager.

« En tant que chef de projet, on n'a pas de gestion d'équipe. On gère notre équipe sur un

projet mais il n’y 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 gérés par d'autres chefs….c’est compliqué car on va

demander des tâches à des personnes dont on n’est pas le chef » (CR) ;

« Les personnes qui sont partagées sur plusieurs projets peuvent être sollicitées sur plusieurs

briefs » (DT).

La capitalisation sur les connaissances et le suivi régulier des activités des équipes projets ne

sont également pas garanties car d’une part, les équipes impliquées dans un projet sont

instables et d’une autre, chacune de ces équipes est rattachée à un responsable fonctionnel

différent et bénéficie d’un mode de fonctionnement qui lui est propre : différents indicateurs

de performance, modes de communication et de collaboration intra-équipe, modes de

planification, etc.

« C’est difficile de mettre en œuvre le partage de connaissance car chaque personne gère son

propre planning. Le chef de projet est un chef d’orchestre, il ne maîtrise pas les activités des

contributeurs qui ont leurs contraintes et priorités » (TR) ;

« Le problème est un problème de mettre autour de la table des personnes qui n’y viennent

pas…il y a des acteurs avec qui le chef de projet n’a pas trop de visibilité ni de rigueur »

(RB).

Comment l’ont fait remarqué les acteurs concernés par ce travail de recherche, l’instabilité

des équipes et l’autorité hiérarchique limitée du chef de projet ont ainsi compliqué la mise en

mise en place des outils « agiles » proposés. Les changements d’acteurs en cours de projets

requièrent des efforts supplémentaires en termes de renforcement de la cohésion des équipes

et de communication entre les membres de celles-ci. De plus, l’intervention ponctuelle des

acteurs engendre une perte d’informations et de connaissances empêchant par conséquent la

capitalisation sur les projets menés. Cela nous conduit à repenser l’agilité et son adaptabilité à

différents types de contexte. Non seulement les pratiques « agiles » nécessitent des équipes de


155

taille réduite, colocalisées où les individus coordonnent leur travail en communiquant de

façon informelle les uns avec les autres, mais leur mise en place requiert des équipes stables,

travaillant ensemble et engagées dans un projet maximum, voire deux. Or, à l’aune des

organisations par projets, la constitution d’équipes permanentes est assez rare. Les acteurs

sont amenés, systématiquement, à apprendre à travailler et à collaborer ensemble. Dans un tel

contexte, l’esprit d’équipe qui qualifie les équipes « agiles » est difficile à cultiver.

« Il y a un mouvement dans l’équipe, les personnes concernées par le brief ne seraient pas les

mêmes… les architectes ne sont pas les mêmes quand on est dans l’étude ou dans la

production…. En plus il y a des gens qui arrivent en cours de route… je ne maîtrise pas les

activités des contributeurs… il y a vraiment une perte d’informations liée au départ des

personnes au cours du projet » (CR) ;

« Il y a des équipes qui sous-traitent avec l’extérieur et donc on n’a pas de visibilité là-

dessus » (CR).

En effet, les caractéristiques de la structure organisationnelle ont fait l’objet de diverses

discussions entre les membres de l’équipe « lean ». Elles se présentent comme des contraintes

affectant la manière dont la démarche est conduite. L’organisation étudiée repose sur une

structure « complexe » qui rend difficile la transposition des pratiques managériales portées

par le courant « agile ». Prenons l’exemple du suivi régulier de la performance. En effet, les

équipes projets semblent manquer d’indicateurs de gestion leur permettant d’avoir une vision

dynamique de la performance du projet. Chacune des équipes avec qui collabore le chef de

projet dispose d’indicateurs qui lui sont propres. La granularité des indicateurs varie en

fonction des phases du projet : l’équipe de développement, utilisant la méthode « scrum »,

dispose d’indicateurs quantitatifs permettant de mesurer le travail au quotidien, l’équipe de

qualification communique au chef de projet, de façon hebdomadaire, son avancement en

termes de pourcentage par rapport aux échéances. En ce qui concerne les architectes, ils ne

disposent pas d’indicateurs quantitatifs, ils communiquent leur avancement de façon très

« macro ».

« La difficulté qu’on a au niveau de notre cycle de vie c’est bien de pouvoir mesurer notre

productivité aux différentes étapes de celui-ci… L’aspect de la performance au quotidien

n’est pas tout à fait une culture que nous avons, on a donc une évaluation globale sur

l’ensemble de nos activités » (TR).


156

Dans une structure de type « adhocratique », la proximité entre les individus permet d’avoir

des clarifications rapides sur l’avancement des tâches et d’assurer leur contrôle en temps réel.

En revanche, dans une structure « complexe » où les acteurs sont attachés hiérarchiquement à

différentes unités fonctionnelles, l’évaluation de la performance est plus difficile à réaliser sur

le court terme. Il n’est pas évident pour le chef de projet d’exiger un compte rendu quotidien

sur les activités des acteurs métiers qu’il coordonne dans la mesure où il ne dispose que d’une

faible autorité hiérarchique « c’est compliqué car on va demander des tâches à des personnes

dont on n’est pas le chef... » (CR).

Outre la structure organisationnelle, le système de management de projets existant semble

avoir également affecté l’orientation de la démarche.

2.3 Mode de management de projet

Dans l’entité Nextv, les projets sont généralement menés selon un mode séquentiel

s’appuyant sur une séparation des expertises entre les différents métiers et valorisant la

planification et la documentation exhaustives. Ces pratiques managériales, propres à l’entité,

constituent une variable de création de sens pour l’équipe « lean ». Nous tenterons, dès lors,

de comprendre leur influence sur la manière dont la démarche a été appréhendée.

Le temps consacré à l’anticipation des demandes et à la planification détaillée 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 difficultés.

Dans l’entité Nextv, le style de management des équipes se transforme au fur et à mesure de

l’avancement du projet. Un chef de projet n’organise pas de la même manière une phase de

conception et une phase de qualification durant laquelle il sera en contact permanent avec son

équipe. Habituellement, des réunions hebdomadaires de longue durée sont menées séparément

et successivement avec chacune des entités impliquées dans la réalisation du projet. Suite à

ces réunions, un ensemble de compte-rendu est élaboré et diffusé au sein de l’organisation.

L’idée de mettre en place des réunions quotidiennes de courte durée a cependant été mal

accueillie. Ces réunions étaient perçues comme une charge supplémentaire à gérer, bien que

leur objet diffère largement des réunions de revues hebdomadaires. La difficulté de motiver


157

les acteurs projets à assister à des réunions supplémentaires et d’intercaler celles-ci aux

réunions déjà existantes ont été les principaux arguments avancés par les chefs de projet.

« Aujourd’hui on termine à 19 heures, il faut voir la réaction des gens pour rajouter encore

une autre réunion… » (ER) ;

« Si je vais encore faire ces daily briefs, je vais passer mon temps à faire des réunions… Les

responsables transverses sont très sollicités et donc ils sont surchargés » (CR) ;

« Un des problèmes c’est qu’on a beaucoup de réunions et je ne pense pas que ça serait bien

des réunions qui se doublonnent… Les gens se plaignent car les réunions sont très longues,

ça dure 4 heures... » (DT).

Sur la base des arguments avancés par les acteurs pilotes, il a été décidé d’adapter les outils de

collaboration et de coordination en fonction du contexte de chaque projet. La fréquence de ces

réunions a été rajustée selon la phase du projet. Comme nous l’avons déjà précisé, ces

réunions peuvent être quotidiennes ou réduites à une fréquence de deux à trois fois par

semaine selon les besoins du chef de projet. Comment savoir à l’avance quelle(s) phase(s) du

projet nécessite(nt) un partage régulier d’informations alors que les projets informatiques

relèvent de nombreuses incertitudes ? Ce constat nous amène à remettre en question les

critères sur lesquels les acteurs « lean » se sont basés pour déterminer la fréquence de ces

briefs et à nous intéresser aux raisons qui justifient leurs choix.

La complexité de la structure organisationnelle et les caractéristiques des projets ne

constituent pas les seuls facteurs ayant conduit les acteurs « lean » à réduire la fréquence des

réunions et à limiter le nombre des participants. Le manque d’intérêt des chefs de projet à

l’égard de ces nouveaux outils et leur « encombrement » ont également eu un impact sur les

choix d’actions entreprises par les acteurs « lean ».

« Pour les briefs ça va dépendre du contexte et du moment du projet. Peut être en phase

d’étude il n’y a pas matière à faire des briefs tous les jours, ou en phase de conception c’est

différent, Donc on n’adaptera en fonction du moment, du contexte et des enjeux » (TR) ;

« On fait le brief qu’avec les personnes qui sont sur le chemin critique... pour moi le point

important c’est les acteurs actifs…. dans la littérature, on dit qu’au 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é valorisée par les équipes

de Nextv et un facteur additionnel de création de sens de la démarche. Comme nous l’avons


158

constaté dans la première section de ce chapitre, le mode de communication formelle génère

beaucoup de gaspillages : temps de rédaction et de lecture des documents, documents

obsolètes, etc. De plus, la documentation produite est rarement conforme aux attentes des

acteurs projets : documents incomplets, documents livrés 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 opérationnels, les architectes. Ils se

trouvent sur Roll et sont envoyés 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 n’a pas de spécifications détaillées qui consolident le tout… on a un vrai problème de

déficit 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 t’es vraiment

paumé…» (LM).

Du point de vue des partisans des méthodes « agiles », la documentation doit être réduite aux

maximum et être remplacée par des livrables concrets matérialisant les différentes phases du

projet : design, conception, développement, tests, etc. (« working software over

comprehensive documentation », Agile Manifesto). Pour cette raison, l’équipe « lean » a

décidé de mettre en œuvre un plan d’action qui vise à réduire la quantité de la documentation

produite. Conscients des coûts engendrés par la documentation, les acteurs projets ne sont pas

prêts à abandonner ce type de pratiques « Laurence (chef de projet) considère que tous les

documents qu'elle a eu sont indispensables pour son projet » (JP). Cette attitude peut

s’expliquer par la culture organisationnelle qui est une culture de non prise de risque

valorisant les processus et procédures très formels : les prises de décisions nécessitant

l’accord de diverses instances hiérarchiques, le besoin de traçabilité des actions entreprises

conduisant à une documentation extensive « tout le monde prend trop de précaution ce qui

rend toutes les actions très longues » (GC). Dans cette optique, la documentation constitue

une sorte d’assurance pour les acteurs même si, très souvent, elle s’avère inutile. Dans de tels

environnements, les pratiques « agiles » encourageant la communication orale au dépend de la

documentation écrite sont rarement appréciées.

Le mode de fonctionnement séquentiel adopté par l’entité Nextv semble avoir influencé

implicitement l’orientation de la démarche. Le cycle de vie séquentiel des projets freine la

mise en œuvre de pratiques « agiles » qui elles, mettent en avant la flexibilité et l’adaptation

aux changements. Prenons l’exemple du développement itératif. En développement


159

informatique, il paraît impensable de contourner les changements qui arrivent en cours du

projet. Les équipes sont invitées à s’adapter aux demandes évolutives du marché et à intégrer

continuellement les retours sur les solutions développées. La proximité entre les members

d’une é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 durée et sont menés de façon séquentielle, les processus et les outils

formels seront privilégiés car ils permettent d’assurer un meilleur contrôle des risques. Dans

un tel contexte, la mise en place d’un système de développement itératif nécessite un

changement radical du mode de fonctionnement des équipes qui, en raison de sa complexité,

n’a pas été envisagé par les acteurs « lean ».

« Normalement, au début d'un projet t'as un scope qui est défini 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 n’a pas le temps et donc je passe du temps à

défendre cela et donc je rate du temps à défendre au lieu de faire autre chose » (CR) ;

« Tous les trucs de replanification qu'on peut me redemander me fait perdre énormément de

temps » (DN).

2.4 Les ressources mobilisées

Le sens de la démarche a été largement imprégné par les retours d’expériences

d’organisations présentant un contexte similaire : équipes géodistribuées, transverses, larges

projets. Ces retours d’expérience sont, pour les acteurs « lean », une aide pour concevoir la

mise en œuvre de la démarche dans leur propre contexte organisationnel. Lors de la

construction des outils « agiles », l’équipe « lean » s’est appuyée sur des présentations

d’organisations ayant implémenté, au sein de leurs équipes, des réunions quotidiennes et un

management visuel (Annexe VI-VII). Toutefois dans ces présentations, les organisations

n’ont pas précisé comment elles ont procédé pour mettre en place ces outils . En outre, la

majorité des présentations mobilisées ont concerné des équipes colocalisées (Annexe VII).

Par conséquent, le manque d’informations et de « cadres » pour implémenter ces outils a été

perçu comme une difficulté dans la mise en place de la démarche.

De manière plus concrète, les acteurs se sont attachés d’une part, à analyser la manière dont

les réunions quotidiennes et le partage visuel de tableaux de bord et d’indicateurs se font au

niveau d’équipes géodistribuées et d’une autre, à reporter les effets d’usage de tels outils. Les


160

supports de présentations ainsi mobilisés ont pour objectif de répondre à deux facteurs

problématiques identifiés par l’équipe « lean » : la géodistribution et la transversalité des

équipes.

« Sur la problématique de la dispersion géographique et donc du pilotage transverse, les gens

d’OS ont le même souci, et ils ont quand même mis en place une modalité d’animation de

brief, un management visuel et un suivi de performance … Nous avons aussi eu des retours

d’expériences de personnes travaillant précédemment chez ML… On utilise les retours

d’expériences, pour illustrer les formations» (TR);

« Je pensais demander à OS sur la manière dont ils procèdent pour organiser et animer les

briefs…. c’est comme notre contexte. Il n’est pas question d’avoir des gens qui se déplacent

car ils sont dans les 4 coins du monde » (RB) ;

«On peut s’appuyer sur le support qu’utilise la société TL dans leur brief.... Dans la pièce

jointe, ils présentent plus en détails comment ils mettent en place le brief -l’objectif est donc

de regarder ce qu’ils font et d’en tirer les meilleures pratiques… (RB) ;

« Je connais quelqu’un qui travaille à la SG et il m’a dit qu’ils ont eu des résultats

formidables, on pourra faire un point avec lui pour avoir quelques éléments explicatifs de

qu’est ce que ça change et donc profiter des retours d’expérience avant de procéder… »

(RB).

Si ces supports ont permis à l’équipe « lean » de mieux comprendre et communiquer la visée

des outils collaboratifs retenus (contenu des réunions quotidiennes, différenciation d’une

réunion quotidienne par rapport à une réunion d’équipes, rôle du chef de projet dans ces

réunions, exemple de tableau blanc et d’indicateurs de performance partagés, etc.), ils

n’illustrent pas, toutefois, la manière dont ces outils sont concrètement déployés au niveau

d’équipes de pilotage transverses, géodistribuées. En d’autres termes les retours d’expériences

ne précisent pas, du moins explicitement, la manière dont les réunions sont organisées dans de

tels contextes, les technologies utilisées, les outils de collaboration et de coordination

complémentaires mobilisés, les défis majeurs rencontrés et la manière dont ils ont été

surmontés, etc. Les acteurs « lean » se sont alors rendus compte du manque d’exemples

concrets qui leur aurait permis de décliner ces outils dans leur propre environnement. Par

ailleurs, si ces nouvelles méthodes managériales ont déjà été appréhendées dans un

environnement global, elles ont souvent concerné les équipes de développement. Or dans le

contexte présent, les acteurs concernés par la démarche appartiennent à des équipes qui ne

sont pas impliquées dans la programmation.


161

Le manque de retours d’expérience et les connaissances limitées des acteurs par rapport à la

mise en place de ces outils pourraient justifier, d’une part, les longues heures passées en

réunion à négocier les propositions à soumettre aux équipes pilotes et d’autre part, l’idée

abstraite et théorique que se sont faites ces dernières de la démarche. Nous sommes, par

conséquent, amenés à considérer que ces supports théoriques mobilisés n’ont pas facilité la

mise en œuvre et l’acceptation des outils et pratiques « agiles ». Les équipes pilotes ne

voyaient guère d’intérêt dans la manière dont la démarche a été proposée. L’équipe « lean »

manquait d’éléments concrets pour envisager l’adaptation de la démarche au contexte des

projets pilotés par l’entité Nextv.

« On dit qu’on va changer un état d’esprit, un mode de fonctionnement, un système de

management, etc. mais il faudrait qu’on puisse donner quelques cas d’illustration » (TR) ;

« J’ai été au rendez vous d’information lean mais je n’ai pas retiré grand-chose… Je trouve

c’est très conceptuel. Il faut adapter notre discours en étant plus dans les exemples » (OD) ;

« Il faut certainement présenter des exemples de réussite et des cas concrets de la démarche »

(FB) ;

« On a du mal à comprendre le bien fondé de la démarche » (PM) ;

« Le kaizen est trop abstrait, il faut s’adresser de façon plus opérationnelle aux équipes »

(JMW) ;

« A priori on n’a pas trouvé des expériences sur les briefs au niveau des équipes qui ne sont

pas hiérarchiques….. Aujourd’hui on est encore en manque de retours d’expériences et de

boites à outils, il serait important de faire appel à la créativité de chacun » (TR).

Il apparait donc utile qu’une organisation, souhaitant emprunter la voie de l’agilité, dispose

d’exemples précis et détaillés sur l’applicabilité des pratiques et outils portés par ce courant

managérial émergent. Ceci est d’autant plus vrai lorsqu’il s’agit d’une organisation

« complexe » caractérisée par une structure matricielle et des équipes métiers transverses

distribuées géographiquement. Néanmoins, à l’heure actuelle, la majorité des études de cas

réalisées ont porté sur des équipes de taille réduite impliquées dans des projets de courte

durée, contrairement au contexte présent.

Il convient ici de rappeler que même si les organisations présentent des caractéristiques

contextuelles communes, elles ne réagissent pas toutes de la même façon. Comme nous

l’avons précédemment indiqué, les individus agissent sur leur environnement en fonction des

interprétations et des significations qu’ils attribuent à celui-ci. Plusieurs facteurs contextuels

peuvent ainsi rentrer en jeu, influencer le sens créé et par conséquent les actions menées. Dans


162

cette perspective, un système managérial adopté par une organisation ne peut pas être

simplement copié et appliqué de la même manière dans une autre. Les individus vont

s’appuyer sur des variables de l’environnement qu’ils perçoivent mais qui peuvent aussi le

dépasser. Le sens des pratiques et principes managériaux diffèrent et évoluent en fonction des

situations. Il est donc important de prendre en compte ce qu’ils représentent dans leur propre

contexte. Ce cas de figure nous fait penser à l’exemple donné par les Poppendieck (2006) sur

les entreprises ayant tenté, dans les années 1990, de copier le système « kanban » chez

Toyota. Les résultats médiocres affichés par ces entreprises s’expliquent par le fait que celles-

ci n’avaient pas perçu le « lean » comme un système de management dont l’objectif principal

vise à éliminer le gaspillage ou qu’elles sont passées à côté du principe central de cette

approche : le respect des personnes.

2.5 Les parties prenantes du projet « lean »

Bien que le rôle qu’occupent les parties prenantes est inhérent à la mise en place de la

démarche, l’équipe « lean » s’est principalement focalisée sur trois acteurs métiers (chefs de

projets, architectes, CPM) et en particulier les chefs de projets avec lesquels ils ont mené

divers entretiens et réunions : « Pour que ça marche il faut que le chef de projet soit

convaincu que la démarche va bien l’aider pour que lui derrière réussisse à convaincre ses

interlocuteurs… » (RB). Peu d’attention a dès lors été accordée aux autres parties prenantes :

les acteurs opérationnels, le marketing, les métiers transverses, etc. Ce choix peu t s’expliquer

par le fait que l’équipe était contrainte par le temps, que son autorité assez limitée lui

empêchait de mobiliser le reste des entités ou simplement, qu’elle préférait emprunter la

« voie » qui, selon elle, paraissait la moins complexe pour aborder la mise en place de la

démarche. Ce cas de figure nous renvoie à la notion de plausibilité qui semble être au cœur de

la démarche « lean ».

Si la phase pilote de la démarche n’a concerné que quelques acteurs métiers c’est aussi parce

qu’elle n’a pas été considérablement consolidée par la hiérarchie, représentée ici par l’équipe

« N-1 » ou le top management. Les enjeux soulevés par la direction générale, lors du

séminaire organisé avec les équipes projets de l’entité, étaient insuffisants pour mobiliser ces

dernières et les inciter à s’engager dans la démarche. Malgré le soutien de la direction

générale, les acteurs « lean » se sont ainsi retrouvés noyés dans la définition et la mise en

œuvre de ces nouvelles approches managériales.


163

« Dans notre situation, le support on l’a toujours eu dès le départ, de JM (directeur général)

et là il n’a jamais fait de défaut….par contre au niveau intermédiaire, les N-1 de JM

(directeur général), la situation était plus mitigée » (TR) ;

« Il y a un besoin d’implication du top management, à part le directeur Général qui est très

sponsor sur le sujet, je n’ai pas l’impression que les autres membres du top management

soient autant impliqués… la direction a un rôle fondamental à jouer pour mobiliser les

gens…» (RB) ;

« Passer un message au Codir qu’il doit être exemplaire dans cette démarche d’amélioration,

de les mobiliser, ils sont quand même un peu spectateur quoi » (RB).

Outre le pouvoir légitime du top management et sa capacité à influencer le déploiement des

outils et pratiques « agiles », les managers d’équipes (chefs de projet, directeurs de projets)

occupent également une place centrale au sein de la démarche, dans le sens où ils sont

capables de renforcer l’image de cette dernière auprès des acteurs qu’ils gèrent et augmenter,

par conséquent, son taux d’acceptabilité.

« Peut être qu’il y a une autre manière de procéder, je pense qu’on n’a pas assez travaillé

avec les managers……Nous sommes revenus sur ce sujet, et donc plus largement comment les

managers s’impliqueront progressivement dans la conduite des ateliers ? » (TR) ;

« Les managers doivent montrer de l’intérêt au travail qui a été fait…LR est déçue et s’est

refroidie après les réunions » (JP).

La faible implication des managers a compliqué l’adoption et la mise en œuvre de la

démarche. La démotivation des managers est dès lors considérée comme une contrainte

affectant l’implémentation du projet.

« Il y a un manque de volonté managériale pour lancer les groupes de travail… Plusieurs

managers n’ont pas participé » (PB) ;

« La démarche est peu utilisée ici et donc je me sens un peu seul » (GC) ;

« La démarche de changement il faut déjà la travailler avec les managers » (TR).

L’efficacité de la démarche dépend également de l’implication de acteurs d’autres services

fonctionnels : les métiers transverses (développement, qualification, architecture, etc.), le

marketing, le R&D, etc. Dans cette perspective, la centralisation de la démarche sur les

métiers de l’entité n’a pas favorisé les gains potentiels liés aux outils utilisés (réunions

quotidiennes, analyse des dysfonctionnements, QQCQOP, tableau blanc) et encore moins

l’organisation lean visée par la direction. Cette constatation a été soulevée par différents

acteurs pilotes qui ont mis l’accent sur les limites d’appliquer les pratiques et outils « agiles »


164

sur un périmètre restreint où seuls quelques métiers de l’entité Nextv sont inclus « Pourquoi

ne pas impliquer dans la démarche plus d’ingénieurs qualité car j’ai l’impression que

plusieurs choses se recoupent… » (CM) ; « Il serait pas mal de refaire une séance de

recherche de problèmes mais avec plusieurs services » (PLP). Les acteurs transverses

occupent un rôle primordial au sein des projets pilotés par celle-ci. En effet, rares sont les

problèmes qui peuvent être résolus en interne sans l’implication des métiers transverses. En ce

sens, les directions de marketing, de développement, de qualification, de maintenance, etc.

doivent également faire partie de la démarche et des plans d’actions. Prenons l’exemple de

l’amélioration de la satisfaction du client. En général, le client est satisfait si le produit livré

est conforme à ses besoins, très souvent évolutifs. De ce fait, une équipe de pilotage de projet

qui va mettre en place des réunions régulières avec ses équipes, sans toutefois impliquer le

marketing, aura du mal à répondre à ses demandes évolutives. D’ailleurs, les personnes

impliquées dans la phase pilote ont évoqué le besoin ultime de faire participer le marketing à

la démarche et cela parce que la majorité des difficultés auxquels elles sont confrontées

relèvent de leurs rapports avec celui-ci et du faible intérêt qu’il leur accorde.

« Je me posais la question si on pouvait mettre les outils à un périmètre plus large et

impliquer d’autres acteurs… notre problème est d’échanger souvent avec le marketing…»

(PC) ;

« Je pense qu’il manque des acteurs aujourd’hui comme le marketing à impliquer dans le

projet … A FT je veux bien mais bon je pense qu’il manque des acteurs…. » (LM) ;

« Nous on va travailler dans le sens d’amélioration de réduction de gaspillage, mais est-ce

que ce travail se fait aussi d’une autre manière mais parallèlement du côté du marketing…. »

(Participant au rendez-vous d’information).

Ce n’est qu’au fur et à mesure de l’avancement du projet, que les membres de l’équipe

« lean » se sont rendus compte de l’importance de certaines parties prenantes dans la mise en

œuvre de la démarche. Partant d’une logique conduite par la plausibilité, ils se sont accordés à

se focaliser davantage sur les directeurs de projets rattachés à l’entité Nextv afin de les

intégrer dans la phase de généralisation du projet. Or ces derniers ne montrèrent guère

d’enthousiasme. Différents facteurs peuvent expliquer ce manque d’intérêt éprouvé : la

lassitude du changement, la surcharge de travail et le changement de posture managériale

qu’exige cette nouvelle approche de management.

Aujourd’hui, les directeurs de projets affichent une certaine réticence quant à la multiplicité

des programmes de changement organisationnel. L’incertitude liée aux avantages de la


165

démarche « lean » proposée, peut expliquer la démotivation de ces acteurs et leur manque

d’implication. Il apparaît qu’une lassitude par rapport aux plans d’amélioration s’est

progressivement instaurée au sein de l’entité. Une lassitude qui s’est traduite par un faible

engagement des managers dans les plans d’actions portés par la démarche.

« Globalement il est difficile de mobiliser les acteurs sur la nième tentative d’amélioration

des processus » (GC) ;

« Il faut voir qu’on est dans le changement permanent à FT donc du coup, moi le premier, on

est parfois dubitatif…. Au bout d’un moment, la lassitude qui s’instaure, on dit voilà les

nouveaux méthodes, les outils j’en ai vu, et j’en verrai d’autres, ce que vous dites m’intéresse

mais j’ai du boulot… » (TR).

La surcharge de travail, quant à elle, constitue une autre raison pour expliquer le manque

d’intérêt des directeurs de projets. Tout d’abord, le temps que nécessitent les formations et les

périodes d’appropriation des pratiques et outils « agiles » n’encourage pas les managers à

faire partie de la démarche « lean ». Ces derniers doivent faire preuve de rigueur et de soutien

continu auprès de leurs équipes alors qu’ils sont surchargés et pris par leur travail habituel.

Prenons le cas des réunions quotidiennes et des ateliers kaizen : les réunions imposent au

manager d’avoir une certaine discipline pour rassembler, au quotidien, les membres de son

équipe et maintenir une cadence régulière dans le suivi et le contrôle des projets. Quant aux

ateliers kaizen, ils exigent un comportement rigoureux d’écoute et une présence régulière du

manager sur le terrain, difficile à réaliser lorsque plusieurs projets et équipes sont pilotés en

parallèle. Les efforts induits par la mise en place de ces outils, la complexité des projets

existants et le manque de temps peuvent, dès lors, expliquer ce faible enthousiasme à l’égard

de la démarche.

« La réalité est que le quotidien passe avant le projet lean ….. Vis-à-vis des pratiques

proposées, les acteurs ne le clament pas car ils ne veulent pas avoir tous les outils sur le dos,

ça génère une perte de temps » (ER).

Une troisième raison pour interpréter la faible participation des directeurs de projets est le

changement de posture suscité par cette nouvelle approche managériale. En effet, une

organisation « lean » suit une logique « bottom-up ». Ce système de management repose sur

les compétences des personnes qui occupent différents niveaux hiérarchiques et en particulier

celles qui se situent au niveau opérationnel « front-line ». Ces dernières constituent un

élément clé dans le cycle de vie des projets. Elles sont impliquées dans les décisions et


166

l’amélioration continue des processus et jouent un rôle véritable pour atteindre les objectifs

fixés. Dans cette logique, les responsabilités de prise de décisions et de définition des

objectifs sont réparties entre les équipes et leur manager. Ce nouveau style de management

nécessite donc un changement de mentalité des managers qui, généralement, n’ont pas

l’habitude de déléguer leurs pouvoirs et de se concerter avec leurs collaborateurs pour les

opportunités d’amélioration dans l’entreprise. Il n’est donc pas surprenant que certains

managers perçoivent ce principe de « renforcement » des équipes comme une menace à leur

statut hiérarchique et une dévalorisation du rôle qu’ils occupent au sein de l’organisation. Cet

élément peut permettre d’interpréter le faible intérêt accordé à ce style de management.

D’ailleurs, cette raison fut également « remontée » dans les discussions des acteurs « lean ».

« Dans l’animation lean + kaizen on cherche de faire en sorte que l’amélioration vienne des

équipes et ce sont les équipes qui disent sur quoi il faut travailler, sur quoi il faut s’améliorer.

Ce n’est plus le manager qui sait tout, qui intervient comme ultime sauveur….Et donc

évidemment que pour des personnes, se mettre dans cette posture là n’est pas aussi simple

d’où aussi la résistance de leur part….. » (TR).

Divers facteurs tant organisationnels, politiques qu’individuels peuvent ainsi conduire les

parties prenantes à abandonner la démarche managériale suggérée. La prise en compte des

attentes de ces dernières est un élément déterminant pour parvenir à l’implémentation de ces

nouvelles pratiques de management de projets. Toutefois certaines parties prenantes occupent

un rôle plus critique dans l’organisation et par conséquent leur participation s’avère

déterminante pour mener à bien la démarche.

Tout au long de la démarche, les acteurs « lean » ont tenté de concilier les objectifs du projet,

les caractéristiques organisationnelles et les exigences des acteurs pilotes en vue de mettre en

place des pratiques managériales cohérentes avec leur contexte.

L’analyse des pratiques discursives des acteurs et leurs interactions avec leur environnement

nous a permis de mettre en lumière les éléments d’ordre contextuel qui semblent avoir

influencé la mise en œuvre des outils « agiles ». Différents éléments ont été identifiés par les

acteurs « lean » comme déterminants dans l’implémentation des « innovations managériales »

de type « agile » : (1) la taille et la géodistribution des équipes ; (2) la structure

organisationnelle (structure de type lightweight, l’autorité limitée du chef de projet) ; (3) la

composition des équipes (acteurs métiers transverses rattachés à différents services


167

fonctionnels, prestataires externes), (4) le manque d’implication des parties prenantes

(manque de support du top management, manque d’intérêt des manageurs de projet), (5) le

manque de ressources informationnelles sur l’implémentation des outils « agiles » dans des

organisations transverses et géodistribuées ; (6) le style de management actuel (la

documentation extensive, le cycle de vie séquentiel, la planification extensive, réunions

hebdomadaires de longue durée) qui ne semble pas faciliter l’intégration des pratiques et

outils « agiles » ; (7) la non implication des acteurs transverses clés (équipes de

développement, marketing, équipes de qualification, etc.) ; (8) la faible autorité hiérarchique

de l’équipe chargée de la mise en place de la démarche d’amélioration, (9) le manque de

support du top management et (10) la lassitude des équipes quant aux programmes de

changement. Ces facteurs peuvent expliquer les difficultés entravant l’appropriation et la

« contextualisation » des outils « agiles » au sein de Nextv. Les substrats techniques associés

à ces méthodes émergentes de management de projet sont peu adaptés à des structures

organisationnelles complexes.

Dans ce chapitre, notre attention s’est focalisée sur les préoccupations des individus et les

significations qu’ils ont attribuées à leur environnement. Nous avons ainsi tenté de

comprendre et d’interpréter, du point de vue de ces acteurs, les facteurs contextuels qui

semblent avoir contraint la mise en œuvre de la démarche managériale.

Comme le montrent ces résultats, l’implémentation d’une démarche basée sur des principes

« agiles » est loin d’être facile à réaliser, en particulier, lorsqu’il s’agit d’une structure

organisationnelle complexe.

168

169

CChhaappiittrree VVII :: DDiissccuussssiioonn

En nous appuyant sur la grille d’analyse de sensemaking, nous expliquons la manière dont la

démarche « lean » a été « construite » à partir des pratiques situées 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 s’appuient les acteurs impliqués dans la « fabrication » d’une

démarche managériale « agile ».

Chapitre VI : Discussion

170

Comprendre comment une organisation, caractérisée par une structure

organisationnelle complexe, s’engage dans la mise en place d’une stratégie managériale de

type « agile » est l'un des principaux buts visés par cette thèse. La quasi inexistence d'études

consacrées à ce sujet nous a conduit à nous interroger sur ce que font les acteurs chargés de la

mise en œuvre des méthodes « agiles » en tant qu' « innovations managériales »et comment ils

font pour aboutir à des résultats stratégiques au sein de leur entreprise.

Afin de répondre à notre problématique de recherche, il nous a paru opportun de nous

rapprocher des études qui s’inscrivent dans le tournant de la « pratique » et d’aborder

l’implémentation des outils « agiles » comme « pratique ». Le phénomène d’implémentation

de la démarche « lean » a donc été appréhendée dans son contexte en articulant le niveau

« micro » (activités d’interprétation, outils mobilisés, les activités de création et de diffusion

de sens, etc.) et le niveau « macro » (structure, règles, ressources, etc.). Il a été abordé du

point de vue des acteurs qui participent à sa construction et des liens qu’ils entretiennent avec

leur environnement matériel et social.

Dans le chapitre précédent, nous nous sommes contentés de faire ressortir les éléments

d’ordre contextuel tels qu’ils ont été identifiés par les acteurs concernés par la démarche et qui

semblent avoir affecté la mise en place de celle-ci. Si ces facteurs relèvent d’un contexte

particulier (profil du chef de projet, équipes instables, manque d’outils « clés en mains »,

etc.), ils constituent des difficultés générales auxquelles peuvent être confrontées d’autres

équipes souhaitant s’engager dans la voie de l’agilité. Toutefois, les pratiques103 stratégiques

et les cadres de référence des individus différeraient d’un contexte à un autre.

103Par pratiques stratégiques nous désignons « les types routiniers de comportement qui consistent en différents

éléments interconnectés : formes d’activités physiques, formes d’activités mentales, « choses » et leur utilisation,

connaissances antérieures permettant la compréhension, savoir-faire, émotions » (Reckwitz, 2002, p.249, dans

Jarzabkowski, Balogun & Seidl, 2007).


171

Ainsi, il apparaît judicieux d’examiner de près, en s’appuyant sur la grille d’analyse du

sensemaking, les « pratiques » à partir desquelles les acteurs ont tenté, par le jeu de leurs

interactions, de « fabriquer », au sein de leur contexte, une stratégie managériale de type

« agile ».

La « fabrique » de la démarche « lean »

La mise en pratique des principes et outils « agiles » auxquels les acteurs « lean » ont été

formés fut loin d’être facile à réaliser : les acteurs ont rapidement pris conscience de l’écart

entre leurs attentes à l’égard de la démarche et la réalité du terrain. Ils ont ainsi cherché à

comprendre et à catégoriser les éléments problématiques afin de les analyser, les mettre en

perspective les uns des autres, les coordonner et les résoudre.

« Au début, en tant que bons élèves, on s’était dit qu’on va mettre en place ce qu’on a appris

dans le cours, mais les effets qu’on a eu entre nous, en échangeant, on a trouvé qu’une

grande majorité des pratiques relevant du lean et des méthodes agiles n’étaient pas possibles

sur une activité de pilotage transverse » (TR).

Le point de départ de la démarche « lean » a été l’absence « d’ordre intrinsèque » à partir

duquel les acteurs ont cherché à organiser le flux d’évènements en traitant certains « indices »

repérés dans leur contexte. La démarche a été délimitée par l’attention accordée à un

ensemble de questionnements d’ordre managérial et organisationnel. Ces questions ont permis

aux acteurs « lean » de « cadrer » leur réalité organisationnelle avant de s’engager dans

l’action.

Comment on va travailler pour identifier les dysfonctionnements ? Quelles pratiques et outils

managériaux retenir ? Comment s’adapter aux activités de pilotage de projets avec de

nombreuses contributions transverses ? Quels seront les acteurs concernés par notre

démarche? Comment les convaincre par la démarche ? Comment s’organise-t-on de telle

manière à produire des résultats tangibles d’ici trois mois ? (Acteurs « lean »).

Cette première série de questions renvoie à des situations problématiques (la contrainte du

temps, le type d’acteurs pilotes à impliquer dans la démarche et les pratiques « agiles » à

mettre en œuvre) auxquelles les membres de l’équipe « lean » ont tenté de répondre. Au fur et

à mesure de l’avancement du projet, de nouvelles interrogations ont émergé concernant

d’autres aspects de la démarche et de l’organisation :


172

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 résolution de problèmes au sein de l’équipe,

qui regroupera des personnes de sites différents ? (Acteurs « lean »).

Le profil des membres de l’équipe « lean » et leurs expériences pourraient avoir influencé la

direction de la démarche empruntée. Notons toutefois que les deux membres essentiels de

l’équipe (le responsable et le coach) ne possèdent d’expériences ni dans le développement

« agile » ni dans la mise en place de ces méthodes. Ceci peut éventuellement expliquer les

questions d’ordre basique auxquelles les acteurs ont tâché d’apporter une solution : « quels

pratiques et outils retenir, comment s’adapter au contexte, comment est utilisé le tableau

blanc ? ». Les situations problématiques telles qu’elles ont été cernées par l’équipe « lean »

auraient peut-être été différentes dans une autre équipe plus expérimentée ou spécialisée dans

ces pratiques managériales tout comme la collecte d’informations, l’interprétation et l’action.

Le recours à des experts en ces méthodes aurait pu constituer, à première vue, une aide

primordiale pour l’équipe ; et la démarche aurait ainsi certainement pris une direction

différente : élargissement du périmètre de la phase pilote (implication de plusieurs services

fonctionnels, implication de différentes entités, etc.), mise en œuvre de pratiques et/ou règles

supplémentaires (réduction du cycle de vie du projet, livraisons itératives et incrémentales,

implication du client dans le développement, 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 d’une stratégie

« agile ». Ces connaissances sont mobilisées dans les conversations formelles et informelles

des acteurs (réunions, discussion, négociations, interprétation, etc.) et dans les routines105 liées

à leur poste de gestionnaire (validation du Codir, planification, définition 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 impliqués dans la « fabrication » et la

mise en place d’une démarche managériale « agile ».

A travers leurs interactions, les acteurs communiquent leurs visions du réel pour aboutir à une

entente sur les actions à entreprendre et les comportements à adopter. L’extrait ci-dessous

nous invite à voir comment le sens de la démarche s’est construit collectivement à travers les

échanges de points de vue et d’arguments entre les membres de l’équipe « lean ».

104

Les connaissances pratiques renvoient au savoir-faire du praticien de la stratégie (Rouleau & Balogun, 2007).

Ces connaissances sont explicites et tacites. 105Les pratiques « locales » spécifiques à un groupe d’acteurs.


173

« Le fait d’avoir plusieurs profils dans notre démarche pilote on va gagner énormément, on

va collecter beaucoup d’informations » (DF), -« Si on raisonne par projet, on va remonter

beaucoup plus des difficultés sur les cycles de vie du projet, sur les interactions et donc moins

des difficultés propres à un métier en termes de concret, du quotidien d’un métier… Par

contre par métier, c’est là qu’on a un enrichissement d’une communauté métier » (TR) ; -« Si

on fait par métier on aura toutes les requêtes sur les autres métiers pour moi ça n’avancera

pas les choses et il n’y aura pas de débats » (DF) ;

« Ça serait bien d’intégrer un projet qui est en train de se mettre en place surtout qu’à la

phase de démarrage les gens rencontrent beaucoup de problèmes qu’ils pourraient nous faire

remonter » (JP) ;

« On doit réfléchir sur comment mettre en place le projet lean sur les deux axes : métiers et

projets » (RB).

Si certains acteurs ont considéré que l’implication d’équipes métiers106 pourrait être plus

bénéfique pour la démarche pilote, d’autres ont plutôt privilégié la diversité des profils

d’acteurs concernés par un même projet. Le raisonnement des membres de l’équipe « lean » a

été guidé par la nature et la variété des problèmes que peut éventuellement mettre en avant

chacune des équipes concernée par la démarche.

Ainsi, une attention particulière a été accordée par les acteurs « lean » à l’identification des

dysfonctionnements dans le déroulement des projets. L’idée de dresser l’état des lieux des

projets souligne l’intérêt qu’accordent les praticiens à la notion de gaspillage pour légitimer

leur démarche managériale. Nous reviendrons infra sur cette notion de légitimité et

l’importance qu’elle occupe dans la mise en place de la démarche.

« On travaillera ensemble sur les outils à proposer aux chefs de projet pour l’animation de

leur équipe… » (TR) ;

« Qu'est ce qui va faire que les gens soient motivés pour venir à un brief régulier où on sait

qu'on doit être ponctuel quand on sait que régulièrement à chaque réunion organisée t'as la

moitié des personnes qui arrivent avec un quart d'heure de retard ? » (TR).

La construction collective du sens de la démarche « lean » semble avoir été conduite par la

plausibilité. L’équipe par exemple a décidé d’impliquer les acteurs qu’elle estimait pouvoir

contacter : « dans tel projet, il y a du monde et on connait des personnes qu’on pourrait

contacter et faire participer à la démarche…. on va faire des ateliers projets et des ateliers

métiers qui seront globalement représentés…on va être modeste et on va se contenter de notre

106Il s’agit des groupes d’acteurs travaillant au sein d’un même métier : chefs de projets, architectes techniques,

architectes fonctionnels, développeurs, etc.


174

entité, on va s’attacher à des choses qu’on peut gérer ». A ce titre, bien qu’importantes, les

équipes transverses ont été exclues du projet. Dans un même registre, l’équipe s’est contentée

d’un nombre assez limité d’outils « agiles107 » à mettre en place. Elle s’est attachée à ce qui

était envisageable dans son contexte organisationnel en optant pour les solutions qu’elle

estimait réalisables et pouvant satisfaire ses objectifs, qui par ailleurs sont instables. Ainsi, les

accords des membres de l’équipe ont davantage porté sur les moyens dont ils disposaient.

Cette notion de plausibilité met l’accent sur un point d’une importance cruciale dans la

« fabrication » de la stratégie : l’influence du contexte au sens « macro » (propriétés

organisationnelles, ressources disponibles, règles, etc.) sur ce qui se passe au niveau « micro »

de l’organisation. Le choix des actions est effectué en fonction des aptitudes des individus et

de leurs capacités à faire évoluer ces aptitudes au sein de leur environnement, celui-ci étant

« enacté » à partir de leur compréhension des situations et de leurs choix stratégiques. Cela

dit, avant de s’engager dans l’action, les acteurs vont évaluer les solutions qu’ils estiment être

capables d’apporter compte tenu des facteurs qu’ils identifient au sein de leur contexte. Dans

cette perspective, le lien entre les niveaux « micro » et « macro » de la stratégie comme

« pratique » est mis en évidence.

« Dans les réunions quotidiennes aujourd’hui soyons réalistes, 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 c’est de vouloir trop traiter et de se noyer. Il faut essayer d’aboutir à

quelques points d’actions » (RB) ;

« On traite 8 dysfonctionnements. Les autres dysfonctionnements on les traitera plus tard. Le

choix a été fait par rapport à leur poids, à la possibilité qu’on avait pour avancer sur le

sujet » (TR).

Si la « construction » de la démarche est le fruit des interactions entre les acteurs « lean », son

orientation est également affectée par les échanges avec d’autres parties prenantes : les

équipes pilotes, la direction générale, le top management, etc. Ces divers groupes d’acteurs se

trouvent, dès lors, indirectement impliqués dans le développement et la mise en œuvre de ces

outils managériaux. Les activités d’interprétation et de négociation ainsi que les pratiques

situées, notamment la prise en compte du contexte du chef de projet, sur lesquelles s’appuient

les acteurs « lean », ont contribué à l’accomplissement de l’activité stratégique.

107Cf. tableau 11.


175

« Une réunion est programmée avec CR (chef de projet) pour définir avec elle la périodicité

du brief, les personnes à impliquer …. Il est important d’avoir un retour sur ses points de vue

et perceptions de la démarche…» (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 c’est lancer une première réunion avec un

chef de projet avec une trame et on en saura pas mal pour voir comment la personne va

réagir » (RB) ;

« C’est pour ça le point de validation au niveau du Codir est fondamental …. Le Codir a

travaillé sur les contenus des ateliers de résolution et validé l'essentiel des thèmes » (TR).

A titre d’exemple, l’implication du chef de projet dans la « fabrication » des outils met en

évidence l’accomplissement social de la stratégie « agile ». En fonction de ses représentations

du contexte, de ses intérêts et de ses prédispositions personnelles, etc. le chef de projet va

adopter l’outil mis à sa disposition, se l’approprier108 dans ses activités, le « contextualiser »

ou simplement le « rejeter ». D’où l’intérêt de nous interroger sur la manière dont les outils

« agiles » sont introduits au sein des organisations. Dans le cas présent, les acteurs se sont mis

d’accord 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 déploiement des outils « agiles » ont été influencés par les objectifs

et les intérêts parfois divergents des parties prenantes. Les réunions quotidiennes de type

« daily-scrum » et les ateliers d’amélioration continue de type « kaizen » ont été considérés

par certains chefs de projet comme une charge supplémentaire conduisant l’équipe « lean » à

repenser leurs pratiques d’implémentation :

« Je pense que c'est une bonne idée, 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 méthode est un peu fastidieuse… ce que je vois ici en tant que

manager c’est qu’on peut passer un temps indéterminé pour analyser les causes… » (PB) ;

« On a l’impression de passer notre temps dans des réunions » (DN) ;

« On s’est adapté en fonction de ce que chacun voulait » (TR).

108S’approprier un outil, c’est « littéralement pour une organisation « rendre propre à un usage » cet outil et le

« faire sien », action qui passe possiblement par une adaptation ou une modification de l’outil par l’organisation.

Sa différence avec le concept de « contextualisation interne » tel que défini par Albert David évoque non

seulement l’idée d’une transformation de l’outil par l’organisation, mais aussi celle de l’organisation par l’outil »

(Rouquet, 2009).


176

Bien que les l’utilité des réunions quotidiennes et des sessions « kaizen » soit mise en avant

dans le discours des acteurs, leur mise en pratique paraît difficile au sein de l’organisation

Nextv : elle nécessite beaucoup d’investissement en termes de temps et d’efforts. Pour les

chefs de projet, l’animation régulière des équipes et les sessions d’amélioration continue de

type « kaizen » exigent discipline et rigueur et requièrent beaucoup de temps que ces premiers

affirment ne pas disposer. Il est donc loin d’être envident, pour un manager d’équipe,

d’organiser des réunions quotidiennes ou d’animer régulièrement des ateliers « kaizen » avec

des acteurs de différentes équipes alors que chacun est engagé dans plusieurs projets en

parallèle et a ses propres contraintes et préoccupations.

« La mise en place de la méthode est un peu fastidieuse… ce que je vois ici en tant que

manager c’est qu’on peut passer un temps indéterminé pour analyser les causes… » (PB).

Cependant, les connaissances dont disposent les parties prenantes sur le lean management et

les méthodes « agiles », semblent avoir également influencé la manière dont ces approches

managériales sont appréhendées et mises en œuvre. Les parties prenantes n’étant pas

suffisamment informées sur ces nouvelles méthodes de management de projet, leurs échanges

se sont avérés peu constructifs. Le manque de cadre de référence commun et de maîtrise de

ces méthodes émergentes a entravé la création de sens de la démarche compliquant dès lors

son développement et déploiement. Outre les difficultés liées à l’applicabilité des outils

« agiles », les équipes projets n’ont pas été formées sur ces méthodes ce qui a eu pour effet de

compliquer davantage leur mise en place. L’intention d’usage de ces outils a par conséquent

été affectée. La formation des équipes aux méthodes « agiles » et leur sensibilisation aux

objectifs et effets d’usage de ces dernières auraient sans doute pu aboutir à une meilleure

contribution collective à la définition et au déploiement de la démarche.

« Les personnes ne connaissent pas spécialement le lean et ce n’est pas évident pour elles de

voir qu’est ce qu’elles vont gagner dans leur domaine en mettant en place le lean » (ER);

« La plupart des personnes impliquées dans la démarche n’ont pas entendu parler du lean »

(JP).

La présence réelle ou imaginée des autres a peut être aussi eu un impact sur l’implémentation

des outils « lean ». La création de sens est ainsi conditionnée par les préférences et les

comportements réellement exprimés par autrui ou tout du moins que nous interprétons comme

tels. Les enjeux de la direction et ses attentes à l’égard de la démarche ont été exposés à


177

plusieurs reprises dans les discours conversationnels des acteurs « lean ». Ils constituent, pour

eux, les cadres de référence des actions à mettre en œuvre.

« À l’issu du pilote, JM (DG) insiste sur le fait d’avoir un objectif chiffré, comme par exemple

on peut gagner tant pour cent sur le coût de déploiement de telle action, c’était certainement

ses attentes ….. Je ne sais pas, c’est une interprétation » (TR) ; « La direction a pour but de

gagner en agilité…. l’idée est de répondre aux enjeux de la direction entre la période 2010-

2012 avec nos moyens constants » (RB).

Mis à part les enjeux définis et présentés par la direction générale « gagner en agilité,

répondre aux besoins de nos clients, faire des projets plus courts et mieux tenir nos délais »,

les membres de l’équipe « lean » ne disposaient ni de points de repères ni de directives

concrètes les assistant dans l’élaboration de leur projet « globalement ce qui attend de nous en

termes d’amélioration c’est qu’on soit plus agile de façon à ce qu’on puisse répondre aux

enjeux d’ici 2012 » (TR). En effet, le terme d’agilité, bien que souvent mis en avant dans les

discours du directeur général demeurait très global et n’offrait aucune possibilité d’action

concrète facilement applicable au contexte. La démarche « lean » a par conséquent pris, dès le

début, une allure abstraite et théorique. Suite aux retours qu’ils ont eu du terrain (équipes

pilotes, Codir) par rapport au bilan de la phase pilote de la démarche, les acteurs « lean » se

sont rendus compte de son image « abstraite ». Par conséquent, ils ont tenté, à nouveau, à

travers leurs conversations et pratiques, de la réorienter. Si les méthodes « agiles » se veulent

pragmatiques, leur mode d’application, en dehors des équipes de développement de taille

réduite, demeure vague et abstrait.

« La démarche lean est donc la réduction des dysfonctionnements. Pour cela on va chercher à

appliquer des procédures standards, des modes opératoires standards. On va trouver une

bonne méthode, on va la décrire et la répéter » (TR) ;

« Ce qui me manque sont les objectifs clairs de la démarche … On a trop dilué les messages.

Je pense qu’il faut être beaucoup plus directif… il faut être plus rigoureux dans l’action

plutôt que dans la méthode » (RB).

Comme ils le font remarquer dans leurs échanges, les acteurs « lean » manquent de solutions

« clés en mains » faciles à mettre en place. Par conséquent, ils sont amenés à « modéliser »

des outils appliqués dans d’autres contextes en vue de les adapter au leur. A titre d’exemple,

les acteurs « lean » se sont appuyés sur une présentation d’un tableau visuel qui montre

comment une équipe peut, grâce à cet outil, échanger et partager les indicateurs de

performance. Or, l’image du tableau visuel mobilisée montre un environnement de travail où


178

les personnes sont présentes physiquement et non pas virtuellement, ce qui est loin d’être leur

cas. Cette focalisation sur le contenu des outils mobilisés par l’équipe « lean » nous amène à

mettre l’accent sur le rôle des outils dont disposent les praticiens dans la « fabrication » de

leur stratégie.

La démarche « lean » telle qu’elle a été initialement construite a subi de nombreux

changements au fur et à mesure de l’avancement de la phase pilote. Le sens du projet a été

modifié à plusieurs reprises conduisant, à chaque fois, à de nouveaux plans d’action. Les

réunions rétrospectives auxquelles ont participé les membres de l’équipe « lean » ont été, pour

eux, l’occasion de revenir sur les actions réalisées, de découvrir le sens de ce qu’ils ont fait et

de mettre en place de nouvelles actions. Le caractère rétrospectif de leurs pratiques a dès lors

permis l’intégration des changements et la réorientation de la démarche. La mise en œuvre des

outils « agiles » s’est manifestée par des allers-retours sur le terrain permettant aux acteurs de

découvrir leurs préférences et celles des acteurs pilotes et d’ajuster leurs comportements. Les

stratégies de ces acteurs ont ainsi été réadaptées aux besoins émergents du contexte.

« Je trouve un peu abrupt et peu explicite le fait d’avoir résumé la reformulation de la

démarche, elle-même déjà synthétique ce qui ne veut pas forcément dire claire,

malheureusement…. » (ER) ;

« Je partage le fait qu’on n’a pas été bon collectivement dans la restitution du travail, parce

qu’on a été soit trop dans la démarche, dans les outils soit trop dans l’approximation 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 démarche

lean sur le projet R3 ZNE, et donc la première réaction est qu’on arrive un peu après la

bataille puisque le projet est quasiment terminé » (TR) ;

« On essayera de profiter des retours d’expérience avant de procéder dans la démarche »

(PB).

Nos observations et analyses montrent que les acteurs ont tendance à réfléchir avant d’agir. Ils

planifient leurs activités, examinent leurs stratégies en anticipant les conséquences des actions

éventuelles et de ce fait, s’engagent, en fonction des moyens à leur disposition, dans celles qui

leur paraissent les plus utiles. La démarche est dès lors guidée, de façon incrémentale, par le

biais des anticipations des acteurs et leurs représentations de l’environnement. Leurs

projections dans des plans d’actions futurs soulignent le caractère « anticipatif » de leurs

actions « on va sortir…; ce qu’on peut faire c’est.. ; l’objectif est de continuer… ».


179

« Peut être qu’il y a une autre manière de procéder, je pense qu’on n’a 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 démarche sur des projets pilotes » (TR) ;

« Ce qu'on peut faire aussi, c’est lancer une première réunion avec un chef de projet avec

une trame et on en saura pas mal pour voir comment la personne va réagir » (RB).

Par ailleurs, nos observations et analyses ont mis en avant l’influence de l’identité

organisationnelle des acteurs sur la manière 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 impliqués dans la « fabrique » de la stratégie

cherchent à produire une représentation de ce qui se passe, conformément avec ce qu’ils

souhaitent être ou paraître « c’est à partir de notre identité que s’élabore le processus par

lequel nous donnons du sens. L’identité est constitué d’une multitude de soi entre lesquels les

individus circulent » (Vidaillet, 2003, p.40).

Différentes conceptualisations de l’identité organisationnelle existent (Gioia, 1998). Nous

retiendrons celle qui s’inscrit dans une approche interprétativiste où l’identité est considérée

comme une expérience subjective vécue par les membres de l’organisation. De ce point de

vue, l’identité organisationnelle fait référence à la vision des membres au sujet de leur propre

organisation et se construit par le biais de leurs négociations continues.

Dans le présent contexte, l’identité organisationnelle s’est progressivement développée à

travers les activités discursives des membres de l’équipe « lean » et leurs interactions avec

leur environnement. La définition des attributs de la démarche a par conséquent fait l’objet de

nombreuses réunions au cours desquelles les acteurs ont cherché à avoir une compréhension

collective de celle-ci, communément partagée. Un ensemble de croyances et de valeurs a

émergé renvoyant à la manière dont les acteurs se sont auto-définis et affichés par le biais de

leur projet. Une attention particulière a été accordée à l’image véhiculée auprès de leur

organisation. Les termes utilisés pour qualifier la démarche « lean » (organisation « agile »;

esprit d’équipe; transparence, etc.) ont longuement été négociés et interprétés.


180

« On a présenté le projet comme étant du lean et donc il faut respecter l’identification de

marques » (TR) ;

« On a des mots importants transparence, communication, identification des problèmes »

(JP) ;

« On dit qu’on va changer un état d’esprit, un mode de fonctionnement, on va rapporter un

système de management » (TR).

L’identité organisationnelle à travers laquelle s’affiche l’équipe « lean » vise principalement à

démarquer la démarche actuelle des projets antérieurs de changements organisationnels.

L’appellation de la démarche renvoie à l’école Japonaise du « lean » qui a connu un succès

considérable dans l’industrie automobile. Les avantages associés à cette approche

managériale, très parlante, ont fait d’elle une démarche particulièrement attractive dans le

monde de développement informatique. Cependant, il existe un décalage entre l’image

organisationnelle que l’équipe souhaite donner par le biais de la démarche « lean » et la

connotation réelle de celle-ci. En d’autres termes, la démarche, réellement entreprise, diverge

considérablement de la philosophie managériale lean. Ce constat renforce l’intérêt

d’appréhender la stratégie comme « pratique » afin de saisir ce que les acteurs « lean » font

réellement et par conséquent, ne pas se limiter à ce qu’ils affirment être en train de faire.

Tout au long du projet, les acteurs « lean » se sont appuyés sur leur représentation préétablie

de la démarche « lean » et sur le discours du directeur général afin de s’influencer entre eux et

d’influencer les autres acteurs concernés par la démarche (acteurs pilotes, organisation ou

acteurs « lean »).

D’un point de vue général, le niveau hiérarchique des acteurs chargés de conduire une

démarche de changement impacte fortement la manière dont le changement sera appréhendé

par les individus concernés. Dans le présent contexte, les acteurs « lean » ne disposent ni de

« pouvoirs de position109 » ni de « pouvoirs personnels110 », au sens strict du terme, pour

influencer l’adhésion de l’organisation aux outils et plans d’action proposés. La recherche de

109Les « pouvoirs de position » comprennent le « pouvoir » coercitif fondé sur la capacité de menacer et

d’exercer des sanctions, le « pouvoir de renforcement » fondé sur la capacité d’offrir une faveur ou une

récompense à la personne et enfin le « pouvoir légitime » fondé sur l’autorité formelle associée à un poste

hiérarchique (French & Raven 1992). 110Les « pouvoirs personnels » regroupent le « pouvoir de référence » fondé sur la capacité d’influencer parce

que l’on est sujet de référence et le « pouvoir de l’expertise » fondé sur les connaissances réelles ou supposées,

sur la compétences professionnelles qui autorise le détenteur de ce savoir à formuler des avis faisant autorité

(French & Raven 1992).


181

légitimité dans la présentation et l’interprétation du projet « lean » devient alors indispensable

pour convaincre les équipes projets de son utilité.

Avant de nous focaliser sur la manière dont les acteurs ont cherché à accroître leur légitimité

auprès des équipes pilotes et de leur organisation, nous nous attarderons sur la manière dont le

« coach » de l’équipe « lean » a réussi à convaincre son équipe du bien fondé de ses

propositions. En effet, ses connaissances et son expertise dans les programmes d’amélioration

de type « kaizen » lui ont permis de s’affirmer fermement autour de la conduite du projet,

d’influencer les perceptions de ses collaborateurs et de transformer, dès lors, l’activité

stratégique. Cela nous conduit à mettre l’accent sur l’importance des connaissances et des

prédispositions personnelles, en l’occurrence l’expertise et la sensibilité du coach « lean » aux

ateliers kaizen, dans la « fabrication » de la stratégie.

« Le lean c’est bien un levier majeur de mise en place de l’amélioration continue pour

satisfaire le client…. l'aspect managérial du lean on l’a sur les programmes kaizen….. Le

lean ne peut pas être fait dans un océan où tout le monde s’en fout…. Le premier volet du

lean est du kaizen et le second volet c’est du brief et du coaching » (RB) ;

« Pour moi, si je peux y aller, ce qui me paraît avoir du sens mais je suis déjà dans la

réponse, c'est qu'il y a des projets pour lesquels on a un périmètre très large et le problème

est un problème de mettre autour de la table des gens qui n’y viennent pas parce qu'ils ne

sont pas concernés…. » (RB) ; -« Donc c’est bien ça? Rendre les acteurs plus concernés par

les interactions ?.... je suis d’accord avec toi…. » (TR).

Dans la majorité des cas, les membres de l’équipe « lean » ont acquiescé sans discuter les

propos avancés à l’égard des différents aspects de la démarche (les plans d’actions à mettre en

place, la manière de procéder, les outils à adopter, etc.). Cette attitude assez passive

s’explique par le manque de connaissances et d’expériences des acteurs dans le domaine du

lean et de l’agilité.

« Quand RB nous a aidé à mettre en place le projet, il avait dit que c’est important d’avoir

des personnes opérationnelles au sein de l’équipe, et on a donc suggéré aux managers de

regarder au sein de leur équipe et d’identifier des personnes qui auraient cette sensibilité

pour participer à ce projet » (TR),

« RB nous a dit de procéder différemment et de mettre en place des ateliers » (TR).

Outre le sens créé des situations et des représentations préétablis par leur « coach », les

membres de l’équipe « lean » ont, à leur tour, tenté d’influencer les équipes pilotes dans


182

l’adoption de la démarche. Leur objectif est de convaincre les acteurs pilotes du sens

« construit » de la démarche pour que ces derniers s’engagent dans son expansion au niveau

de leurs équipes projets.

« Il est important de montrer que ce n’est pas une activité supplémentaire de faire du lean

mais un vrai investissement » (RB) ;

« J’insiste pour que les managers soient là et il faut les convaincre, pour qu’ils soient autour

de la table et qu’on les lâche pas. Je ne vois pas d’autres solutions que d’insister auprès

d’eux et les pousser à s’impliquer….Il faut que les managers acceptent de s’y mettre sinon ça

ne peut pas marcher…» (RB).

Parmi les stratégies adoptées par l’équipe « lean » pour mettre en avant les apports de la

démarche, citons les ateliers de remontées des dysfonctionnements à partir desquels les

projets ont été analysés. Outre l’intérêt en soi de ces ateliers (analyser ce qui ne va pas dans le

déroulement des projets), ils ont constitué un moyen, pour l’équipe « lean », de mettre en

avant les défaillances des modes organisationnels et managériaux existant et de souligner le

besoin de changement des modes de fonctionnement. Ils constituent dès lors un moyen pour

promouvoir les outils « agiles ».

«Quand on identifie un problème on fait le tour avec un outil pour préciser et expliquer les

problèmes. C’est le QQOQCP » (RB) ;

« Quand on aura fini les premiers ateliers, on aura des inputs complémentaires pour faire

d’autres ateliers….» (TR) ;

« Avant le déploiement des outils sur le projet FTTH, il faut montrer comment les besoins de

coordination et d’échanges d’information peuvent être résolus par un brief » (TR).

Les dysfonctionnements évoqués par les participants ont permis aux acteurs de justifier,

auprès du top management et des équipes de l’entité Nextv, le sens et l’utilité de la démarche

managériale entreprise. A cette fin, l’équipe « lean » a mis l’accent sur la quantification des

problèmes remontés en termes de gaspillages. Selon les acteurs « lean », le fait d’avoir des

éléments quantitatifs, « parlant », pourrait intéresser le top management et convaincre les

managers de la nécessité du changement malgré le fait que la valeur des pertes quantifiées

était biaisée. L’identification et quantification des dysfonctionnements a ainsi permis à

l’équipe « lean » d’accroître la légitimité de leurs actions et d’influencer les autres vers le

changement des modes de fonctionnement.


183

« Chacun est censé avancer ces problèmes et on ne demande pas l’évaluation de tous. Nous

sommes là pour décrire le problème d’une façon la plus précise. C’est à nous de les

quantifier après… » (RB) ;

« L’important c’est d’essayer de quantifier en termes de temps perdu… même si c’est à la

louche, il faut essayer de quantifier chaque dysfonctionnement…» (RB) ;

« Ça serait bien de trouver une unité de mesure, là tu as l’indicateur, et l’idée est de dire ce

qui va bouger avec cette action…. La manière dont on peut aussi approximer c’est en gros

qu’est-ce qu’on peut gagner en temps, en moyenne » (RB) ;

« Aujourd’hui on va s’attacher à énoncer les problèmes afin de les quantifier…. Dans nos

résultats ça serait bien de mettre quelques choses comme qu’est ce que ça apporte, qu’est ce

que ça change… présenter un kit de communication en mettant en lumière le gain des

résultats » (TR).

Face au besoin d’améliorer les managériaux des projets pilotés par l’entité Nextv, les outils

« agiles » ont été présentés comme des moyens offrant la possibilité d’accroître la

productivité des équipes et de réduire les gaspillages générés dans les projets actuels. Diverses

stratégies de communication ont ainsi été mises en place. Des « rendez-vous d’information »

ont été organisés, un mois après le lancement du projet, avec l’ensemble des acteurs de

l’entité pour présenter les objectifs et l’avancement de la démarche « lean ».

« Nous vous proposons ces rendez-vous pour vous présenter plus en détail le projet « lean »

Nextv, les actions réalisées et les actions en cours. Au cours de ce point vous pourrez posez

toutes les questions que vos souhaitez sur la démarche » (RB).

Afin de justifier le bien fondé de leur projet et de sensibiliser les équipes projets, les acteurs

« lean » se sont continuellement référés, lors de leur présentation, au discours du directeur

général en insistant sur les enjeux de la démarche : « aujourd’hui sur la télévision on est plus

de cent personnes et au niveau de la direction DP on est plus de 300 personnes impliquées

dans le projet, et donc il y a pas mal de monde et être plus nombreux n’est pas forcement plus

productif … il y a un vrai besoin de changer de mode de fonctionnement et de production…. »

(Directeur Général). Ces rendez-vous leur ont permis de rappeler les dysfonctionnements,

d’insister sur la nécessité de changer les modes de fonctionnement actuels, de promouvoir les

outils « agiles » et de répondre aux questions que se posent les équipes par rapport à la

démarche : « nous vous proposons ces rendez vous pour vous présenter plus en détail le

projet lean management à Nextv… Une large part du rendez vous sera réservée aux

questions/réponses. Ces points se dérouleront par Coop’Net » (TR).


184

En effet, au cours de ces « rendez-vous d’information », des remarques subtiles ont été

soulignées par les participants : absence du marketing, implication des diverses entités, etc.

Bien que ces constatations renvoient à des lacunes importantes quant à la mise en œuvre de la

démarche, elles n’ont toutefois pas été prises en compte par l’équipe « lean ». Elles auraient

impliqué l’élargissement du périmètre de la démarche et donc l’intervention d’autres parties

prenantes ce qui n’était pas à la portée de l’équipe « lean » (manque de temps, manque de

sponsors sur la démarche, faibles possibilités d’action, etc.). Conscients de leurs possibilités

limitées d’action, la « fabrication » de la stratégie a été conduite par la plausibilité.

« Nous on va travailler dans le sens d’amélioration de réduction de gaspillage, mais est -ce

que ce travail se fait aussi d’une autre manière mais parallèlement côté marketing pour

optimiser la façon dont sont gérées les demandes, de façon à ce qu’on ait aussi une réduction

de gaspillage lié à un aspect de la demande qui ne se justifie pas toujours » (LM).

Une lettre d’information bimensuelle a également été diffusée au sein de l’organisation. Elle

s’adresse à un grand nombre de personnes travaillant au sein du groupe. Cet outil stratégique

a permis aux acteurs « lean » de transmettre leur représentation préétablie de la démarche,

d’initier les équipes au vocabulaire « lean », de rappeler les objectifs de la démarche et de

communiquer sur l'avancement des travaux (projets pilotes retenus, dysfonctionnements

remontés, plans d’actions mis en place, témoignages d’équipes ayant déployé des pratiques

« agiles », etc.) (Annexe X).

« Je suggère qu'une phrase (en gras) les nomme : devenir plus agiles avec des moyens

constants, devenir meilleurs sur les délais, améliorer la transparence, faire plus court, Il

serait bien qu'ils soient rappelés lors de toutes nos communications » (RB) ;

« La communication sur le projet se fait notamment à travers une revue d’information qui

parait tous les 15 jours où on définit quelques concepts clés du lean management, on souligne

l’avancement du projet et on fait témoigner quelqu’un sur son expérience ou perceptions à

l’égard de cette démarche managériale …» (TR).

Au travers ces moyens de communication et leur contenu (lettre d’information, ateliers de

remontées de dysfonctionnement, rendez-vous d’information), les acteurs ont tenté

d’apporter, aux parties prenantes de la démarche, une interprétation de la réalité

« préconstruite » et par la même occasion, d’influencer leurs compréhensions et perceptions

de celle-ci.


185

Il n’est toutefois pas garanti que le sens créé par l’équipe « lean » par rapport à la démarche

soit pris en compte et approuvé par les acteurs pilotes et cela malgré les nombreuses tentatives

de cette première. D’ailleurs, par la suite, peu d’équipes ont continué à utiliser les outils

« agiles » soutenus par le projet. Selon certaines personnes interrogées, la démarche telle

qu’elle a été proposée, manque d’originalité « Cette démarche aurait pu être plus

révolutionnaire, plus sympathique, elle ressemble à une énième démarche de qualité » (JFR).

Même si le besoin de renforcer la collaboration entre les équipes et d’améliorer la

communication et la vision commune des projets est fort, la mise en place des outils « agiles »

n’a pas pu être généralisée, en tout cas à l’heure actuelle, au niveau des équipes projets de

l’entité.

Malgré l’expansion des méthodes « agiles » et leur adoption par de nombreuses sociétés

informatiques, beaucoup d’équipes aujourd’hui, recourant à des méthodes « classiques » de

management de projet, ont du mal à accepter et à intégrer ce type de pratiques managériales

qui nécessitent une réactivité, un suivi permanent et donc une dynamique organisationnelle

peu présente dans les approches « classiques». Ce constat est encore plus accentué au niveau

de larges équipes œuvrant dans un environnement « complexe » où l’agilité exige une

restructuration et une réorganisation. Les méthodes « agiles » en tant qu’ « innovations

managériales » ne sont pas formalisées de façon à ce qu’elles puissent constituer des

méthodes de gestion de projet « clés en mains » prêts à être confrontés aux organisations.

Elles renvoient à une logique d’organizing d’acteurs impliqués dans leur « fabrication » et

mise en application.

Dans le cadre de ce travail, la perspective de la stratégie comme « pratique » nous semble

avoir constitué un cadre d’analyse pertinent pour comprendre comment les acteurs, à travers

leurs pratiques, contribuent à la « fabrication » de la stratégie. Afin de mieux saisir la

« fabrication » de la stratégie, nous avons mobilisé la grille d’analyse du sensemaking qui

nous a permis d’appréhender le phénomène d’implémentation de la démarche dans la

perspective des sujets participant à sa création. Par conséquent, en nous focalisant sur les

conversations des individus, leurs activités interprétatives, leurs interactions avec leur

environnement, leur mobilisation des outils, etc. nous avons pu identifier une liste assez

générale de pratiques situées sur lesquelles s’appuient les acteurs chargés de la mise en œuvre

d’une stratégie « agile ». Parmi ces « pratiques », citons : les réunions stratégiques, les ateliers

organisés avec les équipes pilotes, les réflexions collectives sur les caractéristiques


186

contextuelles, la délimitation des situations problématiques, le « cadrage » des outils

« agiles », la diffusion du sens de la démarche, les allers-retours sur le terrain qui servent à

adapter les outils « agiles » retenus, la recherche d’informations auprès des organisations

œuvrant dans un contexte similaire, la mobilisation du discours du directeur général pour

légitimer la démarche, etc.

Ainsi, nous positionnons notre projet de recherche sur les deux dimensions de

« compréhension » (« verstehen ») : la première concerne la manière dont les acteurs

attribuent un sens aux phénomènes organisationnels, à leurs activités quotidiennes et à celles

des personnes avec qui ils interagissent ; et la seconde renvoie à la stratégie de recherche

adoptée pour expliquer et traduire la réalité organisationnelle telle qu’elle est expérimentée et

vécue par les acteurs « comprendre, c'est-à-dire donner des interprétations aux

comportements, implique nécessairement de retrouver les significations locales que les

acteurs en donnent » (Girod-Séville & Perret, 2007, p. 24). Notre réflexion relève, dès lors,

d’une posture épistémologique compréhensive et interprétativiste.

L’environnement complexe dans lequel opère l’équipe « lean » et l’absence d’outils « agiles »

définis de manière précise et détaillée semblent avoir compliqué la mise en œuvre de la

démarche. Si les acteurs « lean » prétendent adhérer à une philosophie gestionnaire de type

« agile », leur vision de celle-ci demeure simplifiée et leur maîtrise des substrats techniques

associés à ces méthodes managériales est faible. Au stade de notre recherche, la démarche

« lean » ne semble pas avoir abouti à ses fins dans le sens où les outils n’ont pas été adoptés,

et appropriés par les équipes pilotes. Seuls quelques plans d’action ont été mis en place au

niveau d’un groupe restreint d’acteurs. Cependant, ces plans d’action ne renvoient pas à une

démarche dynamique de résolution de problème telle qu’elle est valorisée par ces approches

managériales émergentes. Ils répondent à un problème précis et d’une manière bien structurée

(porteurs et contributeurs définis ; plan d’amélioration fixé à l’avance, etc.). Dans cette

perspective, les acteurs sont amenés à respecter leur plan d’action tel qu’il a été défini. Ainsi,

nous nous éloignons des logiques managériales portées par les approches « agiles » et en

particulier par le lean management où la démarche d’amélioration doit être intégrée dans le

mode de fonctionnement des équipes. En ce sens, les managers interviennent sur le terrain de

façon continue pour résoudre les problèmes dès leur apparition. Par ailleurs, il convient de

noter que la mise en place de ces plans d’action fut, de loin, plus facile à être acceptée par

rapport aux outils « agiles » (réunions quotidiennes, tableau blanc, ateliers kaizen, etc.) qui,


187

elles, relèvent des dynamiques d’organizing. Ce propos met en avant les difficultés des

organisations de grande taille et complexe, à assumer les activités d’organizing et leur

tendance à privilégier les procédures et les activités « formalisées ».

188

Conclusion générale

189

CCoonncclluussiioonn ggéénnéérraallee

Alors qu’aujourd’hui les cabinets de conseil en système d’information 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.), s’intéresser de près à ces

« innovations managériales » et à la manière dont elles sont confrontées à la réalité des

entreprises, nous a semblé revêtir une importance cruciale. Dans cette conclusion générale à

notre document de doctorat, nous résumons les principales étapes du raisonnement de notre

travail et exposons les apports de cette thèse mais aussi ses limites ainsi que des pistes de

recherche futures.

1. Résumé des principaux résultats de recherche

Les méthodes « agiles », celles qui relèvent du développement informatique comme

« scrum », « XP » mais aussi celles, plus englobantes comme le « lean SI », rencontrent

aujourd’hui un succès considérable dans le discours des praticiens en management de projets

logiciels. A quel(s) type(s) d’approches managériales ces méthodes renvoient-elles? Quelles

sont les points communs entre les différentes méthodes dénommées « agiles » et comment se

différencient-elles ? En quoi constituent-elles des « innovations managériales » ?

L’intérêt actuel pour les méthodes « agiles » renvoie à la remise en cause du modèle

« classique » de management de projet relativement à des enjeux de réactivité des entreprises

soumises à un environnement concurrentiel de plus en plus intense. Les entreprises

empruntant la voie de « l’agilité » cherchent à concilier les exigences antagonistes du

tryptique qualité-coût-délai et à s’adapter à un contexte caractérisé par l’incertitude.


190

Dans le chapitre (I) de cette thèse, nous avons présenté les méthodes « agiles » dans leur

dimension « d’innovations managériales » revendiquées par leurs promoteurs et au travers

d’une revue de la littérature concernée. Dans cette perspective, nous les avons analysées du

point de vue de la philosophie gestionnaire et des substrats techniques qu’elles sous-

entendent. La philosophie des méthodes « agiles » s’inscrit principalement dans l’école

japonaise du lean qui a trouvé ses sources dans le Toyota Production System développé dans

les années 1980. Des diverses méthodes « agiles » ayant vu le jour, nous avons retenu trois

méthodes (la méthode « scrum », la méthode « extreme programming » et le développement

lean) qui apparaissent, dans la littérature et dans les milieux concernés, comme

emblématiques de trois modes ou voies « d’agilité ». Dans ce chapitre, nous montrons que ces

trois méthodes représentent une forme d’agilité différente. La méthode extreme programming

constitue un support pour les pratiques d’ingénierie et les aspects techniques du

développement logiciel ; la méthode « scrum » qualifie un ensemble d’artefacts et de

pratiques ingénieriques spécifiques au management et suivi des projets ; le lean renvoie à une

approche globale, holistique, s’intéressant à l’organisation dans son ensemble et allant au-delà

des activités de développement informatique. De fait, l’ensemble de ces trois approches offre

une certaine complétude à l’analyse du substrat « théorique » du courant « agile ».

L’analyse de la littérature portant sur ces différentes approches « agiles » nous a permis de

mettre en avant les points suivants : les méthodes « agiles » ne constituent pas une doctrine de

gestion de projet « agile » « clés en mains ». La philosophie gestionnaire que ces méthodes

sous-tendent et les substrats techniques qui y sont associés soulignent un aspect dynamique de

l’organisation qui se « construit » au fur et à mesure de l’avancement des projets. Ces

méthodes reposent sur un outillage « léger », peu « formalisé » dont on pressent qu’il peut

être particulièrement bien adapté à des équipes de taille réduite, où la collaboration et

l’ajustement mutuel sont faciles à réaliser. Mais les méthodes « agiles » de management de

projet, celles qui participent d’une approche englobante du management laissent en suspens la

question de leur contextualisation interne (David, 1996) tant la philosophie gestionnaire qui

les sous-tendent paraît peu « outillée » par les artefacts de management proposés.

Comment à l’échelle d’une équipe projet de grande taille et relativement à une problématique

de management de projet qui dépasse le périmètre réduit des équipes de développement

informatique, peut-on implémenter une méthode de management « agile » ? Que dit la

littérature de ces méthodes lorsqu’elles sont mises en pratique ?

http://fr.wikipedia.org/wiki/Syst%C3%A8me_de_production_de_Toyota


191

De façon à tenter de répondre à ces questionnements, nous avons consacré le chapitre (II) de

cette thèse à l’analyse la littérature rendant compte de cas d’entreprises ayant mis en pratique

des méthodes « agiles ». Les travaux de recherche étudiés rassemblent des positionnements

contradictoires quant aux domaines d’application des méthodes « agiles ». Ils mettent en

évidence des éléments de contingence organisationnelle susceptibles de faciliter ou pas la

mise en œuvre de ces méthodes. Tous convergent sur l’idée que ces méthodes participent

d’approches alternatives qui semblent pallier les insuffisances et limites des pratiques

managériales « classiques ». Mais si ces premières semblent améliorer sensiblement la

productivité des équipes et réduire significativement les coûts engendrés par les cycles de

développement séquentiel, la planification et la documentation extensives, elles se heurtent

néanmoins à plusieurs difficultés ; leur mise en place exige un environnement de travail

facilitant l’ajustement mutuel : la collaboration étroite entre les acteurs, le partage régulier

d’informations et l’adaptation continue aux sollicitations de l’environnement soit une

configuration organisationnelle qui n’est pas toujours aussi facile à réaliser, en particulier,

lorsque les équipes de projet sont transversales et géographiquement distribuées. Les travaux

rendant compte de cas d’implémentation de méthodes agiles se penchent essentiellement sur

des équipes de développement, par ailleurs de taille réduite. Les quelques recherches qui

concernent les méthodes « agiles » dans les grandes organisations, se sont, dans la majorité

des cas, uniquement focalisées sur les équipes impliquées dans des activités de

développement informatique ; elles laissent totalement en suspens la question de l’articulation

entre un mode de management « agile » déployé dans des équipes d’informaticiens et des

modes plus « classiques » qui supportent le pilotage global des projets concernés.

Les cabinets de conseil et les instigateurs du mouvement « agile » mettent en avant

l’adaptabilité de ces approches de gestion de projet informatique aux organisations de grande

taille et aux équipes projets géodistribuées. Mais à l’heure actuelle, leur implémentation dans

ce type d’organisations reste peu explorée111.

Comment les méthodes agiles peuvent-elles être implémentées dans des configurations

organisationnelles plus complexes que celles décrites dans les études de cas parues dans la

111Afin d’approcher la manière dont fonctionnent les sociétés s’engageant dans la voie de l’agilité, nous avons

organisé un cycle de séminaires sur le « Lean et Système d’Information » (Annexe XVII). Ces séminaires ont

pour objectifs de réunir des praticiens français dans le développement logiciels agile/lean pour observer et

partager leurs pratiques. Un site est dédié pour l’animation de cette communauté : http://leansi.wp.institut-

telecom.fr/.


192

littérature ? Comment, à partir de cette « boîte à outil » que constituent les méthodes agiles,

soit d’un outillage qui paraît quelques fois très « basique », peut-on instrumentaliser une

démarche gestionnaire nourrie d’une philosophie générique d’organizing ?

Pour répondre à ce questionnement, il nous a semblé opportun de recourir à une stratégie de

recherche reposant sur une approche par la « pratique ». Comment « en pratique » construit-

on une stratégie « agile » ? Comment, en contexte organisationnel donné, peut-on faire sens

de ces « innovations managériales » ?

Le chapitre (III) présente notre stratégie de recherche fondée sur l’approche par « la

pratique ». Dans ce courant de pensée112, l’école de « la fabrique de la stratégie » aborde la

stratégie comme une activité située et socialement accomplie, construite par les actions, les

interactions et les négociations de multiples acteurs. C’est dans cette perspective que nous

avons choisi d’aborder notre objet de recherche en nous intéressant aux acteurs impliqués

dans la « fabrication » d’une stratégie « agile » dans leurs interactions avec leur

environnement socio-organisationnel.

Nous nous sommes appuyés sur une étude de cas qui fonde notre perspective

«instrumentale113 ». Le terrain de recherche retenu est contingent à notre problématique : une

entité de management de projets informatiques appartenant à un large groupe français de

télécommunication et ayant décidé de mettre en œuvre une démarche managériale basée sur

les principes des méthodes « agiles ».

Notre étude de cas (chapitre IV) s’est déroulée durant 17 mois au cours desquels nous avons

conduit des observations semi-participantes (37 réunions d’une durée moyenne de deux

heures et 8 ateliers d’une durée moyenne de 5 heures). Nous avons conduit 21 entretiens

semi-directifs d’une durée moyenne d’une heure et demie avec les acteurs concernés par

l’étude. Les données de ce corpus ont été complétées par les documents échangés entre les

acteurs (mails, documents supports préparatoires ou synthèses des réunions).

112Whittington, 1996, 2003 ; 2007 ; Gherardi, 2000, 2001 ; Orlikowski, 2000 ; Jarzabkowski, 2003 ;

Jarzabkowski, Balogun & Seidl, 2007 ; Jarzabkowski & Kaplan, 2008). 113

L’étude de cas instrumentale traite d’une question théorique générale dans l’objectif de fournir une nouvelle

compréhension d’un phénomène ou d’affiner une théorie émergente (David, 2000). Le cas fait l’objet d’une

analyse contextualisée mais toujours en vue d’un intérêt externe. Il ne constitue pas l’objectif ultime de la

recherche. L’étude de cas instrumentale nous confère ainsi une compréhension générale du phénomène

d’implémentation des « innovations managériales» de type « agile » dans un contexte particulier caractérisé par

une complexité organisationnelle.


193

Nous avons adopté une démarche inductive pour analyser le corpus de données brutes. Après

plusieurs lectures des données transcrites, nous avons identifié les idées clés auxquelles

renvoi(ent) chaque mot, phrase et/ou paragraphe. Ces idées ont ensuite été classées dans des

catégories. L’ensemble des catégories a été défini de façon itérative et justifié par des

verbatim. La combinaison de diverses sources de données (acteurs occupant différents statuts

et œuvrant dans différents contextes) et d’instruments de collecte de données (observations-

entretiens-documentation) nous a permis d’enrichir notre champ de connaissances et

d’approfondir nos analyses.

Si cette analyse inductive a été guidée par notre objet de recherche, les résultats, quant à eux,

proviennent des données brutes et non pas de nos réponses « souhaitées ». Nous avons

participé à des workshops (notamment en forme de data sessions), en présence d’experts en

sciences de gestion, qui nous ont permis d’accroître la validité des données transcrites et

interprétées. Ces workshops nous ont offert la possibilité de faire part de nos analyses et

interprétations de données. Les retours remontés durant ces workshops ont, d’un côté,

participé à valider notre processus d’analyse et d’un autre côté, fait émergé de nouveaux

questionnements et points à investiguer.

En nous intéressant à la manière dont les acteurs « fabriquent » une stratégie managériale de

type « agile », dans une structure organisationnelle complexe, notre travail contribue à un

enrichissement du corps de connaissances en gestion de projet « agile ».

L’approche d’analyse « par la pratique » nous a permis d’examiner des réalités sur lesquelles

les praticiens s’appuient pour « construire » une stratégie « agile ». Puisqu’il n’existe pas de

pratiques et d’outils « institutionnalisés » pour implémenter une démarche « agile », la mise

en œuvre de ces outils pose de façon centrale la question du sens que les acteurs vont faire de

ces méthodes 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 méthodes managériales et comprendre comment, par le jeu de leurs

interactions, ils se sont engagés dans la « construction » d’une stratégie « agile ». Cette

démarche d’analyse nous a permis d’apporter un éclairage nouveau sur la manière dont les

acteurs « bricolent » la boîte à outils des méthodes « agiles » et « fabriquent » une méthode de

management « agile ».


194

L’analyse des procédés itératifs d’« enactment » et d’interprétation des acteurs a mis en

lumière un ensemble d’éléments fondamentaux dans la mise en œuvre d’une démarche

« agile ». Le chapitre (V) est consacré à la présentation des principaux résultats d’analyse. La

notion de gaspillage semble être au cœur des préoccupations des acteurs souhaitant s’engager

dans une démarche « agile ». Elle constitue une « clé d’entrée » pour analyser l’existant et

mettre en place une démarche de résolution des problèmes. Les acteurs se sont appuyés sur les

dysfonctionnements « remontés » d’analyses du terrain pour convaincre les parties prenantes

du besoin d’améliorer les modes de fonctionnement des équipes et par conséquent accroître la

légitimité de leur démarche.

Par ailleurs, plusieurs facteurs d’ordre contextuel, identifiés par les acteurs « lean », semblent

avoir fortement influencé la démarche managériale entreprise :

1) La taille et la géodistribution des équipes : le déploiement des outils « agiles » s’avère

difficile lorsque les équipes sont de grande taille et éclatées géographiquement ; nous avons

retrouvé là des éléments évoqués dans la littérature et dans le premier volet de cette thèse ;

2) La structure organisationnelle : le rattachement des acteurs à différents services

fonctionnels et l’autorité limitée du chef de projet entravent le suivi régulier des activités et

le contrôle des équipes ; ce point constitue un apport de notre recherche ;

3) La composition des équipes projets : les changements d’acteurs en cours de projets et leur

rattachement à différents services requièrent des efforts supplémentaires en termes de

synchronisation et de renforcement de la cohésion des équipes et ne garantissent pas la

capitalisation sur les projets menés ; là encore, ce point constitue un apport de notre

recherche ;

4) Le style de management de l’entreprise : la conduite « classique » des projets basée sur

l’anticipation et la documentation ne facilitent pas l’intégration des pratiques et outils

« agiles » ; les résistances culturelles sont fortes ;

5) Le manque d’exemples concrets ou d’outils « clés en mains » : cela conforte une de nos

hypothèses de recherche avancée à l’issue de notre revue de la littérature ;


195

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

démotivation des managers et des chefs de projets ; analyse assez classique dans des projets

innovants ; la lassitude à l’égard du changement ; la surcharge de travail ; le changement de

posture du manager que nécessite une telle démarche, etc.

Bien que ces facteurs relèvent d’un contexte particulier, ils semblent transposables à des

structures organisationnelles similaires. Ils peuvent être envisagés, pour nombre d’entre eux,

comme des facteurs invariants à une analyse contingente pour la mise en œuvre réussie d’une

démarche « agile ».

La démarche managériale de type « agile » a d’emblée été guidée par l’attention des acteurs

accordée à des questionnements d’ordre managérial et organisationnel. A travers leurs

interrogations, les acteurs ont tenté de circonscrire les situations « problématiques » qu’ils

souhaitaient traiter. Ils ont ainsi privilégié certains éléments de contexte en les simplifiant et

en les interprétant. Ils ont mis en œuvre nombre d’actions et ont réagi à nouveau au produit de

leurs actions. Leur manque d’expériences et de connaissances en développement et gestion de

projet « agile », leur volonté de s’afficher en tant qu’équipe « lean », les décisions 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é régies

leurs négociations et interprétations, ont ainsi influencé la manière dont la démarche a été

construite et mise en œuvre.

A lumière de ces résultats, il apparaît que la création d’un environnement « agile » au sens des

« agilistes » nécessite une réflexion ex ante sur le contexte d’application. Nos observations et

analyses montrent que l’implémentation des outils « agiles » se heurte à plusieurs difficultés.

Ainsi, la démarche managériale qui a été entreprise au sein du contexte étudié ne semble pas

avoir abouti à ses fins dans le sens où les outils n’ont pas été adoptés, et appropriés par les

équipes pilotes. Seuls quelques plans d’action ont été mis en place au niveau d’un groupe

restreint d’acteurs.

Nous assistons aujourd’hui à ce qui peut apparaître comme un changement de paradigme de

gestion de projet. Dans un environnement où règne l’incertitude, les entreprises sont amenées

à accroître leurs capacités d’adaptabilité et de réactivité. La philosophie prédictive et

« rigide » des approches « traditionnelles » qui souligne le besoin de planifier et d’estimer de


196

façon définitive l’ensemble du projet devient très risquée et inadaptée. Par-delà le courant des

méthodes « agiles », nous assistons à une diffusion d’approches gestionnaires qui favorisent

des organisations « apprenantes », capables de répondre aux besoins du marché par leurs

capacités d’adaptation, d’amélioration et d’innovation. C’est dans cette perspective de

souplesse d’adaptation et d’évolution permanente que les méthodes « agiles » se sont

inscrites. Elles valorisent, dans les discours gestionnaires qui les supportent, la capitalisation

sur les connaissances, l'apprentissage interindividuel, l’amélioration continue, etc. Toutefois,

ces méthodes se heurtent à des problèmes divers qui relèvent de leur manque de

« formalisme » rendant difficile leur application dans les structures qui dépassent le périmètre

d’une équipe réduite de développement informatique.

De fait, deux situations peuvent être envisageables pour les structures organisationnelles plus

complexes souhaitant emprunter la voie de l’agilité :

(1) une structure et une culture d’organisation qui, dans son ensemble, favorise le

développement d’une organisation « apprenante » dans laquelle le travail collectif et

l’environnement informatif sont mis en avant. Ce cas de figure implique une démarche

soutenue par la direction générale qui pour sa part, doit assurer le support nécessaire en

termes de temps, de moyens, de formations, etc. et favoriser la conduite du changement. Ce

type de chantier « d’innovation managériale » peut puiser dans la boîte à outils des méthodes

« agiles » sans toutefois épuiser par cela, la question de la « fabrique » d’une nouvelle

approche managériale,

(2) l’adaptation des pratiques « agiles » aux réalités de l’organisation concernée. Ce cas de

figure accroît le risque de s’éloigner de la philosophie managériale « agile ». En effet, un

environnement « agile » favorise la collaboration, le travail en binôme, l’apprentissage

interindividuel, le partage des connaissances tacites, les feedback continus, la transparence, le

contrôle continu, etc. Or, la création d’un tel environnement est difficile à construire dans une

grande organisation, à structure complexe. Un travail de « contextualisation » des méthodes

« agiles » doit alors être effectué.

Fondamentalement, il ressort de notre travail de thèse que contrairement à ce que la notion

d’agilité laisse croire, les méthodes « agiles » requièrent un cadre bien structuré où les équipes

intervenant sur un projet doivent être stables, communiquer de façon régulière et être


197

rassemblées sous l’autorité d’un responsable de projet. Autrement dit, les pratiques

managériales qui y sont associées présentent une forme de « rigidité » organisationnelle qui

relève du cadre très structuré et structurant des méthodes « agiles » : livraison itérative toutes

les deux à quatre semaines, réunions quotidiennes avec l’ensemble de l’équipe, disposition du

mobilier pour favoriser le travail en binôme, murs accessibles sur lesquels sont affichés les

fonctionnalités, les tâches, l’agenda de la réunion, etc. Ce cadre est plus adapté aux

organisations « apprenantes » où les équipes sont de taille réduite, travaillent dans un même

espace physique et se coordonnent par ajustement mutuel. Dans des structures plus

complexes, il importe aux managers qui réfléchissent à la « fabrique » d’une démarche

« agile » d’inventer des cadres structurants qui « rigidifient » certaines éléments de

l’organisation afin de lui permettre d’être « agile ». Il convient en effet de formaliser les

procédures d’apprentissage sans préjuger des enseignements à tirer face aux situations

nouvelles révélées par l'apparition de dysfonctionnements. L’acquisition des connaissances

provient en grande partie de la résolution des problèmes. Les dysfonctionnements sont autant

d’occasion d’apprendre à condition d’accepter de les rendre visibles, d’identifier leurs causes

profondes et d’expérimenter des contre-mesures. Dès lors, les actions conduites par les

managers doivent faciliter l’émergence de dysfonctionnements, permettre la recherche de

leurs causes profondes et encourager l’expérimentation. Les méthodes « agiles » deviennent

ainsi des méthodes de formation des collaborateurs. La formation de ces collaborateurs est

encadrée par un ensemble d’outils mais renvoie à l’acquisition de connaissances

indéterminées ex ante.

2. Les apports de ce travail de recherche

Ce travail de thèse aborde les méthodes de gestion de projet « agiles » à partir d’un nouvel

angle d’approche, celui de l’approche « par la pratique ». Aujourd’hui, rares sont les écrits à

avoir mobilisé un construit théorique de ce type pour étudier la mise en place des outils

« agiles » et encore moins nombreux sont ceux à s’être intéressés à la manière dont les acteurs

contribuent à leur « fabrication » dans une structure organisationnelle complexe.

Ce travail contribue ainsi au domaine naissant de « la fabrique de la stratégie » en examinant

les pratiques stratégiques à partir desquels les praticiens transforment la stratégie managériale

de leur entreprise. A ce titre, cette thèse met en avant l’importance de se focaliser sur les


198

micropratiques et les caractéristiques contextuelles pour appréhender la construction et

l’accomplissement social de la stratégie.

En mobilisant la grille d’analyse du sensemaking nous avons pu montrer comment une

approche « par la pratique » peut reposer sur un modèle théorique existant en sciences de

gestion afin d’examiner les activités stratégiques des praticiens.

Sur le plan empirique, cette thèse a permis d’apporter un nouveau regard sur les éléments

d’ordre contextuel susceptibles d’affecter la « fabrication » d’une stratégie « agile ». Grâce à

l’étude longitudinale menée et l’approche d’analyse « par la pratique » adoptée, nous avons

pu recenser une liste de facteurs contextuels identifiés par les acteurs comme contraignant la

mise en place de la démarche et mettre d’avantage l’accent sur la logique d’organizing à

laquelle renvoient ces méthodes de gestion de projet informatique. La prise de conscience de

ces facteurs contextuels permettra d’éviter ou tout du moins d’anticiper une partie des risques

liés à la mise en œuvre de ces pratiques dans une structure organisationnelle complexe et par

conséquent d’accroître les possibilités de « contextualisation » de ces outils émergents de

développement et de management de projet informatique.

En outre, l’approche d’analyse « par la pratique » nous a permis d’examiner de près les

« pratiques » qui semblent jouer un rôle critique dans l’accomplissement de la stratégie. Peu

nombreux sont les travaux qui se sont focalisés sur les prédispositions, les savoirs, l’identité

organisationnelle des parties prenantes d’une entreprise dans l’accomplissement d’une

stratégie « agile ».

3. Limites et pistes futures

Tout en contribuant à la littérature en gestion de projet « agile » et à l’approche de la

« fabrique » de la stratégie, notre recherche présente plusieurs limites qu’il nous faut signaler.

Nos constatations ne sont pas généralisables à l’ensemble des organisations souhaitant mettre

en place une démarche « agile ». Notre analyse empirique concerne un contexte d’étude

particulier et tel était l’enjeu au travers du choix méthodologique que nous avons fait : une

étude de cas instrumentale qui permet d’examiner et d’enrichir le substrat théorique des

méthodes agiles. Toutefois, dans une perspective de généralisation, certains éléments mis en

avant ici nous semblent présenter un caractère générique ; mais bien évidemment d’autres


199

études de terrain seront nécessaires pour aller dans la voie de la généralisation. Il serait

également intéressant d’observer comment d’autres groupes d’acteurs, œuvrant dans des

structures organisationnelles similaires, mettent en place une démarche de management de

projet « agile ».

En outre, le cas étudié mobilise un nombre limité de pratiques « agiles ». Bien qu’au départ

l’équipe « lean » se soit intéressée à plusieurs pratiques et outils « agiles », elle les a

progressivement abandonnés pour se contenter finalement d’une liste assez restreinte. Il serait

donc intéressant, dans la continuité de nos travaux, de nous pencher sur l’application d’un

plus grand nombre d’outils et pratiques « agiles ». Par ailleurs, une étude comparative pourrait

faire ressortir une liste de pratiques stratégiques concernant l’application de ces méthodes

dans de telles structures.

Enfin, nous nous sommes intéressés là à la « fabrique » d’une stratégie « agile » et non à son

adoption et appropriation par les acteurs de terrain. Ce volet d’analyse reste à explorer.

200

Bibliographie

201

BBiibblliiooggrraapphhiiee

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, n°10, pp. 27-34.

3. Agourram H. (2009), « Defining information system success in Germany », International

Journal of Information Management, vol 29, n°2, pp. 129-137.

4. Ajzen I. (1991), « The theory of planned behavior », Organizational Behavior and Human

Decision Processes, vol 50, n°2, 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,

n°8, pp. 681-691.

6. Allard-Poesi F. & Maréchal C. (2007), « La construction de l’objet de recherche », in

Thiétart R.A. & al., Méthodes 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, n°6, 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, n°2, 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 défis 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, n°31, 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.

http://www.sciencedirect.com/science?_ob=ArticleURL&_udi=B6VB4-4VKVC1H-1&_user=771355&_coverDate=04%2F30%2F2009&_alid=907063614&_rdoc=4&_fmt=high&_orig=search&_cdi=5916&_sort=d&_docanchor=&view=c&_ct=13&_acct=C000028498&_version=1&_urlVersion=0&_userid=771355&md5=d212488d56ee736331c19c48f155d6d2

http://www.sciencedirect.com/science?_ob=ArticleURL&_udi=B6VB4-4VKVC1H-3&_user=771355&_coverDate=04%2F30%2F2009&_alid=907042882&_rdoc=2&_fmt=high&_orig=search&_cdi=5916&_sort=d&_docanchor=&view=c&_ct=9&_acct=C000028498&_version=1&_urlVersion=0&_userid=771355&md5=239fb2ee14010df792e20ddfd38e039d#bbib1

http://portal.acm.org/author_page.cfm?id=81341487587&coll=GUIDE&dl=GUIDE&trk=0&CFID=31810116&CFTOKEN=70292717


http://www.cs.toronto.edu/~sme/papers/1996/NASA-IVV-96-002.pdf

http://www.cs.toronto.edu/~sme/papers/1996/NASA-IVV-96-002.pdf

Bibliographie

202

14. Balogun J. & Johnson G. (2004), « Organizational Restructuring and Middle Manager

Sensemaking », Academy of Management Journal, vol 47, n°4, 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, n°4, pp. 390-

396.

16. Baumard P. (1997), « Constructivisme et processus de recherche : l’émergence d’une

posture épistémologique chez le chercheur », Cahiers du LAREGO, UVSQ, n° 27.

17. Beauvallet G. & Chabiron C. (2006), « Le Muda sous la moquette : comment démarrer

une démarche de lean office », Working paper n°3, 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, n°6, pp. 386-396.

23. Blais M. & Martineau S. (2006), « L’analyse inductive générale : description d’une

démarche visant à donner un sens à des données brutes », Recherches Qualitatives, vol 26,

n°2, 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, n°5, pp.61-72.

26. Boehm B. (2002), « Get ready for agile methods with care », Computer Publications, vol

35, n°1, 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, n°5, 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, n°2, pp. 124-139.

http://www.sciencedirect.com/science?_ob=PublicationURL&_tockey=%23TOC%235916%232007%23999729993%23672926%23FLA%23&_cdi=5916&_pubType=J&view=c&_auth=y&_acct=C000028498&_version=1&_urlVersion=0&_userid=771355&md5=5120cc6e554bc6cdb0c65905a2008020

http://www.sciencedirect.com/science/journal/09638687

http://www.sciencedirect.com/science?_ob=PublicationURL&_tockey=%23TOC%236027%232008%23999829997%23690541%23FLA%23&_cdi=6027&_pubType=J&view=c&_auth=y&_acct=C000028498&_version=1&_urlVersion=0&_userid=771355&md5=f70afe9dc1bca4a56a1434b84c5b18a1

Bibliographie

203

31. Chanal V. (2000), « Communautés de pratique et management par projet : A propos de

l'ouvrage de Wenger (1998) », Management, vol 3, n°1, pp. 1-30.

32. Chanal V. (2008), « La stratégie 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 thèses de doctorat », Finance Contrôle Stratégie, vol. 4, n°3, 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, n°6, pp. 961-971.

36. Cockburn A. (2000), « Selecting a project’s methodology », IEEE Software, vol (17), n°4,

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, n°1, pp. 6-12.

39. Cockburn A. & Williams L. (2003), « Agile software development : it's about Feedback

and Change », Computer, vol 36, n°6, 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), « L’étude de cas au service de la recherche », Recherche en soins

infirmiers, n°50, pp. 81-88.

43. Conboy K. & Fitzgerald B. (2004), « Toward a conceptual framework of agile methods: a

study of agility in different 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 managériales », Cahier du

Centre de Gestion Scientifique, Ecole des Mines de Paris, n°12.

49. David A. (2000), « Logique, méthodologie et épistémologie en sciences de gestion : trois

hypothèses revisitées » in David A., Hatchuel A. & Laufer R., Les nouvelles fondations des

sciences de gestion, Vuibert, collection FNEGE.

http://portal.acm.org/citation.cfm?id=972224&dl=GUIDE&coll=GUIDE&CFID=48630808&CFTOKEN=93942518

http://portal.acm.org/citation.cfm?id=972224&dl=GUIDE&coll=GUIDE&CFID=48630808&CFTOKEN=93942518

Bibliographie

204

50. David A. (2004), « Etudes de cas et généralisation scientifique en sciences de gestion »,

Actes du colloque Association Internationale du Management Stratégique (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, n°3, pp. 318-340.

52. Dyba T. (2000), « Improvisation in small software organizations », IEEE Software, vol 17,

n°5, pp. 82-87.

53. Dyba T. & Dingsoyr T. (2009); « Empirical studies of agile software development : A

systematic review », Information and software Technologies, vol 50, n°9-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, n°3,

pp. 613-619.

56. ECOSIP, 1993, Pilotages de projet et entreprise : diversités 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, n°4, 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,

n°4, 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, n°2, pp. 200-

213.

61. Flavián C., Guinalíu M. & Gurrea R. (2006), « The role played by perceived usability,

satisfaction and consumer trust on website loyalty », Information and Management, vol 43, n°1, 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, n°2, 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, n°1, pp. 139-150.

65. Garel G. (2003), le management de projet, La découverte.

66. Garel G. (2003), « Pour une histoire de la gestion de projet », Gérer et Comprendre, n°74.

67. Gherardi S. (2000), « Practice based theorizing on learning and knowing in

organizations », Organization, vol 7, n°2, pp. 211-223.




http://www.martinfowler.com/articles/agileOffshore.html

Bibliographie

205

68. Gherardi S. (2001), « From organizational learning to practice based knowing », Human

relations, vol 54, n°1, 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-Séville M. & Perret V. (2007), « Fondements épistémologiques de la recherche», in

Thiétart R.A. & al., Méthodes 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, n°6,

pp. 1357-1385.

74. Herbsleb J.D. & Grinter R.E. (1999), « Splitting the organization and integrating the code

: Conway’s 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, n°2, pp. 16-20.

76. Highsmith J. & Cockburn A. (2001), « Agile software development : the business of innovation », Computer, vol 34, n°9, 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, n°4, pp. 41-

61.

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 managériales et systèmes d'information :

construction d'un idéal type et modélisations », thèse de Doctorat en Sciences de Gestion,

département Sciences Économiques et Sociales, Télécom Paristech.

80. Hollnagel E., Journé B. & Laroche H. (2009), « Fiabilité et résilience comme dimensions

de la performance organisationnelle », Management, vol 12, n°4, 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, n°4, 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, n°2, pp. 227-

241.

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, n°1, 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.



http://www.sciencedirect.com/science?_ob=ArticleURL&_udi=B6VD0-4P0NC1H-1&_user=771355&_rdoc=1&_fmt=&_orig=search&_sort=d&view=c&_acct=C000028498&_version=1&_urlVersion=0&_userid=771355&md5=3c5dcb6640f66a5bee3039ca9d7ba25d#vt1



Bibliographie

206

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

and change », Journal of Management Studies, vol 40, n°1, pp. 23-56.

86. Jarzabkowski P. (2004), « Strategy as practice: recursive, adaptive and practices-in-use »,

Organization Studies, vol 25, n°4, 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, n°1, 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 à l’analyse de l’activité managériale dans un contexte d’ambiguïté et d’incertitude », Management, vol

11, n°1, 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. Kähkönen T. & Abrahamsson P. (2004), « Achieving CMMI level 2 with enhanced

Extreme Programming approach, Lecture notes in computer science, vol 3009, pp. 378-392.

94. Karlström D. & Runeson P. (2005), « Combining agile methods with stage-gate project

management », IEEE Computer Society, vol 22, n°3, 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, n°6-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, n°4, 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 tranchées, 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.

Bibliographie

207

103. Koenig G. (2003), l’organisation dans une perspective interactionniste, in Vidaillet B., le

sens de l’action, 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, n°4, 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, n°9, 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,

n°4, pp 469-480.

111. LeJeune N.F. (2006), « Teaching software engineering practices with extreme

programming », Journal of Computing Sciences in Colleges, vol 21, n°3, 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, n°1, 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.

Bibliographie

208

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. 42-54.

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 student’s perceptions

of agile methods », International conference of Software Engineering, pp. 481-488.

124. Messager Rota V. (2008), Gestion de projet – vers les méthodes 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, l’entreprise en question », in ECOSIP Pilotages

de projet et entreprises : diversités 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 rôles 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 d’un projet système d’information, Dunod, 6ème édition.

133. Murru O., Deias R. & Mugheddu G. (2003), « Assessing XP at a European Internet

Company », IEEE Software, vol 20, n°3, pp. 37-43.

134. Navarre C. (1993), « Pilotage stratégique 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, n°5, pp. 440-457.

http://www.springerlink.com/content/978-3-540-26277-0/

Bibliographie

209

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, n°2, pp. 174-207.

138. Orlikowski W. (2000), « Using Technology and Constituting Structures : a Practice Lens

for Studying Technology in Organizations », Organization Science, vol 11, n°4, pp. 404-428.

139. Orlikowski W.J. &Yates J. (2006), « ICT and Organizational Change », The journal of

applied behavioral sciences, vol 42, n°1, 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, n°2, 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, n°9, 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 , Addison-Wesley.

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 française d'économie. vol 9, n°1, 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, n°10, pp. 41-46.


Bibliographie

210

154. Rising L. & Janoff N. (2000), « The scrum software development process for small

teams », IEEE Software, vol 17, n°4, 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, n°6, 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, n°7, pp.1413-1441.

159. Rouleau L. (2006), « Comprendre la fabrique de la stratégie à partir des récits de pratique » in Golsorkhi (ed), La fabrique de la stratégie (pp.219-239), Paris, Vuibert.

160. Rouleau L. & Balogun J. (2007), « Exploring the middle manager’s strategic sensemaking role in practice », paper presented at the academy of management.

161. Rouleau L., Allard-Poesi F. & Warnier V. (2007), « Le numéro spécial de la RFG-AIMS fait peau neuve », Revue Française de Gestion, vol 33, n°174, pp. 13-14.

162. Rouleau L. & Balogun J. (2008), « Exploring middle manager’s 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, n°6, pp. 376-386.

164. Samra-Fredericks D. (2003), « Strategizing as lived experience and strategist’s everyday

efforts to shape strategic direction », Journal of management studies, vol 40, n°1, pp. 141-

174.

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, n°3, 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, n°4, 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, n°7, pp. 506-

518.

171. Sharp H., Hall T., Baddoo N. & Beecham S. (2007), « Exploring motivational

differences between software developers and project managers », ESEC/FSE.


Bibliographie

211

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, n°1-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, n°8, 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, n°6, 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, n°12, 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, n°20, 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 in Computer

Science, vol 3547, Finland, pp. 487-501.

Bibliographie

212

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 caractérisation des connaissances »,

manuscrit présenté 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, n°2, pp. 239-270.

194. Tsoukas H. & Chia R. (2002), « On organizational becoming : Rethinking organizational change », Organization Science, vol 13, n°5, 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, n°3, 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, n°2, 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, n°4, 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, n°3, pp. 425-478.

202. Vickoff J.P. (2008), « Agile : controverses et réflexions » (www.Entreprise-Agile.com).

203. Vidaillet B. (2003), Comment l’envie déclenche des processus de sensemaking dans les

organisations, in Les défis du sensemaking en entreprise: Karl Weick et les sciences de

gestion, Autissier D. & Bensebaa F. (2006), Economica.

204. Wacheux F. (1996), Méthodes 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, n°4, pp. 305-317.

Bibliographie

213

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, n°4, 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, n°5, pp.

731-735.

217. Whittington R. (2003), « The Work of Strategizing and Organizing: For a Practice

Perspective », Strategic Organization, vol 1, n°1, pp. 117-125.

218. Whittington R. (2006), « Completing the Practice Turn in Strategy Research »,

Organization, vol 27, n°5, pp. 613-634.

219. Williams L., Kessler R., Cunningham R.W. & Jeffries R. (2000), « Strengthening the

Case for Pair Programming », IEEE Software, vol 17, n°4, pp. 19-25.

220. Williams L. (2003), « The XP Programmer: The Few Minutes Programmer », IEEE

Software, vol 20, n°3, pp. 16-20.

221. Williams L. & Cockburn A. (2003), « Agile software development : it’s 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.

214

RRééfféérreenncceess wweebb

http://www.pmi.org/ (site dédié au management de projet).

http://agilemanifesto.org/ (site dédié au manifeste agile).

http://www.lean.enst.fr (site centré sur le lean management).

http://www.cheshirehenbury.com/agility/index.html (site centré particulièrement sur

l’agile manufacturing).

http://agilescout.com/top-agile-blogs-200/ (Site référençant les 200 meilleurs

blogs agiles).

http://leansi.wp.institut-telecom.fr/ (site centré sur le lean et les systèmes

d’information).

http://www.agilealliance.org/ (site dédié au développement agile).

http://institut-agile.fr/ (Site dédié à l’ensemble des pratiques

agiles).

http://www.ambysoft.com/ (site dédié aux best practices en

développement de logiciels).

http://martinfowler.com/agile.html (Site dédié au développement agile de

logiciels).

http://alistair.cockburn.us/ (Site dédié au développement agile de

logiciels).

http://scrumalliance.org/ (Site dédié au développement agile

avec une focalisation sur la méthode

scrum).

http://www.controlchaos.com (Site dédié principalement à la

méthode scrum).

http://xprogramming.com/index.php (Site dédié à la méthode extreme

programming).

http://www.rad.fr (Site dédié aux techniques de gestion

de projet, aux pratiques agiles et à la

méthode RAD).

http://www.pmi.org/

http://agilemanifesto.org/

http://www.lean.enst.fr/

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

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

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

http://www.agilealliance.org/

http://institut-agile.fr/

http://www.ambysoft.com/

http://martinfowler.com/agile.html

http://alistair.cockburn.us/

http://scrumalliance.org/

http://www.controlchaos.com/

http://xprogramming.com/index.php

http://www.rad.fr/

Annexes

215

AAnnnneexxee

I- Traduction du manifeste agile114

« Nous avons trouvé une voie améliorant le développement logiciel en réalisant ce travail et

en aidant les autres à le faire. De ce fait nous avons déduit 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 négociation du contrat

- L’ouverture au changement prime sur le suivi d’un plan

Autrement dit, même si il existe de la valeur dans les éléments de droite, nous accordons plus d’importance à ceux de gauche.

Nous respectons les principes suivants :

- Notre première priorité est de satisfaire le client en livrant tôt et régulièrement des

logiciels utiles. - Le changement est accepté, même tardivement dans le développement. Les processus

agiles exploitent le changement comme avantage compétitif pour le client.

- Livrer fréquemment une application fonctionnelle, toutes les deux semaines à deux mois,

avec une tendance pour la période la plus courte. - Les experts métier et les développeurs doivent collaborer quotidiennement au projet.

- Bâtir le projet autour de personnes motivées. Leur donner l'environnement et le soutien

dont elles ont besoin, et croire en leur capacité à faire le travail.

- La méthode 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 développement soutenable.

Commanditaires, développeurs et utilisateurs devraient pouvoir maintenir le rythme indéfiniment.

- Une attention continue à l'excellence technique et à la qualité de la conception améliore

l'agilité.

- La simplicité - l'art de maximiser la quantité de travail à ne pas faire - est essentielle. - Les meilleures architectures, spécifications et conceptions sont issues d'équipes qui

s'auto-organisent.

- À intervalle régulier, l'équipe réfléchit aux moyens de devenir plus efficace, puis accorde

et ajuste son comportement dans ce sens. ».

114(http://agilemanifesto.org/)

http://agilemanifesto.org/

Annexes

216

II- Glossaire des méthodes « agiles »

- A3 problem solving : Document basé sur un format A3 où sont capturées les informations

relatives aux problèmes apparus (conditions actuelles, objectifs attendus, analyse des causes,

contre-mesure, confirmation des résultats, suivi des actions).

- Andon : Signal ou tableau lumineux qui s'allume lorsque l'opérateur appuie sur un bouton

d'alerte ou tire sur un fil d'alarme.

- Burndown chart : C’est un graphe permettant de visualiser l’avancement des tâches

réalisées par l’équipe. Il comprend la quantité de travail restante dans une itération à travers le

temps de cette itération.

- Client sur le site : Le client est présent avec l’équipe de développement tout au long du

projet afin de répondre à ses questions, d’effectuer les tests d’acceptation et de s’assurer que le

développement se fait conformément à ses attentes.

- Daily Scrum : C’est une réunion quotidienne de 15 minutes concernant l’équipe « scrum ».

Durant cette réunion, chaque membre de l’équipe explique ce qu’il a fait depuis la dernière

réunion, ce qu’il va faire avant la prochaine réunion et expose les obstacles éventuels

rencontrés.

- Done : État d’une exigence ou d’une fonctionnalité lorsqu’elle est globalement acceptée par

toutes les parties prenantes et lorsqu’elle répond aux attentes du client : développée, testée,

documentée, validée et potentiellement mise en production.

- Équipe Scrum : Elle est constituée de quatre à dix personnes maximum. L’équipe Scrum

est responsable de la conversion des items du « product-backlog » en de sous-ensemble de

fonctionnalités livrables à la fin de chaque itération.

- Incrément : La ou les fonctionnalité(s) supplémentaire(s) développée(s) et livrée(s) par

l’équipe à chaque itération. C’est l’apport de valeur pour le client à chaque itération.

- Instant Messenger : La messagerie instantanée ou le dialogue en ligne permet l’échange

instantané de messages textuels entre plusieurs ordinateurs connectés.

- Intégration continue : Cette pratique vise à ce que le système, dans son intégralité, soit

régulièrement et fréquemment, assemblé puis testé. Il s’agit de l’intégration quotidienne de

nouveaux codes aux codes existants.

- Jira : C’est un outil collaboratif permettant d’assurer le suivi et la gestion du tableau des

tâches, des bugs, des demandes d’évolution, etc. Les demandes peuvent être affichées sous

forme de cartes virtuelles.

- Kaizen : Organisation des discussions en équipe pour stimuler l'amélioration continue.

L'objectif du kaizen est l'élimination du gaspillage sous toutes ses formes.

Annexes

217

- Kanban : Des systèmes d’étiquettes ayant pour objectif d’envoyer une indication aux unités

de production en amont de la chaîne 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 s’agit 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 problème une fois pour toutes). C’est une méthode fondamentale de

résolution de problèmes dans le lean management.

- Management visuel : Mise en place de moyens physiques pour créer un environnement

informatif.

- Modèle de tests intégrés : Il s’agit d’un outil open-source qui automatise les tests

fonctionnels des clients. Il intègre le travail des analystes, des clients, des testeurs et des

développeurs.

- 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 problèmes et de

trouver, en fonction de leur fréquence d’apparition, celles à traiter en priorité. Cet outil obéit à

la loi 20/80 où 20% des causes produisent 80% des effets.

- Planning-Game : Il s’agit d’une réunion effectuée au début de chaque itération où les

demandes des clients sont produites sous formes de « user-stories » notés sur des « story-

cards ». Dans ce type de réunion, le client détermine les demandes fonctionnelles à

implémenter, les programmeurs estiment le temps nécessaire pour l’implémentation de

chacune des story-cards et ensemble ils décident des « story-cards » à retenir pour la prochaine

itération.

- Poka-Yoke : Il s’agit de petits systèmes pratiques qui permettent d’identifier

immédiatement 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 partagés d’une manière collective. Les

développeurs ont le droit d’apporter des modifications aux codes à n’importe quelle occasion.

- Post-sprint Meeting : A la fin de chaque itération, l’équipe est censée présenter son travail

au « product-owner ». A ce stade, le « product-owner » s’assure par rapport au contenu du

« sprint-backlog » le travail effectué par l’équipe.

- Product Backlog : C’est un document d’analyse détaillé qui liste l’ensemble des

fonctionnalités à implémenter. Les items notés sur le « product-backlog » peuvent contenir les

critères, les fonctionnalités, la fixation des bugs, les défauts, etc.

- Product-Owner : Le propriétaire de produit ou le « product-owner » est l’unique personne

responsable de la gestion du « product-backlog ». Il communique la vision du produit à

l’équipe de développement et détermine les caractéristiques du produit et fixe sa date de

lancement.

Annexes

218

- Programmation en paire : La production de code se fait en binôme à partir de deux

personnes travaillant ensemble sur une seule machine, un clavier et une souris. La rotation des

paires se fait de manière quotidienne.

- Pull system : Une entreprise lean agit en flux tiré où le client devient demandeur et donc la

production est tirée suite aux besoins exprimés par le client.

- QQOQCP : (pour Qui fait Quoi ?, Où ? Quand ? Comment ? Combien ? et Pourquoi ?). Il

s’agit d’une méthode qui consiste à collecter les données nécessaires pour rendre compte et

analyser une situation ou un problème.

- Réunion pré-sprint : Il s’agit d’une réunion de planification de livrable permettant de

répartir les items du « product-backlog » sur différentes itérations, d’estimer les coûts, le

budget et la date de livraison du produit.

- Retrospective meeting : Après la réunion « post-sprint », l’équipe et le « scrum-master » se

réunissent pour faire un travail rétrospectif sur le déroulement de la réunion post-sprint et le

sprint en général. Au cours de cette réunion, l’équipe évoque ce qui s’est bien passé, souligne

ce qui s’est mal passé ainsi que les améliorations à faire dans les prochaines itérations.

- Scrum-master : Il fait le relais entre le « product-owner » et l’équipe « scrum ». Il ne gère

pas l’équipe mais aide celle-ci à affronter les problèmes et à atteindre les objectifs fixés pour

l’itération en cours.

- Sept gaspillages : Trop de fonctionnalités, Retards, Transfert, Réapprentissage/

reprogrammation ; Travail partiellement fait ; Déplacement/ changement de tâches ; Défauts

non détectés par les tests.

- Sprint : Il s’agit de l’itération pendant laquelle l’équipe Scrum s’auto-organise pour

produire, dans une durée 30 jours, un nouvel incrément. Les itérations ont lieu de manière

consécutive sans aucune interruption.

- Sprint Backlog : C’est le point de départ de chaque itération. Le « sprint-backlog » contient

la liste des taches à réaliser dans la prochaine itération afin de convertir les items du « product

backlog » en un incrément livrable.

- Sprint Planning Meeting : C’est une réunion composée d’une double phase. Lors d’une

première phase, les clients, les utilisateurs, le management et l’équipe décident collectivement

de l’objectif du prochain sprint et des fonctionnalités à implémenter. Et dans une seconde

phase, le Scrum-Master et l’équipe se réunissent pour se focaliser sur la manière dont

l’incrément sera implémenté.

- Stand-up meeting : C’est une réunion quotidienne de 15 minutes, se déroulant dans

l’espace occupé par les développeurs. L’objectif est que ces derniers partagent leurs

expériences de la journée précédente et décident collectivement des taches à effectuer pour la

journée.

- Story-cards : Ils représentent des cartes sur lesquelles sont marquées les « histoires

utilisateurs » ou les « user-stories ».

- Tableau blanc ou « whiteboard » : Logiciel permettant aux utilisateurs distribués de

collaborer en temps réel et de partager leurs fichiers, graphes, etc.

Annexes

219

- Test Driven development : La démarche d’écriture de codes commence par l’écriture des

tests qui permettront de tester les fonctions à implémenter puis de mettre en place ces fonctions

« pas à pas » en vérifiant toujours que les tests écrits pour la fonctionnalité implémentée

« passent ».

- Tests unitaires : Les tests sont écrits pour chaque classe ou portion de codes avant de

commencer à coder. Ces tests sont réalisés à chaque intégration.

- Timeboxing : Principe consistant à définir une échéance fixe pour développer et livrer un

ensemble de fonctionnalités. Si le travail planifié n’est pas achevé, on ne décale pas la date de

fin, 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 pièces jointes. Localisé dans l’intranet, cet outil est sécurisant et

efficace pour communiquer les différents aspects du projet (use-cases, daily program status,

burndown charts, etc.).

- User-stories : Il s’agit des demandes fonctionnelles et des besoins des utilisateurs

généralement écrits par les utilisateurs ou le client.

- Vélocité : La vélocité renvoie au nombre de scénarios que l’équipe estime être capable de

réaliser durant une itération. Elle peut être déterminée à partir de l’expérience de l’équipe sur le

sujet, des projets antérieurs, etc.

- XPlanner : C’est est un outil de planification et de traçabilité pour les équipes « XP ».

Annexes

220

III- Les modèles RAD et DSDM

-Le modèle RAD (Rapid Application Development)

-Le modèle DSDM (Dynamic System Development Methodology)

N fois

CCoonncceeppttiioonn eett ccoonnssttrruuccttiioonn

MMiissee eenn œœuuvvrree

N fois

ÉÉttuuddee ddee ffaaiissaabbiilliittéé

ÉÉttuuddee ddee mmééttiieerr

MMooddéélliissaattiioonn ffoonnccttiioonnnneellllee

IInniittiiaalliissaattiioonn

EExxpprreessssiioonn ddeess bbeessooiinnss

CCoonncceeppttiioonn

N fois CCoonnssttrruuccttiioonn

MMiissee eenn œœuuvvrree

Annexes

221

IV- Outils de gestion de projet « agile »

-Exemple de product-backlog et de sprint-backlog

-Exemple d’un burndown chart

Annexes

222

V- Outils de gestion de projet « agile »

-Exemple d’un « story-board115 »

115(Kniberg, 2007)

Annexes

223

VI- Outils116 mobilisés par l’équipe « lean »

-Tableau blanc dans un environnement de travail

116Ces outils ont été mobilisés par l’équipe « lean » lors des ateliers et les réunions organisés avec les équipes

pilotes.

Annexes

224

VII- Outils mobilisés par l’équipe « lean »

-Le management visuel

Annexes

225

VIII- Outil mobilisé par l’équipe « lean »

-Tableau comparatif d’un « brief » et d’une réunion d’équipe

Daily brief Réunions d’équipes

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 résout pas) les problèmes, qualifie et

quantifie les secteurs de problèmes et pose le

niveau de responsabilité de résolution de

problème.

Objectifs : relectures des anciens comptes

rendus, relecture approfondie des zones à

risques, cela peut inclure les résolutions de

problèmes, la découverte des façons de soulever des barrages. On peut demander l’intervention

également des invités et des experts sur le sujet,

si exigé.

Durée : idéalement 15 minutes, pas plus que 30

minutes.

Fréquence : idéalement au quotidien, briefs à

distance : chaque semaine à une date bien définie.

Fréquence : 1 à 2 fois par semaine, heure fixée,

plus si besoin.

Comment procéder : les sessions sont fixées en

prenant soin d’indiquer le prochain brief.

Le manager de l‘équipe est responsable de conduire

le brief de bout en bout, de garder les membres en

piste afin de ne pas passer à côté des 5 Points

essentiels du lean tout en se concentrant sur la

performance.

Le team manager met en scène 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 durée des briefs, les interactions sont restreintes entre les membres de

l'équipe, pas d'invitations extérieures.

Comment procéder : Les participations

extérieures sont acceptées par avance.

Le manageur donne à tout monde la parole.

La réunion d’équipe couvre la vue globale du

travail.

La réunion résout les problèmes 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

affichées sur un tableau blanc. Celui-ci a une double

fonction : En plus d’assurer le suivi du brief, il permet

aux absents de vite rattraper leur retard. Il peut être mis sur une base de données.

Durée : généralement une heure au minimum.

Annexes

226

IX– Outils mobilisé par l’équipe « lean »

-La démarche d’amélioration continue : kaizen /PDCA

Annexes

227

X- Lettre d’information bimensuelle117

117Le format de la présente lettre d’information a été modifié de sa version originale. Nous avons également

supprimé les noms des personnes pour des raisons de confidentialité.

LeannerShip

Concept-Lean à suivre : On se pose la question «Pourquoi ?» 5 fois de suite pour être sûr de remonter à la cause racine.

VocabuLean Voix du Client : La VOC est utilisée pour décrire les attentes des clients ainsi que la valeur qu'ils perçoivent du produit ou service concerné.

Coaching : accompagnement d'une personne à partir de ses besoins professionnels pour le développement de son potentiel et de son savoir-faire.

Atelier Kaizen : identification et résolution des dysfonctionnements.

QQOQCP : Le « Qui, Quoi, Où, Quand, Comment, Pourquoi ? » est un outil de clarification des dysfonctionnements.

Briefs : Courte réunion contenant des actions managériales centrées sur le fonctionnement de l’équipe projet et non sur le projet lui même. Management Visuel : Partager les dysfonctionnements et solutions d’amélioration sur un support commun visible de tous.

Le Leanner de la semaine Volontaire ... Je me retrouve désigné 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'ingère 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 collègues de ne pas clôturer tel que cette formation. Les pr incipes de base sont alors transcrits dans quelques slides, une dizaine, et le bon sens de chacun fera le reste. Pilotés par un planning serré, nous lançons donc la première étape rapidement, et chacun d'entre nous anime un atelier de remontée de dysfonctionnements. Pour celui me concernant, les remontées sont nombreuses : la difficulté est d'arriver à recentrer les discussions sur l' identification des dysfonctionnements, sans tenter de résoudre, sans tourner en rond. En plus, je suis contraints par le temps, les réunions s'enchainent, et je dois donc clôturer de manière un peu abrupte la séance : toutes mes excuses aux participants ... La suite est en cours, et j'espère que cette lettre vous apportera régulièrement le bon niveau d' information. Ce que je retiens de cette première étape : le Lean, au delà de la méthode, doit nous donner les moyens d'améliorer notre fonctionnement au quotidien, de manière pragmatique, sans attendre que l'organisation, la hiérarchie, les

autres, ... le fassent pour nous. Saisissons cette opportunité, restons pragmatique et peut être que les résultats seront au rendez vous. Cela reste à prouver, certes, mais avec notre participation, et un soutien sur la durée de notre hiérarchie, pourquoi pas ...

La Newsletter bimensuelle sur le Lean Management

AA llaa uunnee

Mais au fait, c’est

quoi le lean

Management?

« Il s'agit du système de production développé par Toyota qui recherche la

rationalisation optimale de l'ensemble du système à travers l'élimination des "gaspillages" et vise à établir la recherche de la

qualité comme un élément intrinsèque au système de production tout en instituant le principe de réduction des coûts. Il comprend

également les accompagnements technologiques nécessaires pour atteindre ces buts »

Taichii Ohno

AAvvaanncceemmeenntt ddeess ttrraavvaauuxx

Actions réalisées :

1) Lancement du projet le 18 juin : élaboration de nos objectifs : devenir plus agiles avec des moyens constants, devenir

meilleurs sur les délais, améliorer la transparence, faire plus court. 2) Phase de préparation pendant juillet aout : Formation de l’équipe projet.

La démarche retenue a été de privilégier le travail en atelier.

3) Cette démarche consiste dans 1er temps à identifier et quantifier les dysfonctionnements. Nous avons donc organisé 4 ateliers orientés Projet (FTTH, R2 ZE, R3 PC, R3 ZNE), 3 orientés Métiers (architectes, Che f de projet, CPM) et 5 interviews réalisés. Votre active participation a permis de remonter 98 dysfonctionnements parmi lesquels 8 ont été retenus pour être traités pendant la phase pilote.

4) Consolidation des résultats avec le CODIR. Démarche retenue :

1 axe métier : atelier de recherche des causes racines et d'identification d'action de résolution. 1 axe projet : déploiement des méthodes de management par le Lean sur les 4 projets cités 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 démarche Lean à Nextv, une heure, par coopnet (les dates seront communiquées prochainement).

L’équipe chargée du Lean management au sein de l’entité Nextv

- TR, Responsable Qualité Nextv, Directeur du projet Lean Management, - JP, Responsable du pôle HPM Pays, - RB, Senior Performance Manager à la direction de la transformation, - DT, Responsable CPM IPTV, - DT, Project Manager Easy TV.

- QR, Apprenti de l’ITIN. -Carine Khalil, Doctorante Lean management à Télécom Paris Tech.

Mise en œuvre de la démarche lean management

Annexes

228

XI- Document de synthèse

-Réunion de l’équipe « lean »

Date: 13/10/09 ;

Durée : 10h:00-12h30

Lieu : Paris

Nom du document: Réunion de l’équipe « lean »

Objectifs de l’atelier: Construction des outils de la démarche « lean » (réunions quotidiennes, KPI)

Participants : RB, TR, DM, JP.

Principaux éléments remontés lors de cette réunion

- Questionnements par rapport au « kit » à proposer aux chefs de projet : comment lui

expliquer la démarche, que doit contenir ce « kit » ?

- Nécessité d’avoir une proposition « préconstruite » des outils avant de partir voir le chef

de projet ;

- Faire une proposition au chef de projet sur laquelle il pourra réagir ;

- Préoccupations : comment expliquer la finalité d’une réunion quotidienne ; comment

différencier une réunion quotidienne d’une réunion d’équipe ? ; quels outils visuels lui

mettre à sa disposition ?

- Recourir à la présentation des managers d’« OS » qui ont mis en place des réunions

quotidiennes au niveau de leurs équipes distribuées (contexte qui semble être similaire à

celui de Nextv).

- Comment motiver les acteurs de Nextv à participer aux réunions quotidiennes alors

qu’aux réunions « normales » ils ont tendance de ne pas venir ?

- Comment rendre les acteurs plus concernés par les interactions ?

Impressions générales

- Les acteurs « lean » ne semblent pas être à l’aise avec les outils « agiles » à mettre en

place ;

- Ils mettent l’accent sur les problèmes de communication entre les équipes ou la

transmission tardive d’informations.

- Ils essayent de « construire » ces outils à travers leur partage d’idées, d’expériences.

- Les propositions de (RB) semblent prédominer.

Annexes

229

XII- Document de synthèse

-Atelier de remontées de dysfonctionnements

Date: 10/09/09 ;

Durée : 09h:30-12h30

Lieu : Paris

Nom du document: Ateliers de remontées des dysfonctionnements (n°2)

Objectifs de l’atelier: Identifier et analyser les problèmes rencontrés par les acteurs dans le déroulement de leurs projets

Atelier animé par: RB et TR

Participants : 5 Chefs de projets

Synthèse brève du contenu

- Manque de communication entre les différents membres de l’équipe (MOE, Marketing,

Architectes, R&D, etc.) ;

- Mauvaise synchronisation au niveau du planning ;

- Décalage d'un projet entraînant le décalage d’autres projets particulièrement en phase de

qualification ;

- Changements de priorité, absence de stratégies bien définies de priorisation de projets ;

- Phase d’étude très longue ;

- Travail supplémentaire induit par les changements de priorité,

- Absence de vision globale sur le projet

- Changements fréquents des demandes des clients, modification du périmètre.

Première impression

- Les chefs de projets semblent être insatisfaits à l’égard de leur collaboration avec le reste

des équipes ;

- Un réel manque de communication entre les personnes impliquées dans un projet

- Les modes de conduite de projet ne semblent pas très efficaces ;

- Beaucoup de gaspillages.

Annexes

230

XIII- Guide d’entretien (n°1)

-Directeur de l’équipe « lean »

Thème (1) : Organisation et cycle de vie des projets

Question 1 : Dans quel type d’organisation évoluez-vous ? (bureaucratique avec beaucoup

de procédures ; 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 décrire le cycle de vie des projets pilotés par Nextv?

Question 4 : Le cycle de vie « séquentiel » est-il commun à tous les projets pilotés par

(DPS) ?

Question 5 : Les livrables de chaque jalon sont-ils standardisés?

Question 6 : Comment les équipes projets pilotées par Nextv sont-elles constituées ?

Question 7 : Par qui le client « donneur d’ordre » est généralement représenté?

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

participation est-elle suffisante ?

Question 9 : Les entités transverses ont-elles chacune un mode de fonctionnement

propre ?

Thème (2) : Le lancement de la démarche « lean »

Question 1 : Quelles sont vos attentes vis-à-vis de la démarche « lean »?

Question 2 : Considérez-vous ce projet comme une opportunité ou un changement

supplémentaire similaire aux changements précédents ?

Question 3 : Quelle est le rôle de la direction générale dans la mise en place de la

démarche « lean »?

Question 4 : Quels sont les moyens attribués par la direction générale ? (formation, plan

d’accompagnement)

Question 5 : Mise à part le lancement du projet qui a eu lieu en Juin 2009, la direction a-t-

elle prévue de communiquer davantage sur la démarche ?

Question 6 : Pourquoi avoir décidé de réduire le nombre des dysfonctionnements à

traiter ?

Annexes

231

Question 7 : Pourquoi le recours aux réunions quotidiennes, au management visuel et aux

ateliers kaizen ?

Question 8 : Pourquoi avez-vous procédez par atelier ?

Annexes

232

XIV- Guide d’entretien (n°2)

-Directeur de l’équipe « lean »

Thème (1) : Raisons de la démarche « lean »

Question 1 : Quelles ont été les raisons qui ont poussé le directeur général à mettre en

place la démarche « lean »?

Question 2 : Selon vous, pourquoi le « lean » précisément et non pas une autre démarche?

Question 3 : Avez-vous suivi des formations sur lean management et les méthodes

« agiles » ?

Question 4 : Quelles ont été vos premières impressions à l’égard de l’applicabilité des

outils associés aux méthodes « agiles » et au développement lean ?

Question 5 : Comment les membres de l’équipe « lean » ont-ils été choisis ?

Question 6 : Avez-vous volontairement décidé de participer à cette démarche ? Si oui,

pourquoi ?

Thème (2) : Mise en place de la démarche « lean »

Question 1 : Quel est le rôle du Codir dans la mise en place de la démarche « lean » ?

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

Question 2 : Comment expliquez-vous le manque d’intérêt des managers d’équipes à

l’égard de la démarche ?

Question 3 : Quel est l’impact de ce manque d’intérêt sur la réussite du projet ?

Question 4 : Comment expliquez-vous le manque d’enthousiasme de certains chefs de

projet ?

Question 5 : Pourquoi le marketing n’a-t-il pas été impliqué dans la démarche ?

Question 6 : Quelles ont été les réactions de la direction générale 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 démarche

« fut très abstraite » ?

Annexes

233

Question 8 : Pourquoi les équipes projets n’ont finalement pas été concernées par la phase

de généralisation de la démarche?

Question 9 : A l’heure actuelle, quels ont été les outils généralisés sur les équipes de

Nextv? Et pourquoi ?

Annexes

234

XV- Guide d’entretien (n°3)

-Chefs de projet (Nextv) « lean »

Thème (1) : caractéristiques des équipes projets

Question 1 : Quelle est la taille moyenne d’une équipe projet ?

Question 2 : Comment les équipes sont-elles composées d’une manière générale?

Question 3 : Quelle est la durée approximative d’un projet mené à Nextv?

Question 4 : Cette durée est-elle respectée ? Si non, pourquoi ?

Question 5 : Les équipes sont-elles réparties géographiquement ? Si oui, comment

communiquent-elles?

Question 6 : Les équipes sont-elles familiarisées avec une méthodologie de conduite de

projet bien précise ?

Question 7 : Les membres des équipes projets sont-ils surchargés ? Si oui, quelles sont les

causes principales de cette surcharge de travail ?

Thème (2) : Gestion de projet

Question 1 : Quel est votre rôle au sein des projets ?

Question 2 : La vision des projets est-elle clairement définie ? Si non, Pourquoi ?

Question 3 : Combien de réunions/semaine sont organisées avec les équipes projets ?

Selon vous, cette fréquence est-elle suffisante ?

Question 4 : Quels sont les sujets abordés au cours de ces réunions ?

Question 5 : Faites-vous des reporting après ces réunions ? A qui sont-ils adressés ?

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 système de capitalisation sur les projets (erreurs, problèmes,

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

Question 9 : Les retours sur les phases antérieures d’un projet sont-ils envisageables ?

Annexes

235

Thème (3) : Gaspillages

Question 1 : À quels types de problèmes organisationnels et/ou managériaux êtes-vous

habituellement confrontés ?

Question 2 : Vous arrive-t-il souvent de réaliser des tâches inutiles ou déjà effectuées ?

Auriez-vous des exemples précis à nous donner ?

Question 3 : Existe-t-il des chevauchements au niveau des différentes phases d’un projet

(équipes qui attendent d’autres équipes, etc.) ? Si oui, comment l’expliquez-

vous ? Quelles en sont les conséquences ?

Thème (4) : Démarche « lean »

Question 1 : Avez-vous déjà entendu parler des méthodes « agiles » et du lean

management ?

Question 2 : Que pensez-vous de la démarche « lean » proposée ? Comment pourrait-elle

vous aider ?

Question 3 : Comment envisagez-vous la mise en œuvre des réunions quotidiennes, du

management visuel et des ateliers kaizen proposée par l’équipe « lean » ?

Annexes

236

XVI- Guide d’entretien (n°4)

-Acteurs internes/acteurs hors Nextv

Thème (1) : Pratiques « agiles »

Question 1 : Avez-vous mis en place des réunions quotidiennes ? Si oui, quelles sont les raisons principales ayant motivé leur mise en place ?

Question 2 Les réunions quotidiennes se font-elles quotidiennement ? Leur durée de (15

min) est-elle respectée ? Si non, pourquoi ?

Question 3 : Durant ces réunions avez-vous recours à un tableau blanc ? Si oui, en quoi cela vous aide-t-il ?

Question 4 : Quels acteurs étaient concernés par ces réunions ?

Question 5 : Les participants sont-ils toujours connectés ? Si non, comment expliquez-

vous cela ?

Question 6 : Quelles sont les problèmes majeurs que vous rencontrez ?

Question 7 : A quel(s) type(s) de problème(s) ces réunions permettent-elles de répondre ?

Question 8 : La mise en place des réunions suffit-elle à améliorer la communication au

sein de votre équipe ?

Question 9 : Comment faire participer davantage les équipes à ces réunions ?

Question 10 : Quelles autre(s) pratique(s) « agiles » avez-vous intégré dans votre mode de fonctionnement ?

Question 11 : Comment percevez-vous la collaboration inter-équipes au sein de la direction DPS ?

Thème (2) : Les sessions kaizen

Question 1 : Avez-vous mis en place des sessions kaizen ? Si oui, à quelle fréquence et

avec quels profils d’acteurs ?

Question 2 : Quel est l’utilité de ces ateliers ?

Question 3 : Comment les sessions kaizen pourraient-elles être plus bénéfiques ?

Question 4 : Êtes-vous impliqués dans des plans d’action ? Si oui, dans quel(s) plan(s)

d’action ? Où en êtes-vous quant à leur mise en œuvre ?

Annexes

237

Thème (3) : Démarche « lean » en général

Question 1 : Quelles sont les difficultés rencontrées par rapport aux outils de la démarche

« lean » retenus ?

Question 2 : Quelles sont vos préconisations pour l’année 2011 ?

Annexes

238

XVII- Séminaires « Lean et Système d’Information »

Sur la période allant de Septembre 2008 à Octobre 2011, 19 interventions ont été

réalisées, avec succès, dans le cadre de cycles de séminaires sur le « Lean et Système

d’Information ». Le public de ces séances est constitué de professionnels des Systèmes

d’Information, de praticiens du lean et des méthodes « agiles », de consultants,

d’informaticiens, de responsables de qualité, etc. Le nombre de participants à chaque

séminaire s’est élevé à 80 personnes en moyenne. Nous listons ci-après les différents

séminaires en soulignant les thèmes traités, le nom des intervenants et le titre de leurs

présentations.

La liste des sept séminaires « lean et système d’information »

Le premier séminaire « Lean et SI » s’est tenu le 17 Novembre 2008 et a donné lieu à 4

présentations :

- « Lean Software Development », Alexandre Boutin, Yahoo ;

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

- « Lean Management et Systèmes d’information », Thomas Houy, Télécom Paristech ;

- « Le développement Logiciel Agile », Régis Médina, Operae Partners.

Cette première séance était très généraliste et marquait l’ouverture de la communauté.

Le deuxième séminaire « Lean et SI » s’est déroulé le 19 Mars 2009 au cours duquel trois

interventions ont été programmées et réalisées :

- « 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;

- « Améliorer le travail d’équipe: Les Core Protocols », Régis Médina et Antoine Contal,

Operae Partners.

Ce séminaire a été consacré à l’amélioration des projets informatiques à travers l’application

des pratiques lean.

http://ses.telecom-paristech.fr/LEANSI/2008-11%20LeanSI%20%2030%20min%20-%20Yahoo.pdf

http://leansi.blog.telecom-paristech.fr/files/2009/10/lean-et-SI-17-novembre.pdf

http://ses.telecom-paristech.fr/LEANSI/xp_leansi_20081117.pdf

http://leansi.blog.telecom-paristech.fr/files/2009/09/19-mars-2009-Kaizen-Station-Service-V1.pdf

http://ses.telecom-paristech.fr/LEANSI/TelecomParis-NSN-VSM-PBS-Story.pps

http://leansi.blog.telecom-paristech.fr/files/2009/09/doc3.pdf

Annexes

239

Le troisième séminaire « Lean et SI » a eu lieu le 25 Juin 2009 et a fait l’objet de trois

présentations :

- « Gérer l'amélioration continue en informatique au travers des A3 PSA et Faurecia »,

Catherine Chabiron, Faurecia ;

- « Le Lean dans le développement de la webtv chez Orange », Régis Médina et Antoine

Contal, Operae Partners ;

- « Enquête Lean et systèmes d'information 2009 réalisée par Fujitsu et Novamétrie avec le

soutien du Projet Lean Entreprise », Christophe Excoffier.

Lors de ce séminaire, nous avons donné la parole à des praticiens ayant mis en place une

démarche lean au sein de leurs activités de développement

Le quatrième séminaire « Lean et SI » s’est tenu le 11 Janvier 2010. Lors de ce séminaire,

deux interventions ont eu lieu :

- « Qu'est-ce que le gaspillage dans le développement informatique, plus particulièrement

dans le code? », Régis Médina, Operae Partners ;

- « La production informatique », Hugo Heitz, BNP Parisbas.

Ce séminaire s’est focalisé sur la notion de gaspillage dans le développement informatique et

sur lean pour améliorer la production informatique.

Le cinquième séminaire « Lean et SI » s’est déroulé le 10 Juin 2010. Le programme était le

suivant :

- « Des logiciels au service du client », Régis Médina, Operae Partners ;

- « Mise en œuvre des démarches agiles et lean pour la construction des systèmes

critiques », Emmanuel Chenu ;

- « Retour d'expérience sur une démarche de formation itérative selon les principes du

TWI », Marie-Noelle Ninteya et Elodie Aidan, Nokia Siemens Network.

Lors de ce séminaire, les interventions ont été variées : une intervention sur la « création de

valeur » pour le client, un retour d’expériences sur l’introduction du lean et de l’agilité au sein

d’une équipe de développement chez Thalès et un retour d’expérience sur une approche de

mise en œuvre de formation sur le terrain.

http://leansi.blog.telecom-paristech.fr/files/2009/09/doc3.pdf

http://ses.telecom-paristech.fr/LEANSI/20090625_leansi_webtv.pdf

http://leansi.blog.telecom-paristech.fr/files/2009/09/Synth%C3%A8se-26-juin-2009.pdf

http://leansi.blog.telecom-paristech.fr/files/2009/09/Synth%C3%A8se-26-juin-2009.pdf

Annexes

240

Le sixième séminaire « Lean et SI » s’est déroulé le 7 Octobre 2010. Trois présentations ont

été prévues pour ce jour :

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

- « Le lean dans la maintenance du SI », Régis Medina, Operae Partners ;

- « La Démarche Lean IT chez Silca », Hervé Deniel, Responsable du contrôle

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

Ce séminaire a été consacré à la gestion des incidents et à la maintenance des systèmes

informatiques.

Enfin le septième « Lean et SI » a eu lieu 23 septembre 2011. Cette séance a donné lieu à trois

présentations :

- « Standards de travail et amélioration continue : exemples de transposition de l'approche

usine sur les SI », Catherine Chabiron, Faurecia ;

- « Maîtriser les délais des projets informatiques », Régis Médina, Operae Partner ;

- « Quand les équipes agiles découvrent le A3 », Antoine Berthelin, 4DConcept et Philippe

Blayo, Orange Business Services.

http://leansi.wp.institut-telecom.fr/files/2010/10/2010_10_07-Lean-et-SI-Mise-en-flux-continu-des-incidents-informatiques_version-pdf.pdf

http://leansi.wp.institut-telecom.fr/files/2010/10/rex_maintenance_si_leansi_20100610.pdf

http://leansi.wp.institut-telecom.fr/files/2010/10/SILCA_PACTE_Institut-Lean-France-20101007.pdf

Documents

Les méthodes ''agiles'' de management de projets