2020UPSLD010
2020UPSLD010
2020UPSLD010
3
4
Remerciements
Cette compilation de brefs messages est à l’attention de ceux qui ont, d’une façon ou
d’une autre, parfois sans en avoir conscience, contribué à cette thèse.
Mes premiers et mes plus chaleureux remerciements vont à la fois à mon responsable
entreprise, Dominique Causse, et à mon directeur de thèse, Sébastien Tran. En tant
qu’encadrant entreprise, Dominique a fortement contribué à développer ma maturité
professionnelle et n’a cessé d’être source de conseils et d’orientations au cours des
travaux. Merci pour tous ces échanges, ta bienveillance et toute l’énergie qui tu as
consacré à mon égard. Sébastien m’a fait preuve très tôt se son assurance en tant que
directeur de thèse. Par sa réactivité unique, j'aimerais également lui dire à quel point j’ai
apprécié sa grande disponibilité et son implication au cours des travaux. J’ai été
extrêmement sensible à ses qualités humaines d'écoute et de compréhension tout au long
de ce travail doctoral.
Loin d’être un travail solitaire, je n'aurais jamais pu réaliser ce travail doctoral sans le
soutien d'un grand nombre de personnes dont la générosité, la bonne humeur et l'intérêt
manifestés à l'égard de ma recherche m'ont permis de progresser. À mes collègues de
5
l’équipe du Management-Lab je vous adresse de chaleureux remerciements. Merci
particulièrement à Albert pour ces éclairages qui ont été une vraie source d’inspiration et
de maturation de ma pensée, à Sébastien pour ta bienveillance et ton écoute ; Mustapha
pour ta bonne humeur prégnante ; Emilie pour ton soutien infaillible ; Pierre-Emmanuel
pour ta confiance accordée afin de donner mes premiers cours. Merci à Béatrice, Odile,
Doudja et Sonia pour vos avis éclairés et l’enthousiasme dont vous avez fiait preuve à
l’égard de mes travaux. Merci aussi à Françoise qui n’a cessé de faciliter toutes mes
démarches. J’ai aussi eu le plaisir de créer une vraie amitié avec les doctorants de l’équipe
Mlab. Merci à Iris, Alix, Stanislas, Ouiame pour ces moments partagés.
À l’achèvement du long travail qu’a nécessité cette thèse, je pense fortement à mon
père, qui nous a quittés trop tôt pour voir son petit dernier terminer ses études. À ma
mère pour son amour qui a accepté le déchirement de notre séparation pour ma réussite.
Mes chers parents je vous suis profondément reconnaissant pour tout ce que vous m’avez
inculqué, ce travail vous est totalement dédié. Je pense aussi fortement à mes frères et
sœurs, je vous adresse toute ma reconnaissance pour vos encouragements dans toutes les
étapes de mes études. Je pense particulièrement à Ouiza qui a grandement contribué à
m’affirmer, à Malik qui n’a cessé de m’encourager, à Kamal et Ismaël qui m’ont transmis
la valeur et la passion dans le travail, à Morade et Karim qui m’ont soutenu sans
cesse. J’adresse une chaleureuse pensée à ma belle maman dont la présence m’a permis
sereinement de terminer ce travail de thèse. À mes fidèles amis, Saïd, Fayssal, merci pour
votre soutien, votre joie et tous ces éclats de rire.
Enfin, à mon épouse, je dois plus que les mots ne peuvent dire. Linda, toi qui m’as tant
soutenu au cours de cette aventure, qui a su supporter ce quotidien fait de stress. Tu n’as
cessé de m’encourager, de m’écouter et de me réconforter, je t’en suis infiniment
reconnaissant. La fin des travaux s’est illustrée par l’arrivée de notre petit garçon, Adam,
qui éclaire notre vie depuis maintenant 3 mois. Ce travail se termine pour me consacrer
pleinement à notre nouvelle vie de famille.
6
7
Sommaire
REMERCIEMENTS ........................................................................................................................................ 5
SOMMAIRE ................................................................................................................................................. 8
INTRODUCTION GENERALE ....................................................................................................................... 10
PARTIE 1 – DU DEVELOPPEMENT SAUVAGE AU MANAGEMENT DE PROJET AGILE : PRESENTATION DES
DIFFERENTS PARADIGMES DE CONCEPTION DES SI ........................................................................................ 24
INTRODUCTION DE LA PARTIE................................................................................................................... 25
CHAPITRE 1 – HISTORIQUE DES METHODES DE CONCEPTION DE LOGICIELS ............................................. 26
INTRODUCTION ............................................................................................................................................... 46
1. REVUE DES DIFFERENTES GENERATIONS DE METHODES AGILES ............................................................................... 47
2. MANAGEMENT DE PROJET ET AGILITE : VERS UN MEME CONTINUUM ? ................................................................... 73
INTRODUCTION ............................................................................................................................................... 84
1. L’ADOPTION DES METHODES DE PREMIERE GENERATION ................................................................................. 85
2. LE DEPLOIEMENT DES METHODES AGILES DANS LES ORGANISATIONS .................................................................. 98
1. ANALYSE PROCESSUELLE DE LA GENERALISATION DE SCRUM DANS LES DIFFERENTES DSI DE LA SOCIETE GENERALE ... 191
2. ANALYSE DE LA FIGURE D’ACTEURS NAISSANTE LIEE A LA GENERALISATION DES METHODES AGILES ......................... 252
8
INTRODUCTION ...................................................................................................................................... 267
9
Introduction générale
Contexte ................................................................................................................................................. 11
De la conception anarchique au développement agile .......................................................................... 13
La généralisation des méthodes agiles dans les grandes organisations ................................................ 15
Question de recherche et enjeux des travaux ........................................................................................ 16
Architecture de recherche ...................................................................................................................... 17
Organisation du document de thèse ...................................................................................................... 19
10
Contexte
La transformation digitale vécue par de nombreuses entreprises de nos jours fait
émerger de nouvelles problématiques dans les organisations. En abordant ce sujet tant
convoité dans les plans stratégiques d’entreprises de nombreux secteurs, il s’avère que
l’une des premières caractéristiques d’une organisation à être impactée par cette
évolution majeure réside dans les différentes composantes de son système d’information
(Mikalsen et al., 2018).
Les différents composants techniques d’un SI dépendent souvent d’un logiciel. Entre
les systèmes d’exploitation, les applications bureautiques ou les progiciels de gestion
intégrés, qu’ils soient prêts à l’emploi ou bien à élaborer, le choix ou la construction de ces
programmes est une facette majeure de la conception et du développement des SI. Les
directeurs des systèmes d’information sont ainsi confrontés à une multitude de
possibilités dans la manière d’envisager la mise en œuvre de logiciels d’entreprises. Le
choix est d’autant plus important puisque les logiciels sont des composants qui
conservent les connaissances opératoires de l’organisation et constituent un répertoire
de modèles pour l’action de l’entreprise (Reix et al., 2016).
Dès les années 1960, le débat autour du dysfonctionnement et des échecs constatés
dans les activités de conception des logiciels et des SI s’est installé dans les différentes
sphères académiques (Naur & Randell, 1968). Depuis l’introduction de l’informatique en
entreprise, force est de constater que les interactions avec de nombreux acteurs, la
planification de la conception sur plusieurs mois voire des années et les faibles techniques
de développement se sont révélées complexes à organiser dans les premiers projets
informatiques (Pinto & Mantel, 1990 ; Robey & Farrow, 1982).
Ce débat, toujours d’actualité, s’illustre par les défis rencontrés de nos jours par les
grandes entreprises dans la mise en œuvre de progiciels de gestion intégrés (Sweis,
Abuhussein, Jandali, Mashaleh, & Al-Debei, 2018). Le taux d’échec des projets, toujours
aussi décrié, nous conduit à aller chercher dans l’histoire de l’ingénierie logiciels et plus
largement des SI, les raisons expliquant l’émergence de ces difficultés. Nous tenterons en
parallèle d’exposer les différentes solutions proposées par les acteurs de la sphère tant
académique que professionnelle pour contrer les difficultés rencontrées dans la
conception des SI.
11
Si la complexité n’a cessé de gagner du terrain dans le développement des SI
d’entreprises, les possibilités techniques sont de plus en plus florissantes. On dénombre
par exemple de nos jours près de 8500 langages informatiques, quand en 1972, il en était
question de 172 (Jones, 2014). Les réseaux informatiques d’entreprises s’étendent en
comportant de plus en plus de terminaux connectés. Quant aux données, à l’aune des
nouvelles capacités de stockage et de traitements possibles, nous sommes entrés dans
l’aire d’une nouvelle révolution industrielle, dont le potentiel d’exploitations des données
permet d’instaurer de nouveaux niveaux de performance de l’entreprise. Cependant,
comment organiser le développement des SI face à ce rythme de développement des
technologies aussi élevé dans le contexte des grandes organisations ?
De nombreuses enquêtes sur les facteurs d'échecs des projets logiciels ont été mises en
œuvre pour rechercher comment améliorer la performance du développement des SI (Al-
Ahmad et al., 2009 ; Glass, 1994 ; The Standish Group, 2016). Les facteurs constatés lors
des premières enquêtes sur les défaillances de projets logiciels semblent être
sensiblement les mêmes que ceux rapportés dans les enquêtes plus récentes. Dès les
premières études sur le sujet Gotterer (1967) souligne que le manque de soutien de la
haute direction, le manque de développeurs compétents, l'évolution des langages, l'évolution
des exigences des utilisateurs et l'insuffisance de la gestion de projet étaient de mise. Cette
juxtaposition semble pourtant avoir peu évolué compte tenu des dernières études sur le
sujet. En effet, ces facteurs d’échecs sont très proches des analyses menées dans des
études récentes (Gauld, 2007 ; Hughes, Dwivedi, Rana, & Simintiras, 2016 ; Verner &
Abdullah, 2012). D’autre part, dans plusieurs cas de figure, les études contemporaines
font explicitement référence aux caractéristiques d'une méthodologie et d'une structure
de gestion de projet faiblement organisée.
Plus de 50 ans après les premières études portant sur les facteurs d’échecs des projets
SI, force est de constater que l’organisation de la conception des SI est toujours d’actualité.
Comme en témoigne l’échec du projet Louvoisa lancé par le ministère des armées en 1996
et arrêté en 2013, les effets d’une mauvaise organisation ont pu dans ce cas avoir des
conséquences dévastatrices avec des coûts faramineux.
a https://www.franceinter.fr/emissions/secrets-d-info/secrets-d-info-27-janvier-2018
12
L’organisation de la conception est donc sensible pour la recherche en systèmes
d’information au regard du taux important d’échecs révélés dans les différentes études.
Le sujet fait l'objet depuis les années 1970 de nombreux débats qui, nous allons le voir
ont conduit les praticiens et les acteurs académiques à identifier de nouvelles méthodes
de conception des systèmes d’information.
Le développement en cascade proposé par Royce (1970) est l’une des méthodes ayant
connu une forte notoriété dans la sphère des développeurs. Elle est fondée sur
l’anticipation des demandes des utilisateurs, la définition complète du futur produit et
une documentation exhaustive. La méthode a rapidement été critiquée pour sa
séquentialité dans l’organisation des phases de développement. Plusieurs études ont par
ailleurs mis en relation l’échec des projets en lien avec ce processus de conception
(Boehm, 1988 ; Ruparelia, 2010).
Les années 1990 ont par la suite connu l’émergence de nouvelles méthodes lancées par
des experts de la conception de logiciels (Highsmith, 2002 ; Schwaber, 1997). Leur
initiative avait entre autres pour objectif de contrer la « crise du développement de
logiciels » mise en lumière par la publication du Chaos Report en 1995. Qualifiées
« d’agiles », ces méthodes connaissent une notoriété considérable via la publication du
manifeste agile de développement de logiciels en 2001.
Les méthodes agiles ont été conçues pour répondre aux environnements logiciels
perturbés dont l’incertitude engendre des changements fréquents d’exigences. Le concept
d’échec est implicitement intégré dans le processus de développement qui se caractérise
par un cycle de conception itératif et incrémental rompant ainsi avec les séquences des
précédentes méthodes (Highsmith, 2002). Elles n’ont pas été créées dans le but premier
d’obtenir les bons livrables dans un projet : elles s’appuient plutôt sur la rétroaction des
utilisateurs pour apporter des modifications à chaque itération jusqu’à aboutir à la
solution idéale (Boehm, 2002).
Si les années 1990 ont été le théâtre de l’émergence de ces nouvelles approches, la suite
s’est accentuée puisque de nombreuses autres méthodologies ont été créées, laissant
place ainsi à différentes générations de méthodes agiles (Alqudah & Razali, 2016a ;
Dingsoeyr, Falessi, & Power, 2019). Les bénéfices constatés dans les projets ont été des
13
motifs pour étendre les méthodes agiles à de plus grands projets de conception des SI. Il
est maintenant possible de constater que les pratiques, principes et rituels ont été étendus
pour coordonner de grandes équipes. Cette seconde génération de méthode est qualifiée
« d’agilité à l’échelle » autant par les praticiens que par la sphère académique.
Au cours des 20 dernières années, les méthodes agiles ont été largement introduites
dans les organisations (Nerur & Moe, 2012). Le sujet a d’ailleurs fait l’objet d’études
foisonnantes dans la littérature en SI (Diegmann, Dreesen, Binzer, & Rosenkranz, 2018 ;
Dingsøyr, Nerur, Balijepally, & Moe, 2012). L'enthousiasme dans l’adoption de ces
approches provient notamment des bénéfices identifiés. Il est en effet constaté qu’elles
permettent d'apporter plus fréquemment de la valeur par rapport aux projets réalisés via
des approches « classiques », elles permettent de réduire les délais de développement, et
dans d'autres cas, une certaine amélioration dans la qualité du produit délivré est
constatée (Laantib et al., 2011).
Si les bénéfices ont principalement été constatés dans le développement des SI, les
méthodes agiles se sont diffusées au-delà des frontières du pur développement
informatique. Elles ont par exemple été mises en œuvre pour le développement d’avion
de chasse chez Saab (Bodén, 2016) et plus récemment, dans la construction de châssis
automobiles et d’outils chez Boschc.
Au-delà des bénéfices constatés, l’adoption des méthodes agiles est une question
importante pour les DSI de grandes organisations. L’adoption dans les équipes de
développement de logiciels s’est fortement accentuée depuis la sortie du manifeste agile.
Créées initialement pour des petites équipes de développement (Kruchten, 2004), de
nombreuses organisations ont éprouvé l’intérêt de les mettre en œuvre pour de plus
grands projets (Hobbs & Petit, 2017 ; Mathiassen & Pries-Heje, 2006). Ceci ayant conduit
à l’émergence des référentiels de mise à l’échelle des pratiques, rituels et cycles de conception
(Larman & Vodde 2015 ; Ambler 2012 ; Leffingwell 2015).
bDans ce contexte, nous utilisons le terme produit pour parler du développement de logiciels ou de
services Web.
c https://www.scrumatscale.com/wp-content/uploads/Annie-Howard-Bosch-Slides.pdf
14
La généralisation des méthodes agiles dans les grandes
organisations
Convaincues des apports qu’elles peuvent avoir sur le succès des projets, les grandes
entreprises ne sont plus dans l’introduction de ces méthodes au niveau de quelques
équipes, mais sont plutôt dans une phase de généralisation dans les projets. L’idée est de
potentiellement normaliser cette nouvelle forme de gestion de projet au niveau de ce qui
est communément appelé le portefeuille de projets (Stettina & Hörz, 2015). Or, comme
elles sont nées dans le développement de logiciels, c’est principalement au niveau des
projets touchant à la conception et au développement de SI qu’elles sont mises en place.
Au premier abord, ce sont donc les DSI qui s’emparent du sujet en expérimentant et en
formant les équipes techniques pour mettre en place une première méthode. Lorsque
cette expérimentation se traduit par un succès, dans bien des cas, l’agilité va gagner du
terrain et va être de plus en plus adoptée dans les projets SI. La question de leur
généralisation soulève de nombreuses interrogations pour les DSI. Comme en témoigne
l’appel du délégué général du Club informatique des grandes entreprises françaises
(CIGREF) auprès de la communauté des chercheurs français en SI en 2017. La tendance
n’est plus d’expérimenter ces méthodes, mais plutôt de les généraliser. Ce qui conduit à
de nombreuses interrogations : Comment faire ? Quelle démarche mettre en œuvre ?
Jusqu’à quel niveau de l’organisation ? La généralisation se limite-t-elle exclusivement aux
acteurs de la direction des systèmes d’information ? Les réponses sont d’autant plus
difficiles à trouver pour les praticiens que ces deux dernières décennies, les méthodes
agiles sont devenues très hétérogènes.
D’autre part, le fonctionnement entre la DSI et les différents départements métier peut
se révéler compliqué. Dans bien des cas, des difficultés de collaboration s’installent entre
les équipes de la DSI et les acteurs non techniques impliqués dans les projets. Ceci se
révèle être une contrainte au mode de fonctionnement prônée par les méthodes agiles. La
15
relation « client – fournisseur » entre les départements métiers et la DSI favorise une
perception des méthodes agiles comme des méthodes exclusivement informatiques.
Le second champ de recherche s’attache à expliquer la mise à l’échelle pour les grands
projets (Hobbs & Petit, 2016 ; Nerur & Moe, 2012). Les travaux analysent les pratiques et
rituels mis en place pour coordonner de plus grandes équipes. Le troisième champ
concerne l’expansion d’usage d’une méthode à tout un département. Il s’agit d’un champ
de recherche focalisé sur l’analyse de l’adoption généralisée d’une méthode à un ensemble
de projets d’une organisation. Ce champ est souvent dénommé par les termes
« transformation agile ». Or une revue de littérature menée par Dikert et al. (2017) met
en exergue le manque de recherche sur le sujet. Sur 52 études de cas analysés par les
auteurs, seulement six ont été menées par des acteurs de la communauté scientifique. La
plupart des articles sélectionnés étaient des rapports d'expérience publiés dans des
conférences de praticiens de l'agilité, ce qui montre d’une certaine manière leur intérêt
pour le sujet.
16
organisationnelles (Barroca, Dingsøyr, & Mikalsen, 2019 ; Dingsøyr et al., 2012 ; Mikalsen
et al., 2018).
Architecture de recherche
Définir un objet de recherche suppose de s’interroger sur les choix épistémologiques
et méthodologiques. Les travaux de cette thèse se sont déroulés dans le cadre d’une
convention CIFREd en collaboration avec le cabinet de conseil Daylight. L’objet de
recherche a donc été construit en collaboration avec les consultants et des partenaires de
recherche confrontés au manque d’information sur le sujet. Nous avons convenu avec
Daylight au début des travaux que la thèse devrait permettre :
• d’analyser les dispositifs mis en œuvre pour déployer les méthodes agiles dans
les projets ;
• d’identifier les facteurs clés influençant le déploiement des méthodes agiles dans
les DSI de grandes organisations ;
• d’identifier le rôle des différents acteurs impliqués dans la généralisation ;
• puis, les travaux doivent contribuer à illustrer les évolutions organisationnelles
induites au cours de la généralisation.
Sur le plan théorique, l’intérêt de nos travaux réside dans la clarification du phénomène
de transformation agile récemment évoqué dans la littérature. Ils permettent d’autre part
de répondre au faible nombre de recherches menées par la sphère académique en
proposant plusieurs études de cas sur le sujet (Dikert, Paasivaara, & Lassenius, 2016b ;
17
Barroca et al., 2019). D’autre part, en considérant les méthodes agiles comme des outils
de gestion, nous contribuons à favoriser la compréhension du processus d’adoption des
innovations managériales, en confrontant la vision linéaire développée par de nombreux
auteurs aux cycles récursifs identifiés dans les différents cas de cette thèse.
D’un point de vue méthodologique, nous avons opté pour des investigations basées sur
une stratégie de recherche qualitative. Ces méthodologies sont plus appropriées pour
rendre compte de façon détaillée de processus organisationnels complexes (Musca,
2006). Nous avons fait le choix de mener quatre études de cas dans une perspective
longitudinale. N’étant pas attachée à un paradigme épistémologique particulier, l’étude de
cas peut être utilisée pour comprendre, expliquer, tester ou générer une théorie
(Eisenhardt, 1989).
D’autre part, mener plusieurs cas permet d’accroître la généralisation des résultats en
se donnant la possibilité que les événements et processus observés ne soient pas
purement idiosyncrasiques (Mukamurera, Lacourse & Couturier, 2006). La multiplication
des cas peut également être utile dans une logique comparative et pour permettre de
trouver des cas contraires qui inciteront à approfondir la compréhension et l’explication
du phénomène à étudier. Au niveau des unités d’analyses, comme les méthodes agiles sont
principalement adoptées dans les projets SI, nous nous sommes focalisés sur l’analyse des
projets SI mobilisant des acteurs de différentes unités d’affaires, et les différentes entités
intégrées à la DSI. Le choix de grandes organisations composées de DSI dans différents
secteurs s’est révélé être un critère primaire. D’autre part, comme le préconise Yin (2014),
nous avons veillé à varier les contextes et les types d’entreprises tout en ayant pris le soin
de garder une certaine validité externe.
Bien que le schéma de synthèse des travaux (figure 1) présente une vision linéaire,
l’organisation des investigations s’est déroulée en trois temps avec plusieurs allers-
retours entre terrain et littérature. La construction de l’objet de recherche a émergé lors
d’une rencontre de recherche organisée par Daylight en juin 2016. Une première revue
de littérature a permis d’identifier la thématique de recherche afin d’organiser une
première phase exploratoire des travaux. Les résultats ont notamment permis d’affiner le
choix méthodologique d’analyse pour la phase explicative ayant été lancée fin 2017.
Les données collectées dans les différents cas proviennent de multiples sources
primaires : observations non participantes, entretiens individuels et semi-directifs. Un
complément de données secondaires s’est révélé être nécessaire pour alimenter les
éléments de compréhension de chacun des cas. L’ensemble de ces données a fait l’objet
d’une analyse processuelle (Langley, 1999) en utilisant un instrument théorique proposé
par Oiry* et al., (2010) permettant de clarifier les différentes trajectoires de
généralisation dans les organisations étudiées. La dernière étape d’analyse des données
consistait à compiler notre matériau empirique dans des template (Dumez, 2011).
18
Enfin, comme notre objet de recherche propose de restituer une analyse historique des
événements (Hernes, 2014), la narration chronologique nous est apparue comme une
méthode pertinente pour mettre en valeur la dimension historique de la recherche
(Langley, 1999).
19
contenu de nos travaux, mais ils se révèlent nécessaires pour les analyses compte tenu
des différents instruments théoriques que nous mobilisons dans le chapitre quatre.
Le troisième chapitre dresse un état de l’art des différents travaux portant sur
l’adoption des méthodes agiles de première génération. Nous présentons ensuite les
travaux analysant la mise à l’échelle au niveau des grands projets et les facteurs
contribuant au succès dans la phase d’adoption. Ce troisième chapitre se termine sur la
présentation des récentes études de cas proches de notre objet de recherche.
Nous présenterons de plus un raisonnement par lequel nous montrons que la méthode
Scrum peut effectivement être considérée comme un outil de gestion avec des propriétés
innovantes. Nous complétons ainsi notre cadre conceptuel en mobilisant dans un second
temps les travaux portant sur l’adoption d’innovations managériales puisqu’ils nous
permettront de prendre en compte certains phénomènes exogènes aux organisations
(Damanpour & Wischnevsky, 2006).
La démarche empirique de nos travaux est présentée dans le chapitre cinq. Nous
discutons les défis méthodologiques qui découlent de la problématique et présentons
l’architecture conçue pour la traiter. Nous commençons par délimiter le cadre général de
notre recherche en précisant notre posture. Puis, nous formulons des propositions de
recherche sous forme de questions décrivant notre protocole d’investigation au cours des
différentes phases. Le chapitre cinq présente d’autre part nos choix méthodologiques et
nous développons plus précisément la manière dont nous avons récolté, traité et analysé
notre corpus de données.
Le sixième chapitre présente les résultats de la phase exploratoire. D’une part, nous
présentons une étude de cas pilote à vocation exploratoire ayant été lancée très tôt dans
les travaux. Nous avons ainsi analysé plusieurs DSI du cas Société Générale qui se sont
lancées très tôt dans la généralisation de la méthode Scrum. Les difficultés rencontrées
20
dans la récolte de données de cette phase et les premières analyses menées nous ont
permis d’affiner nos choix d’études de cas pour la phase explicative.
Une deuxième étude exploratoire est exposée dans le chapitre six. En ayant réalisé un
second aller-retour (figure 1) dans la littérature à la suite de l’étude de cas pilote, nous avons
pu identifier le positionnement précis de nos travaux dans la littérature. Nous avons dans
cette seconde partie de la phase exploratoire opté pour le lancement d’entretiens auprès
d’acteurs ayant été souvent évoqué dans le cas pilote. Le coach agile est une figure d’acteur
mobilisé comme agent du changement par les entreprises mettant en œuvre les méthodes
agiles. Une démarche qualitative a été mise en place par laquelle, nous avons interrogé 15
coachs agiles intervenus dans plusieurs organisations chacun. Ces travaux nous ont permis
de mieux considérer les facteurs (ralentisseurs et accélérateurs) inhérents à la généralisation
d’une méthode agile. Nous avons pu de plus clarifier leur rôle dans la généralisation d’une
méthode agile dans les grandes organisations par la proposition d’une taxonomie des
différents types d’accompagnement.
La phase explicative sera développée au cours du chapitre sept en présentant une analyse
processuelle au cas par cas dans un premier temps. Le choix d’une méthodologie d’analyse
processuelle historique requiert de développer le contexte de chacun des cas. Puis, en
décrivant les différents événements clés identifiés, les dispositifs mis en œuvre et les acteurs
influents dans chacune des organisations, nous exposerons les analyses des différentes
trajectoires de généralisation identifiées.
21
Figure 2 : Vue synoptique de la thèse
22
23
Partie 1 – Du développement sauvage au
management de projet agile : présentation
des différents paradigmes de conception des
SI
24
Introduction de la partie
25
Chapitre 1 – Historique des méthodes de
conception de logiciels
Chapitre 1 Chapitre 2
Historique des approches de Présentation et analyse du
conception de logiciels paradigme des méthodes agiles
Chapitre 3 Chapitre 4
L’adoption des méthodes agiles : L’adoption des méthodes agiles
un état de l’art au travers du prisme des outils de
gestion
26
1. Fondements des premiers paradigmes de
conception de logiciels
Le développement de logiciels trouve ses racines dans les années 1950 avec à l’époque
de premiers langages de programmation en émergence telles que le COBOL ou le
FORTRAN. Si la tendance s’est accentuée par la suite, le premier usage du mot « software
», logiciel en français date de 1959 (Judd, 2000). C’est notamment en 1968 que la sphère
informatique va connaître un tournant majeur lors d’une conférence organisée par
l’OTAN où il est alors proposé la création d’une discipline d’ingénierie logicielle (Gibbs,
1994 ; Booch, 2018).
Il nous parait d’autre part important d’introduire les différentes terminologies utilisées
pour désigner les différents cycles de conception. Les termes « méthodologie » et «
méthode » utilisés dans l'étude des méthodologies de développement de systèmes ne sont
pas clairement définis (Avison & Fitzgerald, 2003). Les deux termes seront utilisés de
façon interchangeable dans cette thèse. D’autre part, les méthodes agiles sont souvent
définies comme des framework en anglais (Schwaber, 1997). Nous opterons pour l’usage
du terme « cadre méthodologique » qui se révèle plus explicite. Enfin, l’usage du terme
« approche » sera mobilisé pour désigner un ensemble de méthodes agiles ou ensemble
de méthodes traditionnelles pour décrire le mode de conception.
27
1.1 Prémices de l’ingénierie logicielle
Dans les années 1950, le modèle code and fix
(codage/correction) est la méthodologie de
développement le plus primaire utilisée en génie logiciel.
Cela commence avec peu ou pas de planification initiale
où l’ingénieur logiciel commençait à immédiatement
écrire des lignes de codes, voir le fonctionnement et
corriger les dysfonctionnements au fur et à mesure
jusqu'à la fin du projet. L’ordre des étapes consistait à
coder d’abord et à réfléchir à l’alignement des exigences
ensuite à la conception globale, aux tests et à la
maintenance. Or, ce mode de conception était plutôt
qualifié d’« anarchique » et manquait de structuration
pour de grands projets (Boehm, 1988 ; Drappa &
Ludewig, 2000). Ce premier cycle a notamment entraîné
des difficultés nécessitant un séquençage explicite des
phases du développement d’un logiciel. En particulier, la
nécessité de définir avant le codage, les exigences et la
préparation rapide pour les tests et la modification. En lien Figure 3 : Décomposition du Stepwise
avec les théories de la conception (Le Masson & Weil, model
2008), nous qualifions ce premier cycle de « conception
sauvage » en raison du faible nombre de ressources qui se limitaient à quelques
développeurs, les connaissances initiales étaient faibles en matière de développement de
logiciels et l’apprentissage s’effectuait principalement par essai-erreur.
La décennie des années 1950 a vu les ordinateurs et les logiciels passants d’usages
militaires et scientifiques au monde des affaires. Au niveau militaire, le projet Semi-
Automatic Ground Environnent aux États-Unis (SAGE) est reconnu comme l’un des plus
importants projets de la décennie ayant contribué à créer le stepwise model (modèle
séquentiel). C’est l’un des premiers cycles de conception détaillant les différentes étapes
du processus de développement. Il est alors proposé par Herbert Bennington en 1956
(Bennington, 1983) dans le cadre du développement du projet SAGE.
L'expérience acquise avec de grands systèmes logiciels, tel que le SAGE (qui se traduit
par environnement semi-automatisé au sol) avait permis de reconnaître la nécessité de
structurer autrement le développement de grands logiciels. Le projet SAGE avait
clairement fait émerger le besoin d’organiser différentes phases de conception
comprenant : la planification, la préparation des tests et les potentielles évolutions des
demandes à considérer au début d’un projet.
28
La figure 3 permet de distinguer les différentes étapes successives à la création d’un
programme selon le stepwise model. Il est par ailleurs l'un des premiers modèles à relever
le défi d’intégrer une préparation rapide pour les tests et la modification du code
développé (Royce, 1970). Ce modèle découle des problèmes causés par la taille croissante
des logiciels, qui ne pouvaient pas être gérés par un seul programmeur.
C’est justement en octobre 1968, lors d’une conférence à Garmisch en Allemagne sous
le titre : « Génie logiciel », que l’une des premières crises du développement de logiciel
s’officialisait. La conférence a marqué la fin de l’ère de l’innocence dans la conception de
logiciels, et mis en évidence une prise de conscience du fait qu’une « crise » de la
production de logiciels ne prendrait pas fin rapidement. La conférence était soutenue par
l’OTAN qui évoquait notamment les dangers pouvant à l’époque être induits par des
pannes, bugs ou problèmes liés à la conception des logiciels dans ses systèmes de défense.
Le nom donné à cette activité - ingénierie logicielle- était selon certains experts assez
provocateurs (Brennecke & Keil-Slawik, 1996), celui-ci suggérait que la crise du logiciel
reposait sur le fait que les programmeurs manquaient de bases théoriques et de discipline
par rapport aux autres pratiques que l'on trouve dans les domaines traditionnels de
l’ingénierie. Certaines des solutions proposées consistaient à créer une nouvelle
discipline du génie logiciel, avec des techniques plus formelles de programmation
structurées et de nouveaux langages de programmation qui remplaceraient le COBOL et
le FORTRAN.
29
Les propositions faites au cours de la conférence convergeaient vers l’idée de séparer
les différentes activités afin de créer un processus de fonctionnement séquentiel. Il est par
ailleurs intéressant de constater qu’à cette époque, l’un des sujets de préoccupation
majeure concernait la réalisation de grands projets et que la complexité était déjà de
mise :
D’autre part, les propositions lors de la conférence étaient basées sur des hypothèses
a priori selon lesquelles les solutions pouvaient être directement trouvées en suivant un
ensemble d'étapes séquentielles. Ce qui supposait que les développeurs pouvaient
obtenir des informations complètes sur les problématiques avant de se lancer dans le
processus de développement (Baskerville, Travis et al. 1992, Fitzgerald 1996).
30
d’une évaluation CMMI implique donc d’évaluer chaque processus de l’organisation pour
ensuite créer un plan d’amélioration.
Malheureusement, ce modèle processuel a été décrié dès le début, car les séquences
proposées ne correspondaient pas nécessairement à la situation de chaque projet (Barry
Boehm, 1996). Les phases ultérieures dépendent directement des phases précédentes et
nécessitent par conséquent une « prévision parfaite » des tâches à réaliser lors les
premières phases du cycle de développement (Fitzgerald, 1996), ce qui était alors assez
difficile à anticiper.
31
Figure 5 : Cycle de vie du développement en cascade Figure 4 : modèle en spirale
Parmi les nouveaux attributs proposés par Barry Boehm dans ce modèle, la répétition
de cycle de prototypage devient l’élément clé de la construction d’un logiciel. Ce
fonctionnement itératif et incrémental, c’est-à-dire le fait de répéter plusieurs fois le
développement et « incrémenter » de nouvelles fonctionnalités au fur et à mesure du
développement change la donne des précédentes approches de conception. (Larman &
Basili, 2003)
Chaque cycle de la spirale suit une itération qui traverse quatre cadrans, comme
l'illustre la figure 4. La première étape consiste à déterminer les objectifs de la partie du
produit en cours d'élaboration (performances à atteindre, fonctionnalités, degré
d'adaptation au changement, etc.) ensuite, le développeur devait évaluer les risques et les
32
alternatives à potentiellement mettre en œuvre, arrive ensuite la phase de
développement et de tests qui permettaient de produire un prototype qui doit être évalué.
Enfin, la fin d’une itération se termine par la planification de la prochaine phase.
À chaque cycle de la spirale, un prototype est construit puis vérifié par rapport aux
objectifs initiaux qui sont ensuite validés par des tests, cette activité permet notamment
d’inclure l’utilisateur d’une solution pour percevoir ses avis et réviser la nature de ce qui
est à développer.
Avant cela, les risques sont identifiés et analysés afin de les gérer. Les risques sont
ensuite classés en tant que risques liés à l'interface utilisateur ou au développement. Si
les risques liés au développement prédominent, la suite de la conception suit une
approche progressive et séquentielle. D'autre part, si les risques liés à la performance sont
prédominants, l'étape suivante consiste à suivre la spirale jusqu'au prochain
développement évolutif. Cela garantit que le prototype produit dans le deuxième cadran
du modèle présente des risques minimes.
L’apport de ce modèle réside d’autre part dans la gestion des risques pour déterminer
le temps et les efforts à consacrer à toutes les activités du cycle, telles que la planification,
la gestion de projet, la gestion de la configuration, l’assurance qualité, la vérification
formelle et les tests. Par conséquent, la gestion des risques est utilisée comme un outil
pour contrôler les coûts de chaque cycle. Une caractéristique importante du modèle en
spirale est la révision des prototypes délivrée.
33
1.4 Le cycle développement en V
Le cycle en V, présenté pour la première fois au symposium INCOSE en 1991 à
Chattanooga, dans l’état du Tennessee aux États-Unis (Forsberg & Mooz, 1996), a été mis
au point par la NASA. Le modèle est une variante du modèle en cascade en forme de V plié
en deux au niveau de décomposition le plus bas, comme le montre la figure 6 ci-dessous.
La partie gauche de la forme en V représente l'évolution des besoins de l'utilisateur,
passant de spécifications de plus en plus affinées au cours du processus de décomposition
et de définition des besoins. La partie droite représente l'intégration et la vérification des
composants du système à des niveaux successifs de mise en œuvre et d'assemblage. L'axe
vertical décrit le niveau de décomposition du niveau système, en haut, au niveau de détail
le plus bas, au niveau composant en bas. Ainsi, plus un système est complexe, plus la forme
en V sera profonde avec le nombre d'étages correspondant.
Figure 6 : Cycle e en V
34
2. Émergence des approches agiles de
conception des systèmes d’information
Le verbe « itérer » provient du mot latin itero qui signifie «répéter»e, ce terme met
l'accent sur le comportement répétitif en tant qu'élément essentiel de la création de code
(Berente & Lyytinen, 2007). Dans le contexte du développement de logiciels, l’itération
peut être considérée comme une période cyclique de planification, construction et test du
code (Larman & Basili, 2003). L’itération est aussi décrite comme des «répétitions de
phases de développement» et de «sous-phases répétitives au sein d’un processus
principal de conception» (Iivari, 1987). Ces itérations se déroulent d’autre part via des
activités de prototypage (Berente & Lyytinen 2007). Nous utiliserons, le terme « itération
» pour désigner des activités répétitives dans la conception de logiciel afin de ne pas le
confondre avec le sprint proposé dans des méthodes plus contemporaines.
e https://www.cnrtl.fr/etymologie/itérer
35
des modes de conception basés sur des cycles itératifs et incrémentaux. C’est par exemple
le cas de l’ingénierie concourante dans le domaine de l’industrie (Garel, 2013). La période
des années 1970 à 1990 se révèle être une période des plus actives pour la mise en œuvre
de ces cycles.
Or, comme en témoigne l’article de Al-Ahmad et al., (2009), cette accentuation ne s’est
pas faite sans obstacle. De nombreuses études dans les années 1990 ont commencé à
identifier les raisons des échecs dans les projets logiciels, mais aussi des projets portant
sur la mise en œuvre des technologies de l’information (TI). Le rapport proposé par le
Standish Group en 1995 met un terme sur cette crise du logiciel en publiant l’étude
« chaos report » (le rapport chaotique). Sur un échantillon d’une taille totale qui était à
l’époque composée de 365 répondants représentant 8 380 applications, il est assez
marquant de voir aujourd’hui que l’étude révélait que 52.7% des projets étaient
considérés comme « remis en cause ». Ceci signifiait que le projet était terminé et
opérationnel, mais dépassait le budget prévu sur la durée estimée en offrant moins de
fonctionnalités que celles spécifiées à l'origine. Puis, l’étude révélait que 31.1% des
projets étaient altérés, c’est-à-dire que le projet était annulé à un moment quelconque du
cycle de développement.
Les développeurs impliqués dans les projets TI doivent donc accomplir des tâches
particulièrement difficiles et doivent développer une faculté d’adaptation continue. Par
36
ailleurs, plusieurs chercheurs justifient les échecs des projets TI en soulignant le fait que
les méthodes traditionnellement employées dans les projets étaient trop « lourdes »
(Boehm, 2002).
Le consortium a notamment donné lieu à ce qui est défini comme un Framework qui se
traduit littéralement par un cadre de méthodologique portant le même nom que le
consortium. La méthode de développement de systèmes dynamiques (DSDM) a été créée
dans un objectif de proposer une méthode centrée sur la qualité dans laquelle les
techniques RAD pourraient être utilisées. La méthode utilise des techniques de
prototypage pour assurer la livraison fréquente de logiciels produits en cours de
37
développement. Ces produits sont livrés dans des délais fixes et connus en tant que "boîtes
de temps" ou « Timeboxing » en anglais. En 1998 le consortium détenait environ 200
membres affiliés d’organisations britanniques et irlandaises.
Nous reviendrons dans le chapitre suivant au niveau des raisons qui justifient
l’ascension de ces méthodes, mais il nous paraît essentiel de souligner que les approches
agiles nées dans la décennie 1990 s’inspirent toutes de travaux de recherche et de
techniques existantes dans le génie logiciel. En effet les pratiques et concepts préexistants
et les influences majeures sur chacune des méthodes agiles sont disponibles dans la carte
évolutive développée par Abrahamsson et al., (2003) (figure 7). La carte illustre les
méthodes agiles de première génération (noms entourés d’un carré dans la figure 7), leurs
interrelations et surtout les pratiques préexistantes ayant contribué à l’émergence de
chaque méthode.
Enfin, l’autre aspect important illustré par la synthèse d’Abrahamsson et al., (2003)
réside dans le fait que les méthodes créées dans les années 1990 ont toutes été portées
par des auteurs ayant contribué par la suite à la création du manifeste agile de
développement de logiciels.
38
Figure 7 : synthèse des liens entre les différentes méthodes agiles de première
génération (Abrahamsson et al. 2003)
39
documentation exhaustive ; la collaboration avec les clients plus que la négociation
contractuelle et l’adaptation au changement plus que le suivi d’un plan ».
Les individus et leurs interactions plus que les processus et les outils
valeurs
fixés.
La méthode la plus simple et la plus efficace pour transmettre de l’information à
l'équipe de développement et à l’intérieur de celle-ci est le dialogue en face à face.
Un logiciel opérationnel est la principale mesure d’avancement.
Les processus agiles encouragent un rythme de développement soutenable.
Ensemble, les commanditaires, les développeurs et les utilisateurs devraient être
capables de maintenir indéfiniment un rythme constant.
Une attention continue à l'excellence technique et à une bonne conception renforce
l’Agilité.
La simplicité – c’est-à-dire l’art de minimiser la quantité de travail inutile – est
essentielle.
Les meilleures architectures, spécifications et conceptions émergent d'équipes
autoorganisées.
À intervalles réguliers, l'équipe réfléchit aux moyens de devenir plus efficace, puis
règle et modifie son comportement en conséquence.
Les valeurs et principes dictés dans le manifeste constituent à notre sens la philosophie
gestionnaire (Hatchuel & Weill, 1992 ; David 1996) commune à toutes les méthodes
agiles. Nous verrons dans le prochain chapitre qu’il est possible d’envisager une
abstraction des différentes méthodes agiles en distinguant plusieurs substrats
techniques, une philosophie gestionnaire de base et une volonté de simplification de la
conception de logiciel autour des différentes méthodes.
40
Business Reviewf où il est évoqué que Mike Beedle s’était notamment inspiré du livre Agile
Competitors and Virtual Organizations : Strategies for Enriching the Customer paru en
1994. Le livre donnait notamment l’exemple de 100 entreprises américaines qui
adoptaient de nouvelles formes d’organisation pour faire face à des marchés ultras
concurrentiels.
Or, à la suite de la vague d’émergence et d’adoption des méthodes agiles au début des
années 2000, des faiblesses ont été identifiées au niveau des cadences de développement
(Gupta et al., 2019). En effet le fonctionnement des équipes en mode itératif, incrémental
et adaptatif a permis d'obtenir des cadences plus fréquentes de développement de
logiciels, mais le manque de relai entre les différentes équipes de développement et les
équipes coordonnant la mise en production effective des logiciels dans les organisations
est une grande difficulté. En conséquence, cela peut entraîner de longs décalages entre
l’émission des besoins, le codage du logiciel et la mise à disposition aux clients (cf.
figure 8). Le schéma ci-dessous, permet notamment d’illustrer la séparation des tâches
réalisées par les « développeurs » et les « opérations ».
f https://hbr.org/2016/04/the-secret-history-of-agile-innovation
41
Figure 8 : Complément du concept DevOps aux méthodes agiles
C’est donc lors d’une conférence en 2009 que Patrick Debois a ainsi mis en lumière le
phénomène en proposant de casser les silos entre les différents acteurs impliqués dans le
processus de développement de logiciel. Il suggéra notamment le terme DevOps
désignant la collaboration étroite entre les équipes de développement (Dev) d’une
application et les acteurs testant et exploitant les logiciels en l’occurrence les
opérationnels (Ops) (Debois 2009, 2011). DevOps se décrit par la capacité d’un processus
de développement à être continu, il s’agit là d’éviter au maximum les temps morts entre
les différentes étapes de développement de sorte à atteindre un niveau de réponse le plus
optimum possible.
Atteindre un niveau de performance comme celui-ci doit ainsi être soutenu par certains
facilitateurs culturels et technologiques. Les facilitateurs permettent une méthode de
travail fluide, flexible et efficace entre les acteurs construisant les solutions logicielles et
les opérateurs. Puis, des solutions techniques sont apparues pour fluidifier la
transmission des éléments développée entre les membres d’une équipe de
développement (Smeds et al., 2015).
De récents travaux soutiennent notamment que la mise en œuvre des méthodes agiles
dans les organisations tend de plus en plus vers la mouvance DevOps de sorte à intégrer
un plus grand nombre de parties prenantes dans le développement des logiciels (A.
Hemon et al., 2018; Aymeric Hemon & Rowe, 2019). L’idée est ainsi d’améliorer les
cadences de développement et satisfaire au maximum l’utilisateur final. Cette évolution
se révèle cependant être très compliquée à mettre en œuvre du fait de la structuration
des organisations. Holmström Olsson et al., (2012) ont ainsi souligné la nécessité d'une
collaboration étroite grâce à des unités organisationnelles spécifiques intégrant la gestion
des produits et étant pleinement impliquées, couplées à des utilisateurs clients proactifs
dans le développement de l’application.
42
Synthèse du chapitre 1
L'industrie du logiciel existe depuis le milieu des années 1950, mais jusqu'en 1965, très peu
d'attention lui a été accordée. Ceci est dû en grande partie parce que l'industrie était trop petite pour
mériter une analyse détaillée selon Brennecke & Keil-Slawik (1996). Cependant, le développement de
logiciels a connu plusieurs périodes influencées par le rythme d’évolution des technologies
informatiques. Nous constatons que de nombreux cycles de conception de logiciels ont émergé
(Ruparelia, 2010), que nous proposons de regrouper en quatre périodes(figure 9). D’une part, le début
des années 1950 s’illustre avec le développement « anarchique ». La conception ne suit pas de cycle
précis et se révèle être faiblement documentée et très faiblement organisée en termes de cycle de
conception. La naissance de l’ingénierie logicielle appuyée par la conférence organisée par l’OTAN en
1968 et 1969 n’aura pas pu réellement ancrer la discipline et les premières propositions de cycles de
conception auprès des développeurs de l’époque.
C’est en 1970, avec le développement en cascade proposé par Royce (1970), que la discipline prend
un tournant majeur. Le cycle de développement est notamment basé sur un processus piloté par un
plan avec des exigences statiques. L’idée derrière ce modèle réside dans la volonté de réduire les
incertitudes liées au développement de grands systèmes logiciels. Une caractéristique clé concerne
également la séquentialité des phases de développement où chaque étape ne prévoit pas de retour en
arrière dans la conception. Or le modèle en cascade a fait l’objet de nombreuses critiques du fait de sa
lourdeur. Une des réponses proposées par Boehm (1988) fut l’introduction du modèle de conception
en spirale. Basé sur un cycle itératif et incrémental, il se révèle être une vraie rupture dans la manière
de concevoir les logiciels. La proposition du prototypage et les interactions fréquentes avec les futurs
utilisateurs font du modèle en spirale une vraie nouveauté dans la manière de concevoir de grands
projets logiciels.
La troisième période qu’il est possible d’identifier concerne la naissance du paradigme de l’agilité.
La naissance de ce paradigme s’explique par plusieurs faits, d’une part, les années 1990 ont connu de
fortes évolutions technologiques avec l’émergence de la micro-informatique. Le secteur informatique
participe d’une évolution générale qu’ont connue les industries de logiciels. 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. 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 » permettant aux organismes de développement de réagir
et de s'adapter rapidement à l'évolution des exigences et des technologies.
43
Nous retenons enfin que la majorité des processus de développement de logiciels qui avaient été
mis au point dans les années 1970 et 1990 étaient critiqués comme étant bureaucratiques ont
énormément contribué à la structuration des premiers départements de conception des SI. Cet aspect
se révèle être crucial en raison des changements induits par l’introduction des méthodes agiles.
Figure 9: Evolution des cycles de conception inspiré de la proposition de Vohra et Singh, (2013)
44
Chapitre 2 : Présentation et analyse du
paradigme des méthodes agiles
Chapitre 1 Chapitre 2
Historique des approches de Présentation et analyse du
conception de logiciels paradigme des méthodes agiles
Chapitre 3 Chapitre 4
L’adoption des méthodes agiles : L’adoption des méthodes agiles
un état de l’art au travers du prisme des outils de
gestion
INTRODUCTION ............................................................................................................................................... 46
1. REVUE DES DIFFERENTES GENERATIONS DE METHODES AGILES ............................................................................... 47
1.1 Les cadres méthodologiques pour les petites équipes de développement ....................................... 47
1.2 Analyse historique de l’émergence du cadre méthodologique Scrum ............................................. 48
1.3 Les attributs clés des approches de première génération ................................................................ 59
1.4 Revue des différentes méthodologies à grande échelle ................................................................... 64
1.5 Les attributs des approches à grande échelle .................................................................................. 65
1.6 Des entreprises vectrices de nouveaux modes d’organisation ......................................................... 71
2. MANAGEMENT DE PROJET ET AGILITE : VERS UN MEME CONTINUUM ? ................................................................... 73
2.1 Fondations du « management par projets » .................................................................................... 73
2.2 L’ingénierie concourante et Scrum des fondations communes ? ..................................................... 75
2.3 Influence des méthodes agiles dans les référentiels de management de projet .............................. 77
2.4 L’émergence des référentiels pour étendre les modes de fonctionnement agiles auprès des équipes
métiers .................................................................................................................................................. 79
45
Introduction
De la conception de logiciels à la gestion de projet : vers des modes d’organisation
d’entreprises ?
Jusqu’à la fin des années 1990, les approches dominantes de développement de projets
informatiques étaient basées sur la planification et le découpage extensifs des projets 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 les approches agiles.
Une variété de méthodes agiles a vu le jour depuis les années 90, certaines proposées
par des experts, d’autres véhiculées par des organisations motrices de nouvelles
pratiques. Un flagrant constat réside dans le fait que ces méthodologies de conception de
logiciels se sont étendues au-delà de la programmation informatique pure pour devenir
de vraies approches intégrées au pilotage de projets intégrant les problématiques
classiques de gestion de projet tel que la gestion d’un budget, des parties prenantes
multiples, ou encore l’analyse des risques (Conforto, da Silva, & de Almeida, 2014;
Conforto & Amaral, 2010; Conforto, da Silva, Di Felippo, & Kamikawachi, 2016).
Il nous paraît d’autre part important de présenter la manière dont les approches agiles
initialement créées comme des méthodes de conception de SI sont devenues à travers le
temps des méthodologies de gestion de projet (Midler, 2008). Et nous verrons par ailleurs
que certaines organisations peuvent être motrices de modes de fonctionnement inspirés
des méthodes agiles. Nous parcourons le cas de l’entreprise Spotify dont le mode
d’organisation a inspiré de nombreuses entreprises.
46
1. Revue des différentes générations de
méthodes agiles
1.1 Les cadres méthodologiques pour les petites équipes de
développement
Parmi les nombreuses approches agiles existantes dans la littérature, nous proposons
de classifier celles-ci en deux catégories tenant compte du nombre d’acteurs à
coordonner. De nombreuses publications font référence au terme agile à l’échelle dans la
littérature pour désigner l’extension des modes de fonctionnement issus des méthodes de
première génération au fonctionnement des projets mobilisant un plus grand nombre
d’acteurs (Alqudah & Razali, 2016b; Ambler & Lines, 2014; Dingsøyr, Fægri, et al., 2014;
Laanti, 2008; Reifer et al., 2003).. Ceci ayant conduit à l’émergence de plusieurs cadres
méthodologique que nous présentons dans la section 2 de ce chapitre. Les méthodes
agiles de première génération sont donc destinées aux équipes comprenant 4 à 11
personnes (Lindvall et al., 2002; McMahon, 2005).
Organisme
N° Nom de la méthode Acronyme Approche initiale Publication clé Créateur - initiateur
d'appartenance
Rapid Application James Martin (Barry
1 RAD - James Martin (1991) -
Development Boehm)
Schwaber & Scrum.org / Scrum Ken Schwaber / Jeff
2 Scrum Scrum -
Sutherland (1995) Alliance Sutherland
Jennifer Stapleton (Grande
Dynamic Systems Rapid Application Agile Business
3 DSDM DSDM (1995) Bretagne) à proposé une
Development Method Development Consortium
extension de RAD
Rational
4 Unified Process UP Objectory Kruchten (1999) IBM Philippe Kruchten
Process
5 eXtreme Programming XP - Beck (1999) - Kent Beck
Adaptative Software
6 ASD - Highsmith (2000) - Jim Highsmith
Development
47
Les méthodes « agiles » de première génération (tableau 1) offrent des principes de
fonctionnement pour mettre en place un processus de conception itératif, incrémental et
adaptatif par le biais de techniques telles que le sprint, le time-boxing, la programmation
par paires, pour n’en nommer que quelques-unes (Hoda et al., 2010; Paasivaara &
Lassenius, 2006). En conséquence, les méthodes agiles sont plus "pragmatiques" sur la
façon de développer un logiciel (i.e. le processus de conception), que sur ce qu’il faut
développer (résultats) (Tripp & Armstrong, 2014). En termes d’usage, certains aspects
comme l’intégration des changements dans le processus de développement rendent les
approches agiles adaptées aux environnements turbulents. L’accent mis sur les activités
liées à la conception telles que les réunions quotidiennes dans Scrum se révèle être une
autre forme de pragmatisme véhiculé par les méthodes agiles (Bass, 2012).
48
1.2.1 Le passage d’une méthode contextuelle à une forme de rationalisation
La première version de la méthode Scrum a été développée par Jeff Sutherland, alors
vice-président des technologies objets au sein de l’entreprise Easel. Cette société établie
aux États-Unis développait à l’époque des logiciels pour différents types d’industries
comme Ford Motor Company, qui utilisait leurs logiciels pour concevoir et construire des
applications internes. Face aux difficultés financières liées aux retards de livraison de ses
produits, les dirigeants d’Easel demandèrent à Jeff Sutherland et son équipe de
développer en six mois une toute nouvelle ligne de produits destinée à certains de leurs
plus gros clients. Le PDG d’Easel était à l’époque confronté à une organisation en grande
difficulté financière et devait absolument réinventer leurs modes de fonctionnement.
C’est ainsi que Jeff Sutherland entama des investigations approfondies sur la réussite
de projets du monde entier et en s’appuyant sur la littérature en informatique. Inspirée
directement des travaux de Takeuchi & Nonaka (1986) (Rigby, Sutherland & Takeuchi,
2016), ainsi que du livre Wicked Problems, Righteous Solutions (DeGrace & Stahl, 1990)
(Rigby, Sutherland and Takeuchi, 2016), la toute première version de Scrum mise en place
chez Easel se composait d’un Product Manager collaborant avec une équipe de réalisation
et en six mois de projets, ils créèrent 6 sprints (inspiré de l’ingénierie concourante)
rythmés avec un carnet d’exigences dynamiques (Product Backlog). Le tableau 2 présente
ainsi les principales sources d’inspiration ayant permis aux créateurs de la méthode de
conceptualiser celle-ci.
49
l’équivalent du thermomètre qui prélève Les rituels de communications
constamment la température de l’équipe. issus du projet Borland inspirent
Jeff Suthelrand pour la création
des Daily Scum meeting
The Fifth (Peter, L’idée de constituer une équipe autonome où Auto-organisation de l’équipe
Discipline: The Art 1990) chacun a une vision globale du produit au de réalisation pendant les
and Practice of quotidien semblait être la bonne approche. sprints
the Learning
Organization
Wicked Problems, DeGrace DeGrace et Stahl ont examiné des modèles Structuration du
Righteous (1990) de développement de logiciels "tout-en-un" fonctionnement d’un Sprint ➔
Solutions qui s’adaptent de manière unique à la mise Développement simultané.
en œuvre orientée objet des logiciels et
aident à résoudre ces problèmes. Les
modèles "tout-en-un" supposent que la
création d’un logiciel se fait en travaillant
simultanément sur les exigences, l’analyse, la
conception, le codage et les tests, puis en
livrant le système entier d’un seul coup. Le
modèle tout-en-un le plus simple est un
super-programmeur unique qui crée et
fournit une application du début à la fin.
Rapid Application Martin Nous avons réalisé que nous avions besoin Reprise du fonctionnement
Development (1991) d’un processus de développement qui devait itératif et incrémental ➔ Jeff
correspondre à une version améliorée du Sutherland propose en plus
développement rapide d’applications, où la d’injecter un principe
visualisation de la conception pourrait d’adaptation continue aux
aboutir immédiatement à un code évolutions du projet (dans une
fonctionnel. fréquence quotidienne)
Object Oriented (Booch, SCRUM est une amélioration de l’approche L’évolution technologique à
Analysis and 1994) itérative et incrémentale pour fournir des l’époque conduit les créateurs
Design with logiciels orientés objet, initialement de Scrum à proposer un cycle
Applications documenté par Pittman et plus tard plus flexible que les précédents
développé par Booch. modèles de fonctionnement
➔le contexte technique de
l’époque contraint l’adaptation
rapide des logiciels développés.
Process dynamics, Ogunnaike Le contrôle des processus industriels mis en Le concept de processus
modeling and and œuvre chez DuPont définit les processus empirique est repris comme
control Harmon comme étant soit "théoriques" (entièrement fondation de Scrum ➔ ce qui
(1994) définis), soit "empiriques" (boîte noire). aboutit plus tard aux 3 piliers de
Lorsqu’un processus de la boîte noire est la méthode : Transparence,
traité comme un processus entièrement inspection et adaptation
défini, des résultats imprévisibles se
produisent.
Tableau 2 : Synthèse des sources d’inspirations ayant abouti à la création de la
méthode Scrum
50
Le projet fut un franc succès pour Easel qui fut ensuite rachetée en 1995 par la société
VMARK. C’est à cette occasion que Ken Schwaber fut introduit à la première équipe de
développement Scrum. Suite au succès rencontré chez Easel Jeff et Ken se mirent d’accord
pour que Ken devienne le « diffuseur » de la méthode à l’industrie du logiciel. Et pendant
ce temps-là, Jeff fut consacré à déployer le développement orienté objet et Scrum dans les
filiales de VMARK aux États-Unis, en Europe et en Australie. La collaboration entre Jeff et
Ken aboutit dans un premier à la rédaction de l’article Scrum development process qu’ils
présentèrent à la conférence OOPSLA g en 1995.
Dès lors, les auteurs considéraient que le développement d’un logiciel se révélait être
un projet exploratoire, en ce sens, ils reprennent le concept de « boîte noire » des
processus empiriques mis en œuvre dans l’industrie chimique pour assumer le fait que
les équipes de développement devaient s’adapter quotidiennement aux contingences du
projet. La « boîte noire » se matérialise dans Scrum par un sprint organisé et constamment
réadapté par des variables d’environnement, en tenant compte notamment du temps, la
concurrence, le coût ou la fonctionnalité. Les auteurs précisent aussi que les facteurs
déterminants liés la bonne mise en place de Scrum résident dans la les connaissances du
marché, le contact avec la clientèle (futurs utilisateurs) et les compétences des
développeurs. Des ajustements fréquents du contenu des produits livrables ont lieu au
cours du projet en fonction de l’environnement. Le produit délivré et revu à tout moment
au cours du projet. L’idée de mutualiser des taches dans un sprint pour éviter les défauts
du modèle séquentiel provient essentiellement de l’ingénierie concourante mise en
lumière par les travaux de Takeuchi and Nonaka (1986).
51
aussi pour quelque chose dans le fait de collaborer de la sorte, puisque les langages de
programmation orientés objet permettaient de faciliter la création de prototypes
d’applications.
L’histoire de Scrum est finement liée aux expériences de ses créateurs. En 1996, Jeff
Sutherland quitta Easel pour rejoindre l’entreprise IDX systems (devenue aujourd’hui
General Electric Healthcare) pour prendre le poste de vice-président de l’ingénierie et du
développement des produits. IDX comptait plus de 4 000 clients et était l’une des plus
grandes sociétés américaines de logiciels de santé, avec prêt de 600 développeurs
travaillant sur des dizaines de produits. Cette expérience fut l’occasion d’étendre Scrum à
l’échelle d’une grande structure. La collaboration avec Ken Schwaber continua dans cette
société puisqu’il fut intégré en tant que consultant pour travailler sur la refonte complète
d’un logiciel médical chez IDX. En « facilitant » la mise en œuvre de la méthode, il mit en
place le rôle de ScrumMaster (Highsmith & Cockburn, 2001).
h Les Patterns languages sont des modèles développés pour favoriser la résolution de problèmes qui
surviennent au cours d’une activité. Les règles empiriques consistent en un ensemble général de conseils et
de bonnes pratiques à mettre en place pour le bon fonctionnement d’une activité. Cette branche de
l’informatique est peu connue.
52
C’est ensuite lors d’un projet mené par Ken Shwaber que la méthode Scrum va se doter
d’un nouvel artefact pour suivre les avancées d’un projet. Si nos sources ne nous
permettent pas vraiment de comprendre qui est l’inventeur du Burndown chart, il semble
finement lié au développement de la méthode Scrum. Il fut d’ailleurs présenté par Ken
Schwaber dans son blog. Le Burndown chart est décrit comme une technique « légère »
pour calculer la vitesse du développement.
Jeff Sutherland intégra une nouvelle société de sorte à appliquer la même « recette »
développée dans les précédentes, et c’est par le biais de son expérience chez
PatientKeeper (qu’il rejoint en 2000), qu’il découvre que la méthode Scrum peut-être allié
à d’autres approches plus orientées sur la programmation notamment eXtreme
Programming (XP). À ce stade la méthode ne donne pas de règles, ou de technique de
programmation précises, en alliant Scrum a XP, il figure que les deux approches se
révèlent complémentaires (Sutherland, 2001b). Il est d’ailleurs intéressant de relever le
fait qu’en 1995, Jeff Sutherland fut sollicité par le créateur de la méthode XP pour
échanger autour des pratiques développées dans Scrum.
Puis quelques mois après la création du manifeste, fidèle à son accord préalable avec
Jeff Sutherland pour la diffusion de la méthode, Ken Scwaber publia 4 livres entre 2002-
et 2010 dont le premier nommé Agile Software Development with SCRUM publié en 2002.
Le choix de ce format permit d’une certaine manière aux créateurs de théoriser la
méthode afin de la rendre accessible pour un maximum de praticiens dans le monde
puisque la méthode était principalement présentée à des communautés restreintes au
préalable.
Dans cette seconde phase, une vraie organisation de la diffusion est mise en place. Si
ces aspects concernent moins le contenu de la méthode en tant que tel, c’est tout de même
53
par le biais de ces mécanismes de diffusion que les praticiens vont potentiellement
envisager une adoption. Comme la communauté Scrum commençait à se développer, dans
la lignée du premier livre publié, Ken Schwaber s’associa avec Mike Cohn et Esther Derb
pour créer la Scrum Alliance. Une organisation dont le but est de former et certifier les
acteurs tentant de devenir ScrumMaster. Ce genre d’acteur est chargé de veiller à ce que
le projet soit mené à bien conformément aux pratiques, aux valeurs et aux règles énoncées
dans la méthode. Cependant, des controverses ont commencé à voir le jour sur la
transparence et le motif de la Scrum Alliance entre les deux associés, ce qui a abouti à la
naissance de Scrum.org en 2006 avec à sa tête uniquement Ken Schwaber.
Avec une diffusion qui ne cesse de croitre en 2006 et 2010 à la vue du nombre de
certifiés, la méthode va prendre un tournant particulier en 2010 au niveau de sa diffusion.
Pour faciliter sa compréhension et maximiser sa diffusion, Jeff Sutherland et Ken
Schwaber développèrent le guide scrum, un document gratuit devenant le support
principal pour les acteurs cherchant à se faire certifier. Comme l’extrait de la première
version du guide suivant le montre, la méthode ne se restreint plus au périmètre du
développement de logiciels, mais au développement de produits.
« Depuis le début des années 1990, Scrum est utilisée pour développer des produits
complexes. Ce document décrit comment utiliser Scrum pour construire des produits. Scrum
n’est pas un processus ou une technique de construction de produits ; il s’agit plutôt d’un
cadre dans lequel vous pouvez utiliser divers processus et techniques. Le rôle de Scrum
est de mettre en évidence l’efficacité relative de vos pratiques de développement afin que
vous puissiez les améliorer tout en fournissant un cadre dans lequel des produits complexes
peuvent être développés » (extrait du guide Scrum).
Scrum est ainsi décrite comme une cadre méthodologique « ouvert » permettant de
développer des produits de toutes natures. La méthode n’est plus une recette de cuisine,
mais se révèle être une cadre d’organisation pour le développement de produit logiciel ou
autre pouvant être allié à d’autres méthodes.
54
travail (framework) composé de rôles, d’événements, d’artefacts et de règles qui lient et
fusionnent l’ensemble de travail d’environ trois à neuf équipes Scrum travaillant sur un
seul Backlog Produit pour créer un Incrément intégré qui répond à un objectif (Schwaber,
2015).
Il est d’ailleurs important d’évoquer le fait que la création de Nexus peut être
considérée comme une réponse à la création de la méthode Large Scale-Scrum proposée
en 2014 par Vodde & Larman (2014). De plus une bifurcation s’établit entre les deux
créateurs historiques de Scrum, puisqu’en 2018 Jeff Sutherland lança à son tour
l’approche Scrum@Scale qui est aussi une extension de la méthode Scrum avec des rôles
et des pratiques différentes de Nexus.
55
1.2.2 Rôles et responsabilités de la version 2017 du guide Scrum
Il existe trois rôles dans la méthode Scrum ayant chacun des tâches et des objectifs
différents au cours du processus de développement (tableau 4).
56
Par exemple, la direction participe à la sélection du Product Owner, à l’évaluation de la
progression du développement.
Le Backlog produit : Le Backlog produit définit tout ce qui est nécessaire dans le
produit final en fonction des connaissances actuelles. Ainsi, le Product Backlog est une
liste d’exigences définissant le travail à effectuer dans le projet. Il comprend une liste
priorisée des exigences commerciales et techniques. Il peut inclure des fonctionnalités,
des fonctions, des corrections de bugs, des améliorations demandées et des mises à niveau
techniques. Le Backlog est constamment mis à jour par l’équipe de réalisation en tenant
compte des éventuelles évolutions d’exigences.
Le Sprint : est le nom donné à une itération dans Scrum. Cette phase est traitée comme
une "boîte noire" où l’imprévisible est attendu. Les différentes modes d’organisations
peuvent changer en réponse aux contraintes environnementales. Une équipe Scrum
s’organise pour produire un nouvel incrément de produit exécutable dans un sprint d’une
durée de 1 à 4 semaines. Avant un sprint, une réunion de planification se tient pour
organiser les tâches du sprint.
La réunion de planification du sprint : est une réunion en deux phases organisée par
le Scrum Master. Les clients, les utilisateurs, la direction, et l’équipe de développement
participent à la première phase de la réunion pour décider des objectifs et des
fonctionnalités du prochain sprint. La deuxième phase de la réunion est organisée par le
Scrum Master et l’équipe de développement, qui se concentrent sur la manière dont
l’incrément de produit sera développé au cours du Sprint.
Le Backlog Sprint : est le point de départ de chaque sprint. Il s’agit d’une liste
d’éléments de Backlog de produit sélectionné pour être implémenté dans le prochain
Sprint. Les éléments sont sélectionnés par l’équipe Scrum avec le Scrum Master et le
Product Owner lors de la réunion de planification du sprint, sur la base des éléments
57
prioritaires et des objectifs définis pour le sprint. Contrairement au Backlog de produit, le
Backlog de sprint est stable jusqu’à ce que le sprint (c’est-à-dire 30 jours) soit terminé.
Lorsque tous les éléments du Backlog Sprint sont terminés, un nouvel incrément du
système est livré.
58
1.3 Les attributs clés des approches de première génération
Les méthodes de première génération ont toutes été proposées par différents acteurs,
et ne proposent pas le même système de fonctionnement. Parmi les différents essais pour
classifier et comparer les méthodes agiles entre elles, les travaux de Iacovelli et Souveyet
(2008) dressent un cadre de comparaison basé sur des attributs clés pour caractériser ces
approches. Leur cadre reprend 4 questions permettant de mieux évaluer le degré d’agilité
des méthodes.
Selon les auteurs, quelle que soit l’approche, une méthode de conception logicielle est
composée d’un cycle de vie, de concepts spécifiques sur le développement lui-même et
l’organisation des personnes autour de la méthode. Si le besoin d’adaptation est considéré
comme l’une des principales caractéristiques des méthodes agiles (Conboy, 2009), c’est
notamment par le biais d’un processus de conception itératif, incrémental et adaptatif que
l’agilité prend corps.
Nous l’avons vu dans le précédent chapitre, les méthodes agiles sont dans la continuité
des méthodes itératives et incrémentales. Elles sont basées sur l’amélioration continue de
l’équipe projet et reposent sur un processus de développement dit empirique (Schwaber,
1997). Le modèle en Spiral proposé par Boehm (1988) demeure l’une des principales
sources d’inspiration du cycle de vie des méthodes agiles. Dans tout le cycle de
développement d’un projet, une itération est un mini-cycle autonome comprenant des
activités couvrant l’analyse, la conception, la mise en œuvre et le test des exigences (figure
12). L’un des apports majeurs de la méthode Scrum réside notamment dans le fait que ces
activités doivent être réalisées de manière concourante.
59
Une différence essentielle entre les méthodes agiles et les méthodes itératives
antérieures réside dans la longueur de chaque itération. Dans le passé, les itérations
pouvaient durer trois à six mois. Avec les méthodes agiles, la durée des itérations varie
entre une et quatre semaines et ne dépasse pas intentionnellement 30 jours (Larman &
Basili, 2003).
Plusieurs recherches ont montré que les itérations plus courtes ont tendance à réduire
la complexité dans le développement en rendant l’équipe plus performante par le biais de
meilleures rétroactions (Bider & Jalali, 2016; Lei et al., 2017; Takeuchi & Nonaka, 1986).
Ainsi, les modifications de l’environnement et des exigences peuvent être intégrées à
chaque itération de la conception.
En résumé, les attributs clés concernant le cycle de vie sont selon Iacovelli and
Souveyet, (2008) sont : la livraison d’incrément de produit potentiellement terminé dans
des itérations courtes et fixes, l’intégration des modifications fonctionnelles et des
évolutions d’exigences à prendre en compte à chaque fin d’itération. Nous proposons de
compléter ces attributs par les tâches concourantes à réaliser au cours d’une itération.
60
1.3.2 L’organisation des individus autour de la méthode – autonomie et
pluridisciplinarité
En ce qui concerne l’organisation des personnes, les méthodes agiles ont tendance à
briser les modes de fonctionnement virtuels entre le futur utilisateur et l’équipe de
développement (Erickson et al., 2005). C’est pourquoi elles cultivent toutes un attribut de
collaboration proche avec les futurs utilisateurs (Inayat et al., 2015a).
D’autre part, les méthodes ont été créées dans l’optique de ne pas positionner un acteur
central, conférant un pouvoir décisionnel délégué aux équipes de développement. C’est
donc par l’autonomie et l’auto-organisation que les équipes adoptant une méthode agile
travaillent (Larman, 2004).
Les méthodes agiles admettent qu’une communication basée sur une documentation
parfaite est impossible. Les auteurs de ces approches considèrent que le développement
de logiciel est une activité principalement sociale, se déroulant dans un contexte
particulier. Les équipes doivent ainsi être colocalisées en communicant face à face
(Berente & Lyytinen, 2007; Inayat et al., 2015a).
Les concepts spécifiques à chaque méthode – des approches favorisant la combinaison avec
d’autres techniques
61
Modeling (AM) et eXtrême programming (XP) n’abordent pas la perspective de gestion de
projet.
Le pilotage projet est considéré ici comme une activité de support servant l’efficacité
du processus de développement (Gilb, 1988). Cela suppose l’existence d’activités de
gouvernance du projet permettant la bonne exécution des tâches de développement de
logiciels, mais aussi la bonne réalisation du projet en cas d’engagement contractuel par
exemple. Ainsi, la méthode eXtrême Programming n’offre pas de vue complète de gestion
de projet. Scrum est destinée à gérer des projets de développement logiciel permettant
l’alliance d’autres méthodes plus orientées sur les aspects techniques du développement
(Schwaber & Beedle, 2002).
Les conseils concrets dans ce contexte font référence aux pratiques, activités et
produits de travail qui caractérisent et fournissent des conseils sur la manière dont une
tâche de développement peut être exécutée. Par exemple, Feature Driven Development
(FDD) énonce huit pratiques à mettre en oeuvre pour que le respect des règles de
62
développement soit valorisé (Palmer & Felsing, 2002). Dans DSDM, l’équipe est autorisée
à prendre des initiatives dans les techniques d’estimation et de planification.
Toutes les approches n’ont donc pas le même degré de formalisation. En proposant
plus ou moins de détails sur les pratiques de développement, les méthodes agiles ont été
adaptées en étant combinées à d’autres méthodes (Cao et al., 2009b; Rasnacis & Berzisa,
2017).
Abrahamsson, Oza & Siponen (2003) ont montré que XP manquait de support pour la
gestion de projet, que les méthodes Crystal manquaient de conseils détaillés sur les
techniques appropriées à utiliser, et Scrum, conçu pour gérer des projets itératifs et
incrémentaux, manquait de pratiques spécifiques pour la conception, le code et les
portions de test dans le cycle de vie. En outre, Agile Software Development (ASD) et DSDM
sont des cadres méthodologiques offrant de grandes règles de fonctionnement plutôt que
des techniques précises. Les recommandations visant à combiner des méthodes ou à
utiliser des techniques d’une méthode à une autre proviennent d’un besoin de remédier
à ces faiblesses. C’est pourquoi plusieurs auteurs ont proposé des publications permettant
de combiner différentes méthodes entre-elles (tableau 5).
N° Combinaison Source
1 XP et Scrum Schwaber et Beedle (2002)
2 XP et Crystal Clear Cockburn (2002)
3 XP et ASD Highsmith (2000)
4 XP et RUP Pollice (2001)
5 XP et DSDM Simmonds et Fazackerley (2003)
6 RUP et Scrum Krebs (2005)
7 ScrumBan (Scrum et Kanban) Ladas (2009)
8 Scrum et TDD Savoine, M. M. et al. (2016)
Tableau 5 : Synthèse des propositions d’alliance des différentes méthodes
agiles
Dans certains cas, la combinaison de méthodes est parfois recommandée par les
experts. C’est le cas pour Scrum, et Crystal Clear, cependant peu d’études montrent la
manière dont l’alliance permet de combler les points faibles d’une méthode.
63
1.4 Revue des différentes méthodologies à grande échelle
L’une des problématiques rencontrées par les praticiens dans l’adoption des méthodes
agiles de première génération réside essentiellement dans l’extension pour de plus
grands projets de développement (Kettunen & Laanti, 2008). Très tôt, des acteurs se sont
lancés dans l’adaptation des méthodes de première génération ayant abouti ensuite vers
des référentiels complets. Cette génération de méthodes a d’ailleurs aussi connu une
vague d’adoption dans des entreprises au niveau international (Alqudah & Razali, 2016a;
Sutherland, 2001a).
Approche Organisme
N° Nom de la méthode Acronyme Publication clé Créateur - initiateur
initiale d'appartenance
Rapid Unified
1 Enterprise Unified Process EUP Ambler (1999) - Scott Ambler
Process
Project Management
3 Disciplined Agile Delivery DaD Scrum - Kanban - XP Ambler (2009) Scott Ambler
Institute depuis 2019
Scrum - Kanban -
Lean pour le
4 Scaled Agile Framework SAFe Leffingwell (2011) scaledagile.com Dean Leffingwell
développement de
logiciel
5 Large enterprise Scale Scrum LeSS Scrum Larman et Vodde (2014) www.less.work Craig Larman et Bas Vodde
papiers de recherche pour décrire l’organisation de plus grands projets, cependant cette
notion reste floue. Dingsøyr et al., (2018) définissent le développement agile à grande
échelle comme les efforts de développement qui impliquent un grand nombre d’acteurs,
un grand nombre de systèmes et des interdépendances qui ont plus de deux équipes.
Dikert, Paasivaara and Lassenius, 2016b, donnent tout de même plus de précisions en
64
définissant la grande échelle comme des organisations projet développant des logiciels
comptant au moins 50 personnes ou au moins six équipes.
La plupart des acteurs présents lors de ce congrès ont également convenu que le
déploiement de méthodes agiles dans les organisations implique la mise en œuvre d’une
certaine hybridation : les méthodes agiles doivent fonctionner dans un monde où les
méthodes agiles et traditionnelles peuvent être utilisées ensemble. La question est alors de
savoir comment adapter les méthodes agiles sans sacrifier les principes sous-jacents du
manifeste agile. (Reifer et al., 2003).
Dans le cadre de cette initiative, il est intéressant de constater à quel point le fait
d’étendre les pratiques des approches de première génération créait des avis très
divergents. Dès lors, les réflexions en sont venues à l’adaptation des rituels de certaines
approches telles que le daily meeting de la méthode Scrum. D’autres proposaient de créer
de nouvelles réunions de synchronisation d’équipes pour favoriser la collaboration et
réduire les dépendances. Les principaux facteurs d’attentions mis en exergues lors de
cette conférence sont donc : l’attention particulière des équipes à résoudre les problèmes
d’intégration dans le cas d’un fonctionnement multiéquipes, la mise à l’échelle des
principes agile au niveau de l’entreprise, i.e. en intégrant les acteurs qui ne sont pas
intégrés dans les sphères techniques. Puis troisième facteur d’attention, il s’agit de la
gestion du développement avec des équipes dispersées.
65
Daneva et al., (2013), soulignent dans leur étude sur des projets à grande échelle et
distribués que la compréhension des dépendances dans la répartition de développement
des exigences est d’une importance primordiale dans de tels projets. Ainsi, la
synchronisation des équipes pour faciliter les dépendances se révèle être un attribut
majeur de cette seconde génération d’approche.
Si les publications scientifiques portant sur l’adaptation à grande échelle des méthodes
agiles ne sont pas conséquentes, plusieurs praticiens ont proposé de mieux caractériser
l’organisation de projet agile à grande échelle (Leffingwell, 2007; Eckstein, 2004). Dans
son livre Agile Software in the large paru en 2004, Jutta Eckstein, propose des principes
d’organisation d’équipes agile plus larges. L’une des principales caractéristiques selon
l’auteur réside dans l’importance devant être accordée par les membres du projet à
interagir et communiquer, même s’ils travaillent dans différentes sous-équipées
(Synchronisation multiéquipes de la figure 14). Au niveau du processus de
fonctionnement, l’auteur détaille notamment l’importance de maintenir des rituels
d’échange et de partage entre les acteurs pour favoriser une transparence de
fonctionnement et éviter le travail de l’ombre de certaines équipes de développement. Au
niveau de la planification des tâches de développement à grande échelle, l’auteur
conseillait notamment de favoriser au maximum la mise en place de courts cycles de
développement et accroître les échanges pour réduire la complexité de ce qui est à
développer.
En 2007, Dean Leffingwell est l’un des premiers auteurs i à proposer un modèle de
fonctionnement complet pour étendre les rituels des premières générations de méthodes
i Larman et Vodde (2008) notamment proposé le livre Scaling Lean and Agile ayant contribué à proposer
des principes d’extension de la méthode Scrum.
66
à de plus grandes équipes de développement. Inspiré du mode de fonctionnement de
Microsoft Synch and stabilize dans les années 1990 (Cusumano & Selby, 1996). Leffingwell
part du principe qu’étendre les principes des méthodes de première génération
s’accompagne de nombreux défis, cependant son livre Scaling agile software
developpement est plus précis quant aux rituels et modes de fonctionnements de
synchronisation entre les acteurs. Il considère par ailleurs que les principes de
fonctionnement et de synchronisation doivent s’étendre au-delà des équipes de
développement en incluant potentiellement les départements de marketing et de finance
pour créer un environnement complet en accord avec les principes et la philosophie agile.
Néanmoins, la grande difficulté liée à la mise à l’échelle des méthodes agiles porte sur
l’organisation d’équipes dans un cadre géographiquement distribué. Les organisations se
révèlent être de plus en plus étendues - fréquemment conceptualisées comme des équipes
virtuelles - a fait l’objet d’une attention particulière de la part des chercheurs (Martins et
al., 2004 ; Powell et al., 2004 ; Hertel et al., 2005 ; Connaughton & Shuffler, 2007 ; Schiller
& Mandviwalla, 2007).
Une des propositions faites en 1968 lors de la conférence organisée par l’OTAN pour
combler le manque de discipline dans le développement de logiciel fut la programmation
orientée composant (Naur & Randell, 1968). Elle consiste à utiliser une approche
modulaire de l’architecture d’un projet logiciel (Riveill, 2000). Ce mode de
programmation permet d’assurer une meilleure lisibilité et une meilleure maintenance
du programme développé. Cependant, la programmation orientée composant a conduit à
la structuration d’équipes regroupées autour des différents cœurs de métier de la
programmation informatique (architecture, développeurs, développeurs de base de
données, testeurs, etc.). Ce mode d’organisation dans le cadre d’un fonctionnement
traditionnel se révèle être assez problématique puisque ce qui est développé passe
d’équipe en équipe, créant ainsi de fortes dépendances.
67
1.5.3 Les différents niveaux de planification
Dans un second temps, Dean Leffingwell propose notamment que les équipes de
réalisation puissent planifier de façon autonome leurs tâches à réaliser au cours des cycles
itératifs de 1 mois. Ceci étant compris dans un niveau inférieur de planification d’une
Release (figure 15). La planification d’itération divise les objectifs de l’itération en tâches
plus petites, généralement sans plus d’un jour ou deux. L’idée étant de favoriser des plus
petites mises à jour plus fréquentes afin de favoriser un affûtage de la vision de ce qui est
à développer tout en collaborant avec l’utilisateur final de la solution.
La méthode Scrum ayant été précédemment détaillée, nous proposons d’introduire les
principes de mise à l’échelle avec le cadre Nexus qui est un prolongement de la méthode
Scrum. Un projet organisé via la méthode Nexus est composé d’une équipe d’intégration
68
(Nexus intégration team dans le schéma ci-dessous) et d’environ trois à neuf équipes
Scrum. Ce cadre méthodologique apporte des nouveautés dans le fonctionnement qui est
complété par de nouveaux rôles, rituels et artefacts. Selon Ken Schwaber, auteur de guide
Nexus :
Au niveau de la gestion des exigences : toutes les équipes Scrum sont censées utiliser
le même carnet d’exigences nommé Backlog produit. Au fur et à mesure que les éléments
du Backlog Produit sont affinés et préparés, chaque équipe se met ainsi d’accord sur ce
qu’elles vont développer autour d’un Nexus Sprint planning meeting. La gestion des
exigences de haut niveau est maintenue dans : le Backlog Sprint Nexus. Puis toutes les
équipes Scrum maintiennent leur Backlog Sprint individuel.
Au niveau des rituels : des événements sont ajoutés, pour compléter les événements
initialement proposés dans Scrum. Ainsi modifiés, ils servent à la fois l’effort global des
équipes Scrum dans Nexus et chaque équipe individuelle.
- Daily Scrum Nexus : chaque équipe est représentée par deux ambassadeurs qui
viendront exposer le travail réalisé à l’ensemble des autres ambassadeurs, une fois
par jour. Le but sera de partager un maximum d’informations entre les équipes
(voire les problèmes rencontrés)
- Sprint Review Nexus : l’ensemble des équipes se retrouvent avec le Product
Owner pour présenter l’ensemble du produit réalisé. Des ajustements de Backlog
pourront d’ailleurs être proposés à ce moment-là.
- Retrospective Nexus : les ambassadeurs de chaque équipe et l’équipe
d’intégration feront ensemble une rétrospective globale du Sprint qui se termine.
Dans la méthode Nexus, l’accent est donc mis sur une synchronisation des équipes
autour du fonctionnement en Sprint. Les équipes sont plutôt des features teams où la
pluridisciplinarité et le développement est orienté sur les fonctionnalités à développer.
Les nouveaux rituels justifient la volonté de favoriser un fonctionnement entre les
différentes équipes de proximité.
69
La mise à l’échelle de Scrum dans le cadre méthodologique Scaled Agile Framework
(SAFe)
70
1.6 Des entreprises vectrices de nouveaux modes
d’organisation
De nombreuses méthodes ont acquis une certaine notoriété sur les dernières années.
Mais une initiative est régulièrement mise en avant comme modèle ayant inspiré de
nombreuses entreprises dans la mise à l’échelle de la méthode Scrum. Il s’agit du modèle
d’organisation créé chez Spotify.
Le modèle Spotify a été créé pour favoriser un meilleur fonctionnement des équipes de
développement. Confrontée à une croissance forte l’entreprise s’est retrouvée à devoir
intégrer de plus en plus de collaborateurs dans de nombreuses équipes. Le modèle est par
définition une organisation « légère », et fournit un instantané d’un modèle en évolution
rapide (Dingsoeyr et al., 2019).
Synthèse du fonctionnement
La tribu (tribe) : est un ensemble d’escouades travaillant dans des domaines connexes.
Chez Spotify, une tribu travaille principalement sur une fonctionnalité précise de
l’application telle que le lecteur de musique ou les listes de lectures. Les tribus doivent
selon Henrik Kniberg, comporter au maximum 100 personnes, ce choix s’explique en
référence au nombre de Dunbarj. Chaque tribu a un responsable devant faire preuve d’un
maximum de leadership pour accompagner les escouades au sein de cette tribu.
Le nombre de Dunbar est le nombre maximum d’individus avec lesquels une personne peut entretenir
j
simultanément une relation humaine stable. Ce nombre est estimé par l’anthropologue britannique Robin
Dunbar entre 100 et 230 personnes et a une valeur admise en pratique de 150 personnes.
71
escouades d’une tribu sont toutes physiquement dans le même bureau, de sorte à
favoriser la collaboration entre les escouades.
Chapitre (chapter) : Les acteurs ayant les mêmes rôles au sein des différentes équipes
comme les développeurs, testeurs, se retrouvent autour d’un chapitre. Ils peuvent ainsi
partager leurs connaissances et créer des outils au profit de toutes les escouades. Chaque
chapitre est organisé par un responsable (Chapter lead).
Guildes (guild): Une guilde est une « communauté d’intérêts » transversale entre tribus.
Il s’agit d’un groupe de personnes qui souhaitent partager des connaissances, des outils,
du code et des pratiques.
72
donc en ce sens que le modèle est caractérisé de « colonne vertébrale », car le
fonctionnement laisse place à la mise en œuvre de nombreuses autres pratiques.
Les méthodes agiles ont pris une telle place dans les organisations projet, que la
terminologie management de projet agile a connu une certaine fulgurance (Highsmith,
2002; Lee and Yong, 2010; Conforto, Rebentisch and Amaral, 2014; Conforto et al., 2016).
Il nous paraît donc important de reprendre les travaux clés en management de projet pour
mieux comprendre les « transferts » de connaissances qui s’établissent au sein des
institutions garantes des bonnes pratiques de gestion de projet.
k https://www.ing.com/Newsroom/News/Squads-sprints-and-stand-ups.htm
lhttps://www.lemagit.fr/etude/La-Societe-Generale-en-route-vers-lagilite-a-lechelle
m https://www.lemagit.fr/etude/Comment-Axa-a-imite-avec-succes-le-modele-Spotify-pour-aller-
vers-l-Agile-at-Scale
73
plusieurs auteurs ont proposé de caractériser les différentes phases historiques ayant
conduit à la reconnaissance du « management par projet » Gareis (1989).
- « Le degré zéro » : qui, émerge au début du 20e siècle, inclue toutes les initiatives
d’entreprises, d’autorités publiques ou même de certaines figures d’entrepreneur comme
Henriy Ford. Dans le degré zéro, « chacun vit dans son splendide isolement convaincu, de
l’extrême singularité de son expertise » selon (Navarre, 1993). Les méthodes et les
techniques de gestion de projet sont maîtrisées par les ingénieurs et les savoir-faire sont
détenus par quelques entreprises isolées qui n’ont pas standardisé ni diffusé leurs
processus et leurs outils (Garel, 2003).
Plusieurs modèles s’établissent dans l’histoire pour mieux qualifier les différentes
initiatives de conception par les projets (Midler, 1998). En reprenant les travaux de
Christophe Midler et de Christian Navarre, Garel (2003, 2011) propose une typologie de
synthèse autour de quatre modèles :
- le modèle séquentiel, caractérisé aussi comme modèle taylorien : repose sur une
intégration dans une entreprise de la plupart des expertises nécessaires au
développement d’un projet (designer, ingénieurs, commerciaux, etc.). Il s’agit là de
séparer les expertises entre différents métiers favorisant une coordination procédurale
et hiérarchique des expertises en vue de réaliser le projet. La coordination des différents
métiers se fait dans une logique séquentielle où les différents acteurs interviennent
74
successivement dans la réalisation du projet. Nous pouvons faire allusion au modèle en
cascade dans la conception de logiciels.
75
Figure 17 : Modélisation du cycle projet séquentiel (type A) et cycles concourants
(Types B et C)
À partir des travaux de Takeuchi & Nonaka (1986), Garel (2003) résume les principes
managériaux de l’ingénierie concourante (Navarre, 1993) précisant que la performance
de l’ingénierie concourante résulte principalement d’une capacité de coordination
permettant la réduction du délai de développement des projets. La direction de projet se
révèle être lourde, car les projets concourants sont dirigés par des chefs de projet dédiés
dont l’influence est importante dans l’organisation.
Nous avons pu voir dans l’analyse historique de la méthode Scrum dans la section 1.2
que ses créateurs ont été inspirés par les travaux de Takeuchi et Nonaka (1986) sur de
nombreux aspects. D’une part le nom « Scrum » provient directement de l’article présenté
par les deux auteurs japonais et nous avons pu caractériser la méthode par le biais d’un
d’un cycle de conception itératif et incrémental tout en intégrant un fonctionnement
concourant dans chaque itération (figure 18). De plus, une des propriétés particulières du
cycle de conception proposé dans la méthode Scrum concerne l’adaptabilité. Chaque
itération conduit à la proposition d’une version de produit qui peut être potentiellement
76
considéré comme terminé ou à améliorer. Puis, à chaque itération les différents acteurs
impliqués dans un projet en mode Scrum peuvent prendre la décision d’arrêter le projet
s’ils jugent que ce dernier remplit tous les besoins.
Une tendance assez récente dans la diffusion des modes de fonctionnement issus des
méthodes agiles porte la prise en compte des principes précédemment évoqués dans les
référentiels de gestion de projet. Les principaux référentiels de gestion de projet utilisés
par de nombreuses organisations sont les référentiels du PRINCE 2, PMBoK et l’Individual
77
Competence Baseline (ICB)n. Comme l’illustre le tableau 7, ces trois référentiels ont été
mis à jour pour intégrer les principes de fonctionnement véhiculés dans les méthodes
agiles. Le PMI a par exemple collaboré pour la sixième version de son référentiel avec
l’Agile Alliance, ce qui a donné lieu à la création d’une extension au PMBoK nommée Agile
practice guide.
D’autre part, les méthodes agile projet management et agile programme management
ont récemment émergé de la collaboration entre l’APMGo et le consortium Dynamic
Systems Development Method (DSDM). Il s’agit d’une mise à jour et d’une extension de la
méthode DSDM créée en 1994. CE virage se révèle particulièrement intéressant puisqu’il
traduit d’une certaine manière la volonté des organismes d’appartenance de ne plus se
limiter aux projets SI.
Date de la
N° Nom du référentiel Organisme d'appartenance
création
1 Agile Project Management 2014 Agile Business Consortium - APMG
2 Agile programme management 2014 Agile Business Consortium - APMG
3 Prince 2 Agile 2015 Axelos
4 PMBoK V6 - Agile Practice Guide 2017 Project Management Institute
5 Individual Competence Baseline V4 2018 IPMA
Tableau 7 : Liste des référentiels de gestion de projet intégrant les principes de
fonctionnement issus des méthodes agiles
n Édité par l’international Project Management Association, celui-ci porte plus sur un corpus de
connaissances autour des compétences des managers de projet.
o L’APMG est un organisme d’accréditation et de certification fortement présent dans le paysage du
78
historiques en management de projet et les associations autour des guides et
certifications des approches agiles. Ces dernières sont nombreuses (Agile Alliance, le site
Scrum.org, le site Scrum Alliance ou le Scaled Agile Inc.) et jouent un rôle crucial dans la
diffusion des méthodes agiles entre les organisations. Le rachat de Disciplined Agile par
le PMI n’est donc pas neutre dans la discipline puisque le PMI tend de plus en plus à faire
évoluer son référentiel. Cette floraison d’organismes certificateurs semble ainsi avoir une
influence dans la fréquence de mise à jour des différents corpus de connaissances.
Nous retenons pour nos travaux deux points. Premièrement, il nous paraît important
de retenir la dynamique en œuvre autour de la mise à jour des référentiels historiques de
gestion de projet. Comme les associations éditant ces référentiels certifient énormément
de praticiens au niveau international, elles jouent un rôle crucial dans la diffusion des
pratiques qu’elles véhiculent. Deuxièmement, compte tenu de l’importance des méthodes
agiles de gestion de projet, il s’avère utile de comprendre les mécanismes en œuvre dans
les grandes organisations pour choisir, adopter et généraliser une nouvelle méthode.
C’est donc avec cette problématique clés que de nouveaux référentiels sont nés ces
dernières années dont l’objet n’est plus de fournir un cadre de fonctionnement
uniquement dédié aux équipes de développement « techniques », mais plutôt aux acteurs
79
des unités d’affaires, désignant ainsi les futurs utilisateurs. Le tableau 8 ci-dessous
regroupe à titre d’exemple certains des référentiels qui ont récemment émergé.
Parmi les premiers acteurs à s’être lancés sur le sujet, un consortium de praticiens a
créé la XScale Alliance. Le référentiel Xscale accessible sur le site internet est un guide
créé pour étendre les principes de fonctionnement dicté dans les méthodes agiles à un
plus grand nombre d’acteurs des entreprises.
Le guide Open Space Agility est assez similaire dans le fond, car il s’agit d’un référentiel
permettant de faciliter l’adoption des approches agile. Le guide donne des principes pour
construire sa propre stratégie de déploiement des méthodes agiles. Celui-ci a donc été
créé pour fonctionner avec les approches initialement adoptées par les organisations et
propose des rituels pour favoriser la mise en œuvre des méthodes agiles. L’objectif est
d’impliquer tous les acteurs concernés d’un DSI et des unités d’affaires par exemple.
Agileshift est aussi sur ce périmètre. Créé par Axelos en 2018, il permet de donner aux
praticiens des principes pour comprendre, dialoguer et défendre les changements induits
par l’adoption des méthodes agiles. Ce guide est destiné à des praticiens recherchant des
techniques de conduite du changement lié à l’adoption d’une méthode agile. Toutes ces
différentes propositions sont des initiatives assez récentes ayant été peu étudiées par au
niveau académique. L’une des raisons s’explique par le faible niveau de mise en œuvre
par les praticiens. Nous retenons donc le besoin d’investiguer plus en profondeur la
manière dont les organisations conduisent le changement lié à l’adoption généralisée
d’une méthode agile.
80
Synthèse du chapitre 2
Ce chapitre retrace les différentes générations des méthodes de conception des SI développées au
cours des 20 dernières années en analysant les attributs qu’elles ont en commun (Figure 13). La première
catégorie concerne les approches à petite échelle, qui font référence aux premières générations
d’approches développées dans les années 1990. Elle regroupe les méthodes du type Scrum, Kanban,
eXtreme Programming et toutes les autres méthodes ayant été créées pour des petites équipes (4 à 9
personnes en général). Ces approches se caractérisent principalement par un cycle de conception itératif,
incrémental, adaptatif et concourant.
La seconde vague d’émergence concerne l’extension d’usage des méthodes agiles de première
génération pour les projets de plus grande ampleur. Il s’agit d’une catégorie d’approches créées pour
étendre les pratiques de fonctionnement proposées par les méthodes de première génération à l’échelle
de plus grande équipes projet SI. Nous faisons référence ici aux méthodes : Scrum of Scrum (Sutherland,
2001), Scaled Agile Framework (SAFe) (Leffingwell 2007); Large Scale Scrum (LeSS) (Larman & Vodde
2014) ; Disciplined Agile Delivery (DaD) (Ambler 2012). Ces approches se caractérisent essentiellement
par l’organisation de plusieurs équipes autour de la création d’un produit commun.
Trois tendances récentes ont donné lieu à l’émergence de nouvelles catégories d’approches. D’une
part, en s’inspirant des modèles de fonctionnement proposés par les méthodes de première et seconde
génération, des entreprises ont développé des modes d'organisation particulièrement novateurs. C’est le
cas du modèle Spotify ou de la Banque ING direct aux Pays-Bas (Birkinshaw, 2017).
Ces dernières années ont aussi été le théâtre du rapprochement des méthodes agiles aux
méthodologies traditionnelles de gestion de projet. Les cadres traditionnels ont commencé à réadapter
leurs référentiels en intégrant plus ou moins les principes de fonctionnement de certaines approches.
Parmi ceux-ci, il est possible notamment de citer la 6e version du Project Management Body of Knowledge
édité par le Project Management Institute. La tendance s’accentue avec le second référentiel classique de
gestion de projet nommé Prince 2 dont l’organisation de rattachement nommé Axelos a proposé une
version Prince 2 agile.
Compte tenu de cette dernière tendance tout en sachant que les méthodes agiles ont une forte
exposition à l’adaptation dans les organisations. Il nous paraît donc judicieux d’investiguer la manière
dont une organisation entreprend l’adoption d’une méthode de gestion de projet agile.
81
Développement
séquentiel Développement
itératif,
Vers des méthodes agiles pour
Conception incrémental et Mise à l'échelle pour les
les petites équipes
sauvage adaptatif grands projets
30 50 70 80 89 91 95 96 98 99 01 01 03 03 05 07 09 11 12 14 15 17 18
Figure 19 : Synthèse historique des différentes méthodes agiles et référentiels de gestion de projet
82
Chapitre 3 : L’adoption des méthodes agiles :
un état de l’art
Chapitre 1 Chapitre 2
Historique des approches de Présentation et analyse du
conception de logiciels paradigme des méthodes agiles
Chapitre 3 Chapitre 4
L’adoption des méthodes agiles : L’adoption des méthodes agiles
un état de l’art au travers du prisme des outils de
gestion
INTRODUCTION ............................................................................................................................................... 84
1. L’ADOPTION DES METHODES DE PREMIERE GENERATION ...................................................................................... 85
1.1 L’adoption des méthodes agiles dans les équipes de développement ............................................. 85
1.1.1 L’introduction et l’expérimentation ..................................................................................................... 85
1.1.2 L’adaptation versus l’adoption fidèle ................................................................................................... 87
1.2 Les effets de l’adoption des méthodes de première génération ...................................................... 88
1.3 Les modèles d’adoption et d’adaptation .......................................................................................... 91
1.4 Le croisement des méthodes agiles aux méthodes traditionnelles .................................................. 93
1.4.1 Les méthodes agiles alliées aux cycles de développement séquentiel ................................................ 93
1.4.2 Les méthodes agiles alliées aux référentiels de management de projet classique .............................. 94
1.5 La mise en œuvre dans les grands projets ....................................................................................... 94
1.5.1 Les pratiques de mise à l’échelle identifiées ........................................................................................ 95
2. LE DEPLOIEMENT DES METHODES AGILES DANS LES ORGANISATIONS ....................................................................... 98
2.1 Les cas de transition étudiés ............................................................................................................ 99
2.2 Les barrières justifiant la nécessité d’une transition ...................................................................... 102
2.3 Les déterminants de la transition ................................................................................................... 104
83
Introduction
Les méthodes agiles ont, comme nous avons pu le voir précédemment, convaincu de
nombreux acteurs professionnels (VersionOne, 2018). Les différentes communautés de
praticiens rassemblées autour des organismes certificateurs sont d’autre part
conséquentes. Ces aspects nous permettent de considérer l’importance des recherches
devant être menées pour expliquer les différents phénomènes qui en découlent.
D’un point de vue académique, les recherches connaissent aussi une croissance
soutenue dans le traitement du sujet. La revue de littérature menée par Dingsøyr et al.,
(2012) a permis d’identifier 1551 papiers publiés entre 2001 et 2010 traitant des
méthodes agiles. La revue de littérature menée par Diegmann et al. (2018), permet de plus
d’identifier l’intérêt croissant des chercheurs en SI. Le nombre d’articles de journaux et
de documents de conférence a d’autre part augmenté régulièrement jusqu’en 2010 (Nerur
& Moe, 2012). Il est aussi intéressant de constater le nombre de contributions faites dans
la littérature en management de projet (Conforto et al., 2014, 2016).
Si le sujet des méthodes agiles semble être traité de façon soutenue, la littérature se
polarise essentiellement autour de l’adoption des méthodes de première génération dans
les équipes de développement. De nombreuses critiques demeurent aussi dans les
analyses proposées par les chercheurs au sujet des faibles fondations théoriques dont font
preuve les articles (Conboy, 2009). Bien que des initiatives ont été mises en place ces
dernières années dans les conférences internationales pour organiser les thématiques de
recherche (Barroca et al., 2019; Dingsøyr, Moe, et al., 2014; Moe et al., 2016), il figure que
l’ensemble des recherches sont très hétérogènes dans le traitement des différentes
problématiques liées à l’adoption des méthodes agiles (Abrahamsson et al., 2009).
84
1. L’adoption des méthodes de première
génération
En raison du substrat technique inhérent aux méthodes agiles qui s’explique par leur
provenance de la sphère du développement de logiciel, c’est logiquement dans les
départements système d’information que ces approches sont adoptées et c’est, via ces
mêmes départements qu’elles se diffusent auprès d’acteurs en dehors des DSI (Conforto
et al., 2016).
La principale tendance dans les travaux portant sur l’adoption des méthodes agiles se
révèle être mitigée. En effet, les résultats mentionnent dans bien des cas de nombreuses
difficultés pour les équipes de développement dans la mise en œuvre de ces « nouvelles »
formes d’organisation (Boehm & Turner, 2005; Chan, 2009; Hajjdiab & Taleb, 2011).
Dans la première décennie des années 2000, l’introduction des méthodes agile dans les
équipes pouvait être freinée par leur manque de notoriété. Les développeurs préféraient
85
les approches classiques ayant atteint un fort ancrage dans les organisations (Hajjdiab et
Taleb, 2011).
Cohn & Ford, (2003) évoquent que les développeurs peuvent présenter des
résistances s’exprimant par une réticence dans la mise en œuvre de nouvelles méthodes
si l’expérimentation est imposée. Les auteurs prennent par exemple un projet dans lequel
un responsable contraignait les membres de l’équipe de développement à utiliser Scrum.
Pour contrer les difficultés d’introduction liées à la faible notoriété, plusieurs auteurs (B.
Boehm, 2002; Moore & Spens, 2008) proposent de mobiliser « une poignée d’acteurs » les
plus motivés d’une organisation afin de sensibiliser le reste des collaborateurs. Une
sensibilisation progressive peut ainsi faciliter le changement pour les différentes équipes
de développement. Lors de la première utilisation de Scrum, certaines équipes sont par
exemple submergées au point de ne rien faire face à la liberté de ne pas disposer d'un
diagramme de Gantt quotidien (Cohn & Ford, 2003; Mahanti, 2007).
Au cours de la première décennie des années 2000, l’introduction des méthodes agiles
dans les organisations s’est fortement accentuée. Comme nous l’avons vu précédemment,
l’une des raisons réside dans les bénéfices perçus par les premiers adopteurs. Il s’avère
que l’un des principaux constats ayant contribué à la notoriété des méthodes agiles réside
dans la capacité d’une équipe à être très réactive tout en fournissant des logiciels de
qualité répondant aux besoins des clients plus rapidement (Ågerfalk et al., 2009; L.
Vijayasarathy & Turk, 2012). Ceci créer de concert, une « promesse » de productivité plus
forte de la part des équipes de développement. (Vijayasarathy & Turk, 2008).
Dans leurs récents travaux, Cram & Newell (2016) mettent en valeur le fait que la
décision d’introduire une méthode agile dans une organisation de nos jours est fortement
influencée par le phénomène de mode qu’elles constituent. Les bénéfices clés identifiés
ont de raison leur rapide diffusion dans les équipes. D’autre part, Cram & Newell (2016)
distinguent 3 types d’adoption : l’adoption croisée, caractérise une adoption mixant
plusieurs méthodes, comme l’alliance des méthodologies du type Scrum et XP. Il y a
ensuite l’adoption « sur-mesure », faisant allusion à des organisations adaptant les
méthodes « traditionnelles » aux méthodes agiles. Et, il y a enfin l’adoption des « débutants
» qui concerne les organisations mettant en place seulement quelques pratiques alliées
aux méthodologies traditionnelles.
Dans la lignée de la proposition Boehm & Turner, (2005), nous considérons ainsi que
l’adoption d’une méthode se déroule de prime abord par la volonté d’une équipe de
développement de mettre en œuvre une nouvelle approche de conception dont l’objectif
est d’atteindre de nouvelles performances de productivité.
86
1.1.2 L’adaptation versus l’adoption fidèle
Pour Ågerfalk et al., (2009), l’adoption des méthodes agiles repose essentiellement sur
le principe d’introduire «juste assez de méthode» pour piloter un projet. C’est la raison
pour laquelle elles reposent sur une formalisation plus « ouverte » par rapport aux
méthodes dites traditionnelles (Highsmith, 2002). Néanmoins, des travaux révèlent que
les méthodes agiles sont dans les faits rarement adoptées de manière fidèle (Boehm &
Turner, 2003b). Cao et al., (2009a) définissent l’adaptation comme l'ajout, l'abandon ou la
modification de pratiques spécifiques prescrites par des méthodes agiles.
Toujours selon Cao et al. (2009a), l’adoption passe essentiellement par une adaptation
influencée par l’environnement organisationnel. Ils relèvent notamment que : les
caractéristiques du projet ; les exigences et pratiques organisationnelles considérées comme
des normes internes ; l’expérience des membres de l’équipe du projet et son attitude à l’égard
de la démarche de développement, constituent des sources d’influence dans l’adaptation.
L'utilisation réussie des méthodes agiles dépend donc de la nature du projet, des tâches à
réaliser et de l'organisation (Rasnacis & Berzisa, 2017).
Pour les grands projets complexes et critiques au niveau de la sécurité par exemple, les
modes de fonctionnement doivent être adaptés pour pouvoir être appliqués efficacement
(Campanelli et al., 2018). Ainsi 4 types de sources d’influence sont relevées par les auteurs
:
L’adaptation des méthodes agiles dans un usage étendu pose cependant une question
cruciale tant auprès des chercheurs que chez les praticiens. L’adaptation étant un fait
inévitable : quel serait le niveau de modification acceptable dans l’adaptation des
différentes méthodes pour toujours considérer un fonctionnement agile ? Dans la
préservation d’un mode de fonctionnement performant, la question du degré
d’adaptation se révèle essentielle pour certains chercheurs (Javdani Gandomani & Ziaei,
2014). Nous verrons dans les prochaines sections les propositions de modèles proposant
différents niveaux d’adaptation.
87
1.2 Les effets de l’adoption des méthodes de première
génération
L’introduction des méthodes de première génération dans les équipes de
développement et plus généralement dans les organisations ne se fait pas sans heurts. De
nombreuses études portent sur les impacts liés à l’adoption des différentes méthodes
agiles. Nous proposons donc de dresser les effets constatés par les chercheurs dans cette
sous-section.
L’adoption d’une méthode agile a des répercussions de différentes natures sur les
configurations d’équipes (Dwivedi, 2013). Coram (2005), différencie les répercussions
sur les individus impliqués dans un projet, les processus via lesquels un projet est
développé, et sur le projet lui-même. Au niveau des individus : les acteurs les plus
impactés par l’adoption d’une méthode agile sont les développeurs (tableau 9). Ces
résultats se confirment avec l’analyse de Inayat et al., (2015) qui précisent que le
changement de fonctionnement est conséquent pour ces acteurs.
88
Les développeurs doivent selon Highsmith, (2002) être prêts à travailler en toute
transparence et être capables de gérer les changements constants. Ils doivent aussi
acquérir la faculté de gérer les problèmes rencontrés dans un contexte d’incertitude forte.
Ainsi les acteurs peu expérimentés peuvent éprouver des difficultés dans ce mode de
fonctionnement (Boehm et Turner, 2004).
Mahanti (2007), précise que les freins du point de vue des individus se traduisent par
un état d’esprit fermé à la mise en œuvre de nouvelles méthodes. La bureaucratie régnante
dans les organisations et les compétences spécialisées, notamment l’expertise des
individus dans les équipes projet empêche la bonne adoption. Au niveau des processus de
conception, les méthodes agiles engendrent un réel changement pour les entreprises avec
un niveau de maturité élevé (niveau CMMI 3 ou 4). Il est parfois plus difficile pour ce genre
d’organisation de changer de méthode en raison de leur comportement rigide et solide
dans les modes de fonctionnement ayant pris du temps à s’établir (Babuscio, 2009). Le
passage d’un mode de conception à un autre se révèle être une vraie transition pour les
équipes et l’organisation.
La gestion des exigences se révèle être difficile dans les équipes. Les méthodes agiles
préconisent une gestion des exigences dynamique en prenant en compte les retours des
futurs utilisateurs dans une fréquence assez forte. Ainsi, les équipes doivent constamment
planifier, estimer et délivrer des exigences dans des rythmes assez courts lors des
itérations. Le passage en mode agile contraint ainsi les équipes à devoir adapter leur
rythme de fonctionnement, ce qui peut être vécu difficilement par les individus (Cho,
2008; Van Waardenburg & Van Vliet, 2013).
Drury-Grogan (2014), mets en valeur dans ses travaux six obstacles majeurs liés à la
prise de décision dans les équipes projet. L’agilité prônant un mode de fonctionnement
basé sur des décisions partagées entre les membres d’une équipe, des tensions peuvent
s’installer lorsqu’un acteur non intégré à l’équipe impose une décision. Les priorités des
travaux peuvent être contradictoires entre les chefs de projet et l’équipe de
développement. En outre, la prise de décision de groupe peut d’autre part se révéler
difficile en cas de manque d’implication des différents acteurs d’un projet. Le fait de
conserver un rôle de chef de projet et une équipe autoorganisée sans une réelle
sensibilisation se traduit comme des difficultés dans l’adoption des méthodes agiles.
89
La prise de décision dans les projets mobilisant des méthodes agiles se caractérise par
des séquences de décisions multiples. L’étude de McAvoy & Butler (2009) montre que le
niveau élevé d'autonomisation d'une équipe de développement de logiciels est un facteur
négatif pour la prise de décision projets. Les équipes autonomes peuvent développer des
pensées de groupe pouvant conduire à de mauvaises décisions. Le rôle de chef de projet
dans les initiatives de développement agile doit ainsi être réévalué pour atteindre un
certain niveau d’implication et d’équilibre dans la prise des bonnes décisions (Drury,
Conboy & Power, 2012).
L’autonomie des équipes est l'un des éléments essentiels dans le manifeste agile, Hoda,
(2011) souligne que le choix des bons acteurs pour composer une équipe autoorganisée
est un défi. En outre, plusieurs obstacles ont été signalés au sujet de certains rôles
spécifiques dans les équipes agiles. Par exemple, les chefs de projet, en particulier ceux
qui ont de l'expérience dans le développement de logiciels traditionnels, ne peuvent pas
oublier facilement leur rôle antérieur de commandant dans les méthodes traditionnelles
tout en faisant preuve de plus de leadership. Le changement d’état d’esprit des acteurs
senior dans les projets se révèle être un frein pour au niveau des dynamiques de groupe
(Cohn & Ford, 2003).
Shastri, Hoda & Amor, (2017) ont identifié quatre rôles devant être pris en compte par
les différents responsables et chefs de projet au sein d'équipes travaillant avec une
méthode agile. Ils doivent agir en tant que mentors, le responsable doit devenir un guide
et un soutien pour l'équipe en facilitant le mode de fonctionnement. Le rôle de
coordonnateur se caractérise par le fait que le chef de projet doit faciliter et coordonner le
fonctionnement des équipes. Le rôle de négociateur tient compte de la gestion des budgets
et des exigences client. Enfin ce genre d’acteurs doivent œuvrer comme « adaptateur » des
processus, ils doivent avoir la capacité d’adapter les modes de fonctionnement entre les
approches traditionnelles et agiles.
Les travaux que nous venons d’aborder nous permettent de mieux illustrer certaines
caractéristiques du processus d’adoption des méthodes agiles au niveau des équipes
projet. Nous retenons par ailleurs que le changement de mode de conception nécessite de
90
mettre en place une organisation apprenante permettant d’adapter et d'intégrer les outils
et des pratiques agiles au niveau des équipes projet (Khalil, Fernandez & Houy, 2013).
En réponse aux faibles orientations proposées par les praticiens dans l’adoption des
méthodes agiles, Sidky et al., (2007) proposent un cadre pouvant être utilisé comme une
approche structurée à l’adoption. Le modèle comprend deux composants principaux :
l’indice de mesure agile Sidky (nommé SAMI) pour évaluer la capacité d'une organisation
à devenir agile. Puis, sur la base de cet indice, le modèle définit un cadre d’adoption pour
les équipes projet. Sur la base du degré d’évaluation potentiel mesuré, le modèle propose
un ensemble de pratiques à mettre en place suivant différents niveaux de maturité.
91
Cao et al., (2009b) ont proposé un cadre basé sur la théorie de la structuration
adaptativep (Jones & Karsten, 2008). Le cadre étudie l'adaptation des méthodes au sein
d’une organisation en tenant compte des caractéristiques du projet et de l'organisation.
Les auteurs présentent quatre catégories de motifs poussant à l'adaptation des méthodes
agiles au sein d'un projet : les motifs reliés au processus de développement, au client, aux
développeurs ainsi qu'à l'organisation et au management.
Les projets dans les grandes organisations sont de plus en plus menés par des équipes
distribuées géographiquement. Sureshchandra & Shrinivasavadhani (2008) ont proposé
un cadre d’adoption dans ce genre de cas. Le cadre est soutenu par un outil, basé sur les
travaux de Boehm & Turner (2003), pour évaluer le degré d'agilité et de formalisation
nécessaire pour un projet. Il se déroule en quatre étapes :
Enfin, un des modèles qui nous paraît être le plus pragmatique est celui proposé par
McAvoy, Sammon et Owens (2007). Ils proposent un outil d’aide à la décision pour choisir
une méthode. Le modèle comporte 10 facteurs contextuels pour affiner les choix dans
l’adoption d’une méthode. Ces facteurs nous paraissent être les plus pragmatiques par
rapport aux précédents modèles. Ils permettent selon les auteurs d'établir la base pour
une discussion sur la pertinence d'adopter une méthodologie agile dans le cadre d'un
projet de développement logiciel. Les facteurs critiques d'adoption sont divisés en quatre
groupes comprenant : la taille du projet, les acteurs assignés au projet, la présence du
client pour lequel le projet sera livré et les paramètres organisationnels dans lesquels le
projet est entrepris.
pLa théorie de la structuration adaptative (AST) modélise les façons dont une technologie est adaptée à
une organisation et comment les structures organisationnelles s'adaptent à la technologie.
92
Comme Rohunen et al., (2010) l’analysent, la plupart des modèles d’adoption proposés
comportent trois caractéristiques communes :
- les modèles proposent d’extraire les pratiques issues de toutes les méthodes
agiles ;
- Ils préconisent une adoption itérative pour adopter des pratiques au fur et à
mesure au niveau dans les projets ;
- Puis chacun des modèles propose un indice de mesure pour évaluer le degré de
maturité de l’équipe de développement.
La principale critique à laquelle sont exposés ces modèles repose sur le fait que les
analyses mobilisées dans l’adoption et l’adaptation d’une méthode ne se font qu’au niveau
des équipes ou des projets. Or il nous paraît important de mieux comprendre la
dynamique d’ensemble des projets puisque des phénomènes de dépendances et de
collaboration entre plusieurs projets peuvent s’établir. Ces précédents travaux négligent
d’autre part les parties prenantes (différents métiers) censées collaborer avec une équipe
de développement.
Les travaux de Port & Bui (2009) sont parmi les premiers à avoir proposé une approche
scientifique du croisement des méthodologies. Basés sur les travaux de Boehm et Turner,
(2004), ils proposent deux stratégies pour créer une méthode mixte. L’alliance se fait
principalement dans la gestion des exigences en partant du principe que l’analyse coûts-
bénéfices proposée dans les méthodes séquentielles peut être alliée au développement
itératif, incrémental et adaptatif. D’une part, ils proposent de simplement ajouter l’analyse
coût-bénéfice à l'approche agile adoptée. Puis, ils proposent une approche plus
93
sophistiquée qui module la taille de l'itération pour maximiser la maîtrise des coûts
attendus dans les projets.
Plusieurs chercheurs ont utilisé les principes de l’ingénierie des méthodes dans la
proposition d’hybridation (Campanelli et al., 2018; Dwivedi, 2013). La construction de
l’Hybrid Adaptive Methodology Reference Architecture (HAMRA) en est un exemple. Il est
défini comme un méta modèle permettant l’analyse empirique, constructive et qualitative
d’une méthode « hybride ». Il vise à permettre aux équipes de développement la création
de configurations contextuelles des méthodologies agiles en identifiant un nombre
restreint de pratiques de travail à mettre en œuvre (Gill, Henderson-Sellers et Niazi,
2018).
Cette définition est nourrie par les travaux lancés plus tôt dans l’intégration de
pratiques issues des méthodes agiles alliées aux méthodes gestion de projet classique.
Conforto & Amaral (2010) ont à cet effet développé une méthode alliant gestion de projet
et développement itératif. Nommée Iterative and Visual Project Management Method
(IVPM2), les auteurs l’ont développé dans le cadre d’une recherche intervention pour le
compte d’une entreprise au brésil. Ils proposent une approche pragmatique en
conservant le cycle de vie classique de gestion de projet à savoir la planification, le
développement et le déploiement, tout en intégrant un fonctionnement itératif et
incrémental avec des rituels inspirés par la philosophie du manifeste agile.
94
méthodes de seconde génération se diffusent réellement dans les organisations. De
nombreuses études ont porté sur la mise à l’échelle des méthodes de première génération
pour de plus grands projets (Kalenda, Hyna et Rossi, 2018).
Comme nous l’avons présenté dans le chapitre précédent, les méthodes agiles de
première génération ont été adaptées pour coordonner un plus grand nombre d’acteurs.
Cependant, cette nouvelle génération a mis du temps à se diffuser dans les entreprises
(Alqudah & Razali, 2016a). Les travaux dans la mise à l’échelle portent dans de nombreux
cas autour de l’extension de la méthode Scrum (Paasivaara et al., 2008, 2012; Sutherland,
2001a).
Les autres cadres méthodologiques d’agilité à l’échelle sont plus considérés comme des
« boîtes à outils ». Sur les 42 cas analysés par Gustavsson, (2017), seulement 4 ont suivi
les mises en œuvre de rôles suggérées à partir des cadres méthodologiques d’agilité à
l’échelle. Du point de vue des praticiens, Gustavsson, (2017) précise que ces cadres ne
sont pas considérés comme prescriptifs, ils sont plutôt considérés comme des boîtes à
outils avec lesquelles les organisations composeront leur propre mode de
fonctionnement. Ce phénomène se confirme de la même manière par rapport à l’adoption
des méthodes de première génération. L’adoption des méthodes agiles pour de plus
grandes équipes semble se caractériser par une déconstruction-reconstruction des
pratiques véhiculées dans les différentes méthodes (Conboy & Fitzgerald, 2010).
95
L'application de méthodologies agiles dans les grands projets soulève le défi de la
complexité engendré par un nombre beaucoup plus élevé d'intervenants. Ces acteurs
proviennent naturellement d'un contexte organisationnel plus large conduisant ainsi vers
la mise en place d’équipes multiples, interdépendantes, et travaillant ensemble sur un
objectif commun (Bick et al., 2018).
Les pratiques de mise à l’échelle des méthodes agiles portent sur la mise en place d’une
coordination de plusieurs équipes. Pour éviter les écueils dans ce fonctionnement, les
travaux de Paasivaara & Lassenius (2016a) insistent sur l’importance de mettre l'accent
dans la définition de valeurs communes entre les différentes équipes. La mise en œuvre
d'ateliers portant sur les valeurs et principes de fonctionnement a permis de combler ce
manque dans le cas analysé. Cet alignement se révèle particulièrement important dans le
développement à grande échelle, car les équipes peuvent avoir des degrés de liberté
significatifs en décidant de leur fonctionnement. Définir et communiquer des valeurs et
des principes de fonctionnement commun peut guider les équipes dans le cadre d’une
collaboration à grande échelle.
La mise en œuvre des communautés de pratiques est un dispositif mis en place dans
plusieurs cas pour soutenir l’adoption dans plusieurs équipes. Kahkonen, (2004) précise
que certaines méthodes agiles s’appuient sur des concepts de fonctionnement dont les
guides et référentiels précisent peu la manière dont elles doivent être mises en œuvre.
Les résultats de l’étude de cas menée par Kahkonen (2004), étayent la proposition selon
laquelle, en plus des structures officielles de l'équipe, il devrait y avoir des communautés
de pratiques qui transcendent les frontières des équipes pour favoriser une forme les
partages et apprentissages liés au fonctionnement. La mise en place de communautés de
pratique se décrit comme la mise en œuvre d’une collectivité d’individus assistant à des
ateliers animés comme pratique clé pour gérer les problèmes multi-équipes (Paasivaara et
al., 2013).
96
Les travaux récents menés par Dingsøyr, Moe & Seim (2018) permettent d’approfondir
la compréhension des mécanismes de coordination qui s’établissent dans le
développement d’un grand programme. Ils identifient 22 mécanismes de coordination
classés autour de 3 catégories. Les mécanismes de groupe, considérant la multiplicité des
acteurs où des rituels bien définis sont mis en place par les différentes équipes du
programme pour favoriser les échanges (démonstrations, rencontres par domaine
d’expertises). Les mécanismes individuels caractérisent les interactions entre individus
favorisées par des pratiques telles que le client sur site ou la colocalisation des équipes.
Puis, ils identifient des mécanismes de coordination impersonnels. Ils décrivent par cette
catégorie l’usage d’outils de messageries et de plateformes de management de la
connaissance permettant de favoriser les échanges informels.
Enfin les travaux de Hobbs & Petit, (2017) nous permettent de conclure sur le fait que
les organisations et la taille des projets ont une incidence sur la mise en œuvre et
l'utilisation des méthodes agiles. Les recherches actuelles ont principalement pour objet
d’étude les projets avec peu ou pas de reconceptualisation au niveau des grands projets.
Les principales études portant sur les grands projets nous permettent pour le moment
uniquement d’identifier que les mécanismes de coordination entre les équipes se révèlent
être critiques (Rolland et al., 2016).
Or des questions restent en suspens. Une des analyses qui se révèle être pertinente
pour approfondir les travaux actuels concerne la manière dont une organisation envisage
la mise en œuvre des méthodes agiles pour ses grands projets, sachant que les cadres de
mise à l'échelle qui proposent des solutions à ces niveaux gagnent en popularité (Conboy
& Carroll, 2019).
97
2. Le déploiement des méthodes agiles dans les
organisations
Pendant des décennies, les organisations ont poursuivi sans relâche l'objectif de créer
des processus optimisés pour maîtriser les projets de conception des SI. La stabilité à
laquelle elles aspirent peut constituer une inertie dans le fonctionnement des équipes
projet. Devenant de facto l’un des plus grands obstacles à l'adoption de méthodes agiles
(Cockburn, 2006).
Nous proposons de présenter dans les sections suivantes les défis identifiés dans la
littérature concernant le déploiement des méthodes agiles pour de nombreuses équipes
travaillant d’une organisation. Nous présentons les différents cas étudiés, les barrières
justifiant que le déploiement des approches agiles est une transition majeure pour une
organisation. Puis, nous relèverons les déterminants identifiés dans les différentes études.
Nous présentons les études de cas portant uniquement sur des déploiements au sein de
grandes organisations. En reprenant la définition de Dikert, Paasivaara & Lassenius
98
(2016), un déploiement à grande échelle se caractérise par une organisation ayant pour
cible un minimum de 50 personnes ou 6 équipes. En dessous de cette échelle, les auteurs
considèrent qu’il ne s’agit pas d’un déploiement majeur.
Dans les évolutions organisationnelles, les auteurs illustrent le passage des équipes
initialement composées en component team devenant des features team. La phase
expérimentale s’est composée de la mise en place d’une équipe pilote, une réorganisation
virtuelle des équipes et la création de communautés de pratiques. La seconde phase se
focalisait essentiellement dans la recherche d’un mode de fonctionnement commun à
toutes les équipes. Des ateliers ont rythmé sur les valeurs de coordination et de
fonctionnement ont été mis en place tout au long de la phase. La troisième phase concerne
la mise en œuvre d’équipes organisées pour livrer de manière continue le développement.
Les travaux portant sur l’analyse du cas Ericsson nous permettent d’avoir plus d’éléments
concernant les impacts engendrés par le déploiement des méthodes agiles. De plus, ils
précisent certains dispositifs mis en œuvre pour construire une nouvelle organisation
d’un département R&D.
Parmi les premiers cas de déploiement présent dans la littérature. Le cas de Yahoo !
analysé par Benefield (2008) est l’un des premiers à présenter un périmètre de
déploiement particulièrement large. La volonté s’est nourrie de la nécessité d'adopter des
processus et des pratiques standard pour aider les équipes à livrer de meilleurs produits
plus rapidement. Le premier effort de Yahoo! dans la modification du processus de
développement de logiciels a commencé en 2002 avec la mise en œuvre d’une méthode
basée sur le cycle en V. C’est lors d’une présentation de Jeff Sutherland (créateur de
Scrum), que le responsable du développement de produit chez Yahoo ! prit la décision de
lancer un déploiement de la méthode Scrum de grande ampleur. Cette décision s’explique
99
notamment du fait d’un certain mécontentement lié au dysfonctionnement dans le
développement des produits logiciels développé. C’est en février 2005 que l’entreprise
mit en place une démarche de déploiement composée : d’un projet pilote pour identifier
la bonne approche à adopter, la mise en place d’une équipe de coaching pour
accompagner la volonté du haut responsable dans le déploiement de Scrum et des
formations pour l’ensemble des acteurs. Si les différentes phases ne sont pas expliquées
dans l’étude du cas, une certaine diffusion entre praticiens s’est établie au travers des
différents dispositifs mis en œuvre. Dans les barrières rencontrées, l’entreprise a été
confrontée à la menace constante d’une restructuration due au manque de vision précise
des responsables. D’autre part, les systèmes de suivi du temps, les incitations RH qui
récompensent les individus par rapport aux équipes, et les structures matricielles qui
encouragent des optimisations locales au détriment des objectifs de l'entreprise sont des
menaces constantes identifiés par l’auteur.
Le cas Nokia étudié par Laanti, Salo & Abrahamsson (2011), est l’une des rares études
mesurant le phénomène du déploiement des méthodes agiles par le biais d’une méthode
quantitative. L’objet de leurs travaux porte sur une analyse d’individus expérimentés
ayant connu différentes méthodes de gestion de projet. Leur étude permet d’illustrer si
les méthodes agiles font une entrée éphémère ou bien si elles font l’objet d’un ancrage
pérenne. Sur un échantillon de 1000 répondants : les résultats révèlent que la majorité
des répondants ont un avis positif dans le fait de mettre en œuvre une méthode agile. Les
avantages constatés comprennent une plus grande satisfaction dans la phase des équipes,
les individus considèrent que la qualité et la transparence dans la conduite des projets
augmentent. Malgré les bénéfices perçus, l’étude révèle certains défis. L’organisation de
la généralisation d’une méthode agile en simultané pour toutes les équipes chez Nokia
s’est révélé être difficile en raison notamment des différences de fonctionnements
engendrées. Cet aspect est notamment souligné dans l’étude par la mise en œuvre non
homogène de la méthode adoptée.
La seconde étude quantitative identifiée dans la littérature qui se révèle être pertinente
est proposée par Olszewska et al., (2016). Ils présentent un modèle de mesures pour
comparer quantitativement une organisation de développement logiciel avant et après un
déploiement. Le modèle est composé de 8 mesures composées d’un indicateur mesurant
le temps de développement des fonctionnalités dans les projets ; un second mesurant le
coût de développement par fonctionnalité et le nombre de bugs identifiés dans les projets
entre autres. En comparant la transition d’une organisation passant d’une à neuf équipes
agiles, les résultats montrent que le changement de processus de développement conduit
à une hausse des bugs reportés dans les applications développées. L’étude se prête tout
de même à la critique dans la quantité de données récoltées. S’il est précisé que la récolte
est basée principalement sur des journaux du service client, des bases de données de
rapports de bug, des rapports d’outils de contrôle de version. Le total des données
récoltées n’est pas précisé.
100
Dans leurs récents travaux, Conboy & Carroll (2019) compilent les données de 13
études de cas où ils analysent les différents cas de déploiement des méthodes agiles de
seconde génération (SAFe, Nexus, etc). Les résultats de leurs travaux ont notamment
abouti à la proposition d’un modèle conceptuel (figure 20) considérant les différentes
phases de déploiement d’une méthode de seconde génération.
Leurs travaux présentent d’autre part neuf défis liés aux différentes phases de leur
modèle. La préparation d’un déploiement nécessite le choix de construire d’abord un
cadre méthodologique correspondant le mieux aux caractéristiques de l’organisation.
L’idée n’est donc pas de mettre en œuvre un cadre méthodologique calqué des référentiels
des méthodes de seconde génération. Ils proposent d’identifier les nouvelles formes
d’organisation des équipes à mettre en œuvre pour préparer les équipes au changement
de fonctionnement. La conduite du déploiement doit ensuite selon les auteurs être
organisée via un équilibre top-down et bottom-up. Signifiant que le déploiement doit à la
fois être soutenu par de hauts responsables contribuant au lancement de dispositifs pour
favoriser la mise en œuvre tout en laissant place à une diffusion virale dans les équipes
pour ne pas imposer un changement soudain de fonctionnement.
Le modèle conceptuel proposé par Conboy & Carroll, (2019) présente des faiblesses en
termes de lecture du déploiement. Il considère uniquement l’adoption d’une seule
méthodologie en ne tenant pas nécessairement compte des acteurs impliqués dans le
processus. L’axe en ordonnée n’est pas explicité en tant que tel. Il ne s’agit pas d’un niveau
de mise en œuvre dans les différentes équipes des organisations, mais d’un niveau
d’attentes peu explicité par les auteurs. D’autre part, les treize cas analysés ne mettent pas
en perspective empiriquement la manière dont les organisations ont conduit le
déploiement.
Dans de nombreux travaux, le déploiement des méthodes agiles est aussi considéré
comme un changement organisationnel. Les nombreux travaux de Gandomani et al.,
101
(2015) contribuent ainsi à définir le déploiement des méthodes agiles comme une
transformation suivant « un processus qui tend à rendre les activités de développement de
logiciel ainsi que les postes en appui compatibles avec les approches agiles ». Il est par
ailleurs à noter que le processus n’agit pas uniquement au sein des équipes, mais touche
l’ensemble de l’organisation.
Dans les différentes études traitées précédemment, les frontières des cas étudiés sont
très peu explicitées, seuls la taille et le nombre d’équipes de développement sont précisés.
Nous avons pu voir que le déploiement des méthodes agiles dans les projets SI engendre
des évolutions organisationnelles. Or peu de travaux nous éclairent sur les mécanismes
clés qui s‘établissent pendant les différentes phases du déploiement des méthodes agiles.
Dans les barrières liées aux caractéristiques internes, Dikert et al. (2013) relèvent que
le scepticisme des développeurs dans l’adoption des nouvelles méthodes,
l’incompréhension des nouveaux modes de fonctionnement engendré par un manque
d’accompagnement créent des résistances au changement. Une fois déployées à grande
échelle, des barrières liées aux difficultés de coordination se révèlent être un des freins à
la poursuite de l’usage. Le manque d’implication des acteurs hors du développement (non
techniques) est d’autre part une des barrières qui entrave le bon fonctionnement des
projets.
102
inerties dans les projets causés par les méthodes initialement mises en place. D’autre part,
comme les valeurs du manifeste agile préconisent une communication en face à face,
l’organisation des espaces physiques peut ne pas favoriser un mode de collaboration et
une communication directe entre les acteurs.
Les méthodes adoptées se traduisent dans bien des cas comme de nouveaux modes de
fonctionnement. Ainsi, le fait de ne pas appliquer tous les principes dictés dans un
référentiel peut engendrer des dysfonctionnements lorsque plusieurs équipes doivent
collaborer (Hoda & Murugesan, 2016a). D’autre part, les pratiques véhiculées dans les
différentes méthodes peuvent engendrer des difficultés de compréhension. Par exemple,
la gestion des exigences dans les méthodes agiles s’établit principalement par la
formalisation de récits utilisateurs (non estimés financièrement), quand dans les
méthodes traditionnelles ce sont des spécifications fonctionnelles détaillées et estimées
financièrement. Les prévisions des coûts de développement d’un projet peuvent se
révéler plus difficiles dans le premier cas de figure, nécessitant ainsi un réel changement
de fonctionnement dans la manière de gérer les budgets des projets.
Dans de nombreux cas, comme les projets se déroulent dans des organisations
matricielles, les individus impliqués sont ainsi confrontés à différents modes de
management. Quand les équipes sont autoorganisées, il est relevé dans la littérature que
les responsables de départements sont des acteurs freinant la pérennité du nouveau
mode de fonctionnement mis en place. Cet aspect se traduit notamment par le fait que les
équipes doivent faire plusieurs fois le même travail. En prenant l’exemple de la création
de Backlog, Drury, Conboy & Power (2012) montrent que des équipes projet doivent faire
un double travail dans la phase de constitution des exigences à développer en créant un
Backlog et un cahier des charges classique.
Peu de travaux se focalisent sur les freins induits par des acteurs externes à
l’organisation ayant initié le déploiement des méthodes agiles. Nous relevons tout de
même les résultats des travaux de Rolland et al., (2016) en ce qui concerne la multitude
de méthodes agiles. Les différentes approches conduisent à différents types d’adoption au
sein d’une même organisation. Ce phénomène se nourrit des différents discours véhiculés
par les experts, coachs et consultants intervenant dans les organisations et créant des
discordances de fonctionnement.
103
2.3 Les déterminants de la transition
De récents travaux ont d’autre part identifié un certain nombre de déterminants mis
en œuvre pendant le processus de déploiement (Dikert, Paasivaara et Lassenius, 2016).
L’engagement et l’implication des différents supérieurs hiérarchiques d’une organisation
semblent être les aspects les plus importants pour appuyer le déploiement. Ces acteurs
doivent s’approprier en amont les modes de fonctionnement prôné par les différentes
méthodes agiles afin d’incarner et véhiculer la philosophie gestionnaire proposée dans le
manifeste agile (commune à toutes les méthodes agiles).
L’organisation d’un déploiement progressif se révèle être un des aspects clés dans le
processus. En favorisant les expérimentations au cours du processus de déploiement, les
organisations peuvent favoriser la généralisation des apprentissages identifiés dans les
projets pilotes. Les résultats des travaux de Kettunen & Laanti (2008a) mettent en valeur
l’importance de premières expérimentations par les individus, car cela contribue à forger
une expérience positive pour poursuivre l’usage.
Pour accompagner les différents acteurs impliqués dans le déploiement, les travaux de
Gandomani et al., (2015), œuvre essentiellement pour la mise en œuvre d’une conduite
du changement accompagnant les différentes équipes et entités impliquées (techniques
et non techniques) à la compréhension des nouveaux modes de fonctionnement. Dans
cette optique, Moore & Spens (2008) préconisent de mobiliser une poignée d’acteur
motivé qui jouera le rôle de « bon communicant » pour présenter et favoriser le
déploiement.
Enfin, la reconnaissance des nouveaux rôles véhiculés dans les méthodes adoptées
(Product Owner, Scrum Master, etc.) est importante pour affirmer le nouveau mode
d’organisation. En effet dans bien des cas, les nouveaux rôles sont mis en place dans le
cadre d’organisations « virtuelles ». C’est-à-dire qu’ils ne sont pas définis dans les
politiques des ressources humaines des entreprises ayant initié le déploiement des
méthodes agiles. L’implication de ces acteurs dans le processus semble déterminante
pour une reconnaissance de ces acteurs dans l’organisation.
104
Synthèse du chapitre 3
La question de l’adoption des méthodes agiles dans les organisations est principalement traitée
au niveau des équipes projet. L’adoption semble suivre un processus composé de plusieurs étapes
composées : d’une introduction qui se traduit par la reconnaissance d’un besoin où les membres
d’une équipe projet s’interrogent sur le fait d’intégrer une nouvelle méthode de fonctionnement.
Une fois choisie, la méthode est durant une période d’expérimentation adaptée au fonctionnement
de l’équipe en étant alliée avec d’autres méthodes agiles et/ou avec une méthode classique.
Les travaux traitant de l’adoption des méthodes agiles dans la littérature présentent de
nombreux impacts identifiés dans les projets (changement de rôles, changement de cycles de
conception). Nous avons pu constater que de nombreux acteurs composant une équipe de
développement des SI doivent changer de casquette et de mode de fonctionnement par rapport aux
méthodes initialement mises en œuvre. La littérature a d’autre part donné lieu à de nombreux
modèles d’adoption qui expliquent comment une organisation peut sélectionner et adapter
plusieurs méthodes agiles de première génération.
Les travaux sont cependant assez pauvres en ce qui concerne la mise en œuvre des méthodes
agiles à des projets de plus grande envergure. D’autre part, lorsqu’une méthode agile est adoptée
dans un projet, l’état de l’art actuel nous donne peu de visibilité quant à la suite du processus
d’adoption dans une organisation.
La deuxième partie du chapitre avait notamment pour objectif d’identifier les travaux sur le
déploiement des méthodes agiles à un ensemble de projets d’une organisation. Les différents cas
présentés nous permettent de comprendre le déroulement de certaines phases et de certains
dispositifs mis en œuvre. Nous retenons de plus la nécessité d’étudier le déploiement au-delà des
acteurs intégrés dans les projets, à savoir les acteurs métiers.
Bien que l’étude des barrières et des déterminants nous révèle des éléments clés dans le
déploiement des méthodes agiles, peu de travaux analysent les mécanismes à l’œuvre pendant les
différentes phases du déploiement. Nous retenons d’une part l’importance d’investiguer des cas de
généralisation dans une optique longitudinale en nous concentrant sur d’autres unités d’analyses
comme les acteurs des différents départements indirectement impliqués dans les projets.
105
Chapitre 4 : L’adoption des méthodes agiles
au travers du prisme des outils de gestion
Chapitre 1 Chapitre 2
Historique des approches de Présentation et analyse du
conception de logiciels paradigme des méthodes agiles
Chapitre 3 Chapitre 4
L’adoption des méthodes agiles : L’adoption des méthodes agiles
un état de l’art au travers du prisme des outils de
gestion
CHAPITRE 4 : L’ADOPTION DES METHODES AGILES AU TRAVERS DU PRISME DES OUTILS DE GESTION .. 106
106
Introduction
Les analyses portant sur l’adoption des méthodes agiles ont principalement été
réalisées du point de vue de travaux en management des systèmes d’information. Or il
nous parait essentiel de considérer les méthodes agiles comme des objets de management
pour appuyer l’étude du phénomène de leur déploiement au sein de grandes
organisations.
De nombreux paramètres doivent être pris en compte lors de l'examen d’introduction
d’une approche agile de gestion de projet au sein d’une organisation. Nous avons pu voir
précédemment qu’il existe de nombreuses méthodes, chacune proposant des modes de
fonctionnement plus ou moins différents dont les impacts se révèlent être multiples sur
la culture, les processus de décision, les rôles et de l'organisation du travail. Compte tenu
des différentes terminologies ayant été utilisées dans le chapitre précédent, il figure que
les travaux portant sur les outils de gestion se révèlent être particulièrement utiles pour
expliquer le processus d’adoption des méthodes agiles.
Nous proposons ainsi dans ce chapitre une approche conceptuelle par les outils de
gestion. En introduisant les éléments de définition de ce cadre théorique ayant émergé
principalement en France dans les années 1980, nous préciserons les différentes
terminologies utilisées pour désigner les outils de gestion. Nous mobiliserons les travaux
permettant de clarifier les effets de ces objets de management dans l’action collective afin
de doter nos analyses d’une grille conceptuelle fondée sur un cadre théorique bien établi.
Nous présenterons de plus un raisonnement par lequel nous montrons que la méthode
Scrum peut effectivement être considérée comme un outil de gestion avec des propriétés
innovantes. Nous compléterons notre cadre conceptuel en mobilisant dans un second
temps les travaux portant sur l’adoption d’innovations managériales (Damanpour &
Wischnevsky, 2006) puisqu’ils nous permettront de prendre en compte certains
phénomènes exogènes aux organisations.
Les différents travaux mobilisés constitueront ainsi notre grille d’analyse pour la phase
empirique de cette thèse. Nous terminerons cette première partie par la présentation de
la question de recherche et les propositions de recherches qui découlent de la revue de
littérature.
107
1. Les outils de gestion comme cadre d’analyse
conceptuel
Les années 1980 ont été le théâtre de nombreuses initiatives théoriques pour
comprendre la structuration des organisations. À l’aune des travaux ayant été menés par
Chandler (1977) et Mintzberg (1980) notre recul nous fait prendre conscience que de
nombreuses méthodes et techniques ont émergé durant ces années ayant conduit au
développement du champ des outils de gestion. À la lecture des organisations
contemporaines où les configurations organisationnelles sont régies par les technologies
collaboratives (Tran, 2014), les travaux portant sur les outils de gestion nous paressent
d’autant plus d’actualité pour expliquer les dynamiques organisationnelles
contemporaines.
Les organisations s’étendent dans des réseaux de plus en plus larges (De Vaujany,
2005) et favorisent des interactions entre utilisateurs par le biais de nouvelles
technologies de l’information et de la communication. Concevoir des systèmes
d’information se conduit comme nous avons pu le voir dans une dynamique de gestion de
projet. Si la littérature regorge d’exemples de travaux en gestion de projets industriels
pour comprendre les artefacts, et organisations mises en œuvre au cours de ces 50
dernières années (Garel, 2011; Lenfle, 2014; Midler, 2008), peu de travaux s’intéressent
aux outils de gestion mis en œuvre pour les projets de conception des systèmes
d’information.
La littérature sur les outils de gestion se révèle être en adéquation avec nos travaux sur
plusieurs aspects. Ils nous permettront d’une part de caractériser le déroulé du processus
d’adoption d’un outil de gestion. Ils nous permettront de comprendre la manière dont une
organisation envisage d’introduire une méthode agile de gestion de projet. Nous pourrons
appuyer nos réflexions quant à l’adaptation et l’appropriation de la méthode introduite
au niveau des individus, des projets et de l’organisation. Enfin, dans l’optique de mieux
caractériser les mécanismes en œuvre dans le déploiement d’une approche de gestion de
projet agile, le cadre conceptuel mobilisé nous permettra de mieux expliquer les
dynamiques en œuvre autour de la généralisation d’une nouvelle approche de gestion de
projet.
108
1.1 Terminologie et définitions liées aux outils de gestion
De nombreux travaux se sont penchés sur la proposition de nombreuses
dénominations pour désigner pourtant un même concept. Entre instrument de gestion
(Berry, 1983), machine, technique (Hatchuel & Weill, 1992) ou objet de gestion (Adam-
Ledunois & Damart, 2017), ces termes partagent un sens commun considérant que les
outils de gestion sont au cœur du fonctionnement des organisations pour structurer les
dynamiques et le comportement des acteurs d’une entreprise (Grimand, 2016).
Cependant, une certaine distinction de fond est tout de même nécessaire pour préciser
l’usage des différents termes employés.
Depuis les années 1980, les travaux sur les outils de gestion ont émergé par l’impulsion
des travaux menés au sein du Centre de Gestion scientifique de l’école des Mines et du
Centre de Recherche en Gestion à l’école Polytechnique. Michel Berry avait notamment
ouvert la voie à l’école française dans le rapport intitulé Une technologie invisible - l'impact
des instruments de gestion sur l'évolution des systèmes humains dans lequel il contribue au
développement d’une « approche théorique par les instruments » (Berry, 1983). Il
qualifiait alors les outils de gestion comme technologie invisible avec de multiples
propriétés telles que la réduction de la complexité organisationnelle, la coordination des
activités et la régulation des rapports entre des hommes et entre des groupes sociaux.
Michel Berry appuyait notamment le fait que les outils de gestion pouvaient cristalliser
des rapports de forces entre les hommes.
Le second auteur ayant marqué la voie de l’école française dans ces travaux est Jacques
Girin. Il a notamment contribué à élargir le champ des outils de gestion en introduisant la
notion de « machines de gestion ». Empruntant cette distinction à Marx qui en fait la ligne
de partage entre la manufacture et la grande industrie, Girin converge avec le point de vue
de Berry (1983) sur l’aspect disciplinant des outils gestion. Il s’aligne sur le fait que les
outils de gestion peuvent imposer leurs propres rythmes au point d’occulter les finalités
de l’action.
Hatchuel & Molet (1986) précisent que l’intégration de plusieurs outils de gestion
répondant à une intention stratégique constitue un dispositif de gestion. En ce sens, le
dispositif de gestion permet d’intégrer les outils et les acteurs de façon cohérente, et dans
le respect de certaines règles de gestion (De Vaujany, 2006a). La règle de gestion permet
d’organiser les dynamiques de l’action par le biais de discours ou de pratiques, qui
peuvent être tant internes qu’externes, destiné aux acteurs qui orientent leurs actions (De
Vaujany, 2005).
Les outils de gestion se révèlent être plus ou moins complexes selon leur nature. Au-
delà des aspects matériels, la nature même d’un outil peut être difficile en raison de sa
nature conceptuelle et de sa combinaison dans des contextes organisationnels. Pour les
109
capter de façon plus précise, Hatchuel & Weill (1992) suggèrent que tout outil de gestion
est le fruit de trois éléments en interaction :
- Un substrat technique qui est l’abstraction sur laquelle repose l’outil et qui lui
permet de fonctionner ;
- une philosophie gestionnaire qui traduit l’esprit de la conception et des usages de
l’outil et peut donc faire référence à des règles de gestion ;
- et enfin une vision simplifiée du système de rôles sous-jacent à l’outil.
Le substrat technique désigne plutôt les objets techniques (Akrich, 2006), ou encore
les artefacts (Lorino, 2002). Ce dernier est plus récemment défini par Martineau (2017)
comme support visuel, graphique, physique et/ou matériel sur lequel repose un outil de
gestion, et qui se présente aux utilisateurs dans une situation d’activité. Dans ce sens, Canet
et Tran, 2017, mettent en avant le rôle clé du substrat technique dans la construction du
sens et le succès du déploiement d’un objet de gestion au sein de l’organisation.
Une seconde définition clé souvent reprise dans les travaux en sciences de gestion est
celle proposée par Moisdon (1997), il considère les outils de gestion comme : « un
ensemble de raisonnements et de connaissances reliant de façon formelle un certain nombre
de variables issues de l’organisation, qu’il s’agisse de quantités, de prix, de niveaux de qualité
ou de tout autre paramètre, et destiné à instruire les divers actes classiques de la gestion,
que l’on peut regrouper dans les termes de la trilogie classique : prévoir, décider, contrôler.
» (Moisdon, 1997 pp. 7).
Quant à la règle de gestion, elle se matérialise de façon subtile par un discours, une
pratique interne ou externe à destination des membres de l’organisation (par exemple
110
une règle comptable). De Vaujany précise que la visée d’une règle de gestion est
explicitement normative et obéis à une logique de régulation de l’action collective.
Le tableau 10 présente ainsi les termes clés que nous mobiliserons pour la suite des
travaux. Nous retenons de plus que les outils de gestion peuvent être multiples dans les
organisations, composés de différents attributs plus ou moins complexes à capter. Ainsi,
pour mieux comprendre la manière dont l’action collective s’organise au sein des projets
SI d’une organisation, nous proposons de rapprocher la notion d’outil de gestion des
méthodes agiles mises en place dans les projets SI.
Si les outils de gestion sont multiples et régissent les liens entre acteurs de différents
niveaux, David (1996) propose une taxonomie composée de trois dimensions des
innovations managériales, désignant en substance les outils de gestion (nous reviendrons
sur cette notion dans la section 2 du chapitre). Il présente notamment les outils de gestion
orientés relations, ceux orientés connaissances, d’autres sont enfin mixtes. Les outils
111
orientés relations reflètent « les différents types de contacts et de connexions, formels ou
informels, directs ou non, qui existent entre des acteurs ou des groupes d’acteurs de
l’organisation ». L’auteur prend notamment l’exemple d’un contrat d’objectifs à la RATP.
Celui-ci renvoie par exemple directement aux relations entre acteurs organisationnels.
- l’axe horizontal indique si l’innovation (ou l’outil) concerne les relations ou les
connaissances - ou les deux -,
- l’axe vertical indique avec quel degré de précision l’innovation est définie au début
du processus, c'est-à-dire son degré de formalisation.
Ces deux dimensions permettent de définir un espace dans lequel classer les différents
outils de gestion introduits dans une organisation. Ce modèle souligne notamment qu’à
tout moment d’un processus d’adoption, un outil peut être plus ou moins formalisé.
112
1.2.2 Les différents degrés de contextualisation-formalisation
Dans ce cadre, le degré de contextualisation interne d’un outil de gestion peut être
compris comme la distance qui existe entre l’outil et l’organisation à un moment donné
de l’histoire de l’outil dans une organisation donnée. D’un point de vue qualitatif, David
signale que cette distance correspond « non seulement à l’écart entre le fonctionnement
présent et ce que l’on imagine du fonctionnement futur, mais aussi à la longueur et à la
difficulté du chemin à parcourir pour que l’outil fonctionne effectivement ». Il nous parait
ainsi important dans nos travaux de mesurer ces deux variables.
113
Si l’outil se révèle être totalement formalisé, mais avec un degré de contextualisation
proche de zéro (partie 2 de la figure 22), il s’agit d’un outil « prêt à l’emploi » selon David
(1996), mais n’étant pas confronté à la réalité de l’organisation souhaitant l’intégrer.
L’outil se révèle cependant être une innovation managériale pour l’organisation
adoptante du fait de son caractère novateur à l’état des pratiques internes au sein de
l’organisation (Adam-Ledunois & Damart, 2017).
Enfin, si l’outil est considéré comme formalisé avec un degré de contextualisation fort
partie 1 de la figure 22, il s’agira d’un cas où l’outil se révèle être ancré dans l’organisation
et ne présente pas de caractère novateur. Un processus d’adoption d’un outil de gestion
pourra ainsi démarrer par un point qui se situera à l'intérieur du carré défini par ces
positions extrêmes de la figure.
Le modèle ayant été précédemment présenté a été enrichi par des travaux plus récents
introduisant une nouvelle variable de contextualisation. Rouquet (2009) propose
d’étendre les travaux de David en introduisant le degré de contextualisation externe d’un
outil de gestion, incluant ainsi les acteurs du champ institutionnel relatif à l’organisation
introduisant l’outil. Le degré de contextualisation externe d’un outil de gestion peut être
compris comme « une mesure du degré de contextualisation de l’outil au sein des diverses
organisations qui entourent l’organisation considérée ».
De cette manière, un outil de gestion peut être envisagé comme l’évolution du degré de
contextualisation interne d’un outil de gestion dans une organisation, comparée à celle du
degré de contextualisation externe de l’outil au sein du champ institutionnel. Quatre
situations sont ainsi présentées par Rouquet sur un modèle composé de deux axes (figure
23) :
- La contextualisation interne et externe de l’outil peuvent être toutes les deux totales.
Cela signifie que l’outil est utilisé par l’organisation et les organisations de son champ
institutionnel. L’outil se caractérise comme un potentiel standard du champ utilisé par
l’organisation (partie 1 de la figure 3).
114
- Deuxièmement, la contextualisation externe de l’outil peut être totale et sa
contextualisation interne nulle. Dans ce cas, l’outil est un potentiel standard du champ
institutionnel qui n’est pas utilisé par l’organisation considérée. Rouquet considère que
l’outil est alors associé à une forte pression institutionnelle (partie 2 de la figure 23).
- Troisième cas de figure, si la contextualisation interne et externe de l’outil est nulle. Dans
ce cas, l’outil se réduit à un mot d’ordre ou à un concept pouvant potentiellement être
innovant, puisqu’il n’a pas été opérationnalisé par aucune organisation du champ
institutionnel (partie 3 de la figure 23).
115
Les « outils fermés » poussent la logique de rationalisation au maximum afin qu’ils
puissent être compris et mis en œuvre au maximum. Leur forme repose sur des schémas
clairs et non ambigus. Sur la substance, Martineau (2017) précise que le but est de
normaliser les comportements des utilisateurs et leur prévisibilité. Par exemple, le
principe d’ordonnancement d’un budget tend à être non ambigu (chaque ressource
appartient à une catégorie et une seule, selon la seule et unique logique comptable), et
exhaustif (toute ressource est prévue pour rentrer dans une catégorie).
Cette typologie nous renvoie directement aux travaux de Lorino (2002) considérant
deux positions théoriques des outils de gestion. Les outils « fermés » s’illustrent par une
théorie « représentationniste » et « computationnelle ». En ce sens, les propriétés
intrinsèques de l’outil ou son design suffisent à le définir. L’outil tend à influencer l’action
et engendre une certaine prescription des comportements. Il va ainsi se caractériser par
une certaine efficacité opérationnelle à répliquer la réalité et à la simuler. L’acteur s’inscrit
dans un rapport de conformation passive à l’égard de l’outil.
Tableau 11 : Précisions quant aux artefacts fermés et ouverts d’un outil de gestion
116
Ainsi, la mise en œuvre d’un outil dont le substrat technique est ouvert ou bien fermé
aura nécessairement une influence dans le processus d’appropriation auprès des
individus allant l’utiliser. Il nous parait donc important de spécifier la nature d’un outil de
gestion dans son contexte organisationnel puisque les dynamiques liées à sa diffusion
interne ne seront pas les mêmes.
Il met en avant que toute appropriation est une forme contingente qui articule les
objets, les outils, les dispositifs et les règles. Deuxièmement, « tout outil et objet de gestion,
conçu à distance des acteurs ou bien dans une logique de co-production, présente une
certaine flexibilité instrumentale et interprétative ». La notion de « flexibilité » renvoie à
l’adaptation de l’outil aux contextes des individus le mettant en œuvre.
117
- des utilisateurs finaux et des dynamiques d’apprentissage-représentation de
l’outil par lesquels ils vont inscrire leur utilisation de l’outil dans une logique de
régulation autonome (perspective dite « psychocognitive ») ;
- le troisième point de vue concerne celui des utilisateurs finaux toujours et des
processus sociologiques par lesquels passe l’appropriation afin de constituer une
régulation autonome (perspective dite « socio-politique »).
Tableau 12 : Les trois regards pour étudier l’appropriation des outils de gestion selon
De Vaujany (2006a)
En somme, comme nous l’avons introduit, l’ensemble des travaux sur les dynamiques
d’appropriation des outils de gestion convergent vers deux théories proposées par De
Vaujany (2005). D’une part la théorie de la "conception à l’usage" d’un outil de gestion se
traduit par le fait que « l’appropriation d’un outil est consubstantielle à sa conception ».
Cette théorie considère que c’est au fil d’apprentissages, de conflits et de dialectique
autonomie-contrôle que l’outil prend forme. Ce processus se caractérise essentiellement
par la prise en compte des usagers et concepteurs des outils de gestion afin de
comprendre les activités de conception, stabilisation et réadaptation de l’outil dans
l’organisation. Dans ce cadre, le processus d’appropriation amène ici le collectif à penser
sa propre transformation ou les trajectoires dans lesquelles il pourrait s’engager. Cette
théorie s’inscrit notamment dans la perspective des travaux d'Orlikowski (2000)
permettant de dépasser la simple prise en compte des utilisateurs dans le processus de
118
conception, mais préconisant plutôt de prendre en compte l’usage dans sa globalité, dès
la conception de la technique.
La seconde théorie englobant les différents travaux sur l’appropriation des outils de
gestion concerne la "mise en acte". Ce second cadre théorique valorise davantage
l’interaction entre des acteurs et des outils. L’appropriation se traduit par un vaste
processus interactif qui engage des « prescriptions réciproques » au sens d'Hatchuel
(1996). De Vaujany fait directement référence à Moisdon (1997) considérant le «
caractère irréaliste des hypothèses de rationalité intégrées dans les outils par rapport aux
systèmes de rationalités locales en interaction que constituent les organisations ».
Cette incomplétude des outils de gestion fait donc l’objet d’apprentissages par les
usagers, qui est comblé par un travail de conception : « Conception et usages sont alors
intégrés dans un vaste processus récursif et continu ». L’outil est approprié par un ou
plusieurs acteurs qui l’interprètent, le forment et le déforment. Puis un autre collectif ou
les mêmes acteurs se réapproprient ensuite l’outil reconstruit, s’engageant
séquentiellement dans des rapports prescripteurs-opérateurs plus ou moins forts.
119
1.4 La relation conception-usages permettant l’appropriation
Les travaux de nombreux auteurs présentent un consensus sur la prise en compte des
liens entre la conception et l’usage des outils de gestion dans l’analyse du processus lié à
déploiement d’un outil de gestion (Aggeri & Labatut, 2010; Berry, 1983 ; Hatchuel & Weil,
1992 ; de Vaujany, 2005 ; Girin, 1983 ; Berry, 1983; Hatchuel, Weil, 1992; Moisdon, 1997).
L’activité de conception est pour de nombreux auteurs indissociables de l’usage
« opérationnel » de l’outil (Aggeri & Labatut, 2010; De vaujany, 2006a; Grimand, 2016).
Segrestin (2004) insiste sur une nécessaire mise en débat de la prescription et de
l’exploration croisée des concepteurs et des usagers de l’outil, des savoirs et des relations
qui les unissent.
L’outil de gestion ne résume pas la totalité des actes censée être mis en œuvre dans
l’action collective donnée, il fixe plutôt un cadre d’action qui peut être enrichi ou non par
les choix des acteurs le mettant en œuvre. Ainsi, selon Hatchuel (1994), la définition des
outils est incomplète par nécessité. Le rôle des utilisateurs, ou de ceux qui font l’objet d’un
contrôle au travers d’eux, consiste à les enrichir par leur expérience et leur jugement. Il
s’agit donc d’un apprentissage croisé entre concepteur et utilisateur de l’outil. Il est donc
important de souligner que par nature, un outil de gestion se développe dans un certain
contexte (Aggeri & Hatchuel, 1997). Il est donc important de les étudier dans une situation
de mise en action (Moisdon, 1997).
Une démarche de conception d’un outil de gestion se révèle être ainsi tâtonnante et
exploratoire. Or si de nombreux auteurs considèrent de fait la double perspective
conception-usage d’un outil de gestion, il figure que les travaux de Canet (2012 ;2013)
permettent de les considérer de façon indépendante. L’auteur définit l’activité de
conception par une « action continue, assurant un processus de
construction/reconstruction permanent de l’outil et repose sur un apprentissage
ininterrompu ».
La mobilisation de ces travaux conduit à identifier deux niveaux d’analyse dans le cadre
de la conception d’un outil de gestion : d’une part le modèle conceptuel et le modèle
génératif. La conception d’un outil de gestion est une activité vécue par toute organisation
créant ou adoptant un outil de gestion. Ainsi, Canet (2013) présente dans ses travaux qu’il
y a niveau de conception de l’outil au sein de chaque organisation, celui-ci est notamment
décrit par un modèle conceptuel, par lequel chaque organisation décide d’adopter ou
développer un outil en poursuivant une activité de conception réglée. Puis, en prenant
l’exemple d’un cabinet de conseils, Canet (2013) décrit que ce genre d’acteurs peuvent
être amenés à proposer des « recettes générales guidant les mises en application d’un outil
», c’est ce qui est désigné comme un modèle génératif de conception. Il nous parait de ce
fait intéressant d’interroger la relation des outils entrant dans la logique du modèle
120
conceptuel et génératif pour comprendre les différents allers-retours entre consultants,
accompagnateur et praticiens dans une organisation.
En poursuivant dans cette logique Hatchuel & Weil (1992) évoquent notamment le fait
que la conception et l’usage des outils de gestion sont indissociables de la naissance de
nouvelles "figures d'acteurs". Ce genre d’actions accompagne le processus de
rationalisation de l’outil qui se matérialise par l’apparition de nouveaux métiers, rôles,
statuts et entités internes. Nous devons ainsi comprendre la relation entre les différents
organes de contrôle lié à la mise en œuvre des outils de gestion, et identifier les agents
dédiés à ce genre de travaux.
D’autre part, les allers-retours entre conception et usage des différents acteurs
impliqués dans ce processus rendent un outil de gestion plus ouvert à des changements
auprès des utilisateurs finaux. Ce que nous qualifions ici « d’aller-retour » entre
conception et usage signifie selon De Vaujany (2005) qu’une première étape de
conception est issue d’une précédente étape auprès d’acteurs opérationnels où l’adoption
de l’outil se révèle être « figé ». Dans ce cas les praticiens peuvent ainsi recourir à une «
reconception à l’usage » de l’outil jusqu’à trouver le bon niveau de correspondance aux
besoins des individus. Cette dynamique continue de la conception-usage de l’outil de
gestion (Artin, 2007) nous parait ainsi intéressante à illustrer dans une perspective
temporelle afin de comprendre au mieux les dynamiques collectives.
Une des principales difficultés dans les liens conception et usages des outils de gestion
tient cependant à la dimension incertaine des processus à piloter (Artin, 2007). En
fonction de la dynamique de l’action collective locale dans une organisation, les outils sont
eux-mêmes soumis à des évolutions plus ou moins incertaines. Analyser l’adoption des
outils de gestion doit ainsi nécessairement être considéré dans la double perspective
conception-usage en tenant compte d’un contexte organisationnel (Paraponaris & Gilda,
2006).
121
1.5 Apport des outils de gestion dans l’analyse de la mise
en œuvre des méthodes agiles
Différents courants théoriques se sont emparés de la question des outils de gestion.
Parmi les pionniers, il nous parait important de mentionner: Henri Fayol, Frederick
Taylor tout comme les travaux de Mary Parker Follett qui soulignèrent l’importance de
l’outillage gestionnaire dès le début du 20e siècle (Damart, 2013). Ce premier courant
s’illustre notamment par l’importance de la figure de l’expert (Hatchuel & Weill, 1992)
dans les organisations dont la vision de la gestion se fonde sur l’application du
management scientifique à la résolution des problèmes qui se posent dans la vie des
organisations (Chiapello & Gilbert, 2013).
Cette première partie de notre cadre conceptuel portait principalement autour des
travaux ayant contribué à légitimer des analyses sociales autour des outils de gestion. Ces
travaux ont notamment été initiés en France par les laboratoires de gestion des écoles
d’ingénieurs (CRG-Polytechnique, CGS-Mines) et constituent des jalons importants dans
la littérature, car ils ont mis en exergue l’importance de ces outils dans les organisations.
Nous envisageons ainsi de traiter l’adoption d’une méthode agile au travers du prisme des
outils de gestion, cependant une hypothèse reste en suspens au regard de notre objet
d’étude. Comment considérer une méthode agile comme un outil de gestion ?
En prenant le cas de la méthode agile la plus mise en œuvre : à savoir la méthode Scrum
et les valeurs et principes d’ordres plus généraux aux méthodes agiles, il est intéressant
de rapprocher les attributs caractérisant les méthodes agiles de la définition d’un outil de
gestion. Dans le cas de la méthode Scrum, par définition, les créateurs de cette approche
mettent en valeur un nouveau mode d’organisation d’un projet. La méthode est définie
comme une nouvelle approche englobant une large variété de pratiques
organisationnelles et managériales où les différentes séquences du projet sont organisées
en Sprint. De nouveaux modes de gestion des tâches sont mis en lumière avec par exemple
le Product Backlog – qui n’est plus un cahier des charges traditionnel, mais une liste des
exigences s’adaptant aux priorités du projet. Au niveau des rôles, il n’y a plus de « Chef de
projet » en tant que tel, mais un Product Owner dont les responsabilités sont totalement
différentes.
On retrouve donc dans cette définition (appuyée par le tableau 13) la notion de
philosophie gestionnaire véhiculé par les valeurs et piliers de la méthode. La vision
simplifiée de l’organisation peut être vérifiée au niveau d’une organisation ne serait-ce en
ce qui concerne les rôles et son intentionnalité, c’est-à-dire la simplification des procédés
de développement des projets avec un objectif d’adaptation et d’amélioration continue. Et
le substrat technique de la méthode Scrum est aussi bien établi puisqu’il est présenté dans
la méthode sous forme de différents artefacts comme le Burndown chart, ou le product
backlog.
122
Éléments de définition Méta analyse des méthodes Application avec le cas de la méthode
selon Hatchuel et Weil agiles comme outils de gestion scrum
(1992)
Philosophie gestionnaire : Les 4 valeurs du manifeste agile La méthode est alignée sur le
qui traduit les intentions de développement de logiciels manifeste agile (Sutherland 2001) et
projetées sur l’outil, et les 12 principes sous-jacents présente de plus des valeurs de
l’esprit dans lequel il a été constituent la philosophie fonctionnement : « Lorsque les
conçu commune à toutes les valeurs d'engagement, courage,
méthodes focus, ouverture et respect sont
incarnées et vécues par l'équipe
Scrum, les piliers Scrum de
transparence, d'inspection et
d'adaptation émergent et consolident
la confiance entre tout le monde. »
(Extrait du guide scrum)
Une "vision simplifiée de Les rôles véhiculés dans chaque - Product Owner
l’organisation": qui décrit approche sont clés et tendent à - Scrum Master
schématiquement les simplifier l’action collective - Équipe de réalisation
rôles et apprentissages autour des projets SI. (Hoda &
devant implicitement et Murugesan, 2016b)
explicitement s’opérer Les pratiques et rituels - Réunion quotidienne (Daily meeting
autour de l’outil pour que proposés dans chaque méthode de 15 minutes)
ce dernier puisse s’insérer agile permettent de rythmer la - Sprint
efficacement dans dynamique des projets. (Jalali & - Revue de Sprint
l’organisation Wohlin, 2010) - Rétrospective du Sprint
Un substrat technique qui Toutes les méthodes cultiventDans le cas de la méthode Scrum, les
est l’abstraction sur des artefacts qui permettent principaux artefacts sont :
laquelle repose l’outil et d’équiper les équipes d’objet de
- Le Backlog produit
qui lui permet de suivi des projets. (Jalali & - Le Backlog de Sprint
fonctionner Wohlin, 2010) - Le Burndown Chart
- Définition d’une exigence
« terminé »
Tableau 13 : Analyse de la méthode Scrum comme outil de gestion
Le raisonnement autour des outils de gestion pourrait être réalisé avec bon nombre de
méthodes ayant préalablement été présentées dans le chapitre 2. Nous nous en tenons
néanmoins à une méta analyse puisque nous avons vu dans les chapitres précédents que
les méthodes agiles cultivent des points communs, parmi lesquels une philosophie
gestionnaire véhiculée par le manifeste agile de développement de logiciels. Le tableau 13
reprend ainsi des éléments d’exemples permettant d’appuyer le raisonnement au niveau
des autres méthodes agiles.
123
En partant du principe que notre précédente hypothèse a été validée, énonçant que les
méthodes agiles peuvent être considérées comme des outils de gestion, à l’instar d’Aggeri
& Labatut (2010), nous retenons ainsi que les questions de recherche au sujet des outils
de gestion tiennent autour d’interrogations sur les effets attendus et inattendus, produits
par ces outils sur les dynamiques organisationnelles. Ainsi, en guise de synthèse des
travaux présentés dans cette première partie, nous proposons de différencier les termes
ayant été évoqués afin de poser une compréhension limpide des termes pour la suite des
travaux.
124
Apport de la littérature sur les outils de gestion dans nos travaux
Cadre conceptuel Questionnement pour nos travaux Objet d’analyse dans la suite des
travaux
Caractérisation d’un outil de Justifier le caractère gestionnaire de La méthode adoptée ou construite
gestion (Hatchuel Armand, 1994) l’outil adopté par l’organisation. Une au sein d’une organisation
- Philosophie gestionnaire méthode agile peut-elle être Les objets de gestion
- Substrat technique (Ouvert ou considérée comme un outil de complémentaire à la méthode
fermé ?) gestion ? mise en œuvre
- Vision simplifiée de l’organisation Dans quel dispositif gestionnaire
s’intègre la méthode nouvellement
adoptée ?
Adoption d’un outil de gestion : Comment se traduit l’introduction Les consultants, coachs ou acteurs
(David, 1996) d’une méthode agile ? Qui intervient ayant contribué à l’introduction de
- Niveau de cadrage dans le processus ? Qu’elles sont les la méthode dans une organisation
- Niveau de procédure décisions prises ?
Niveau de formalisation de l’outil Quel est le degré de formalisation de La méthode adoptée ou construite
de gestion l’outil ? au sein de l’organisation
- Nature des artefacts (Substrat L’outil comporte-t-il des artefacts
technique) prescriptifs ou bien est-il ouvert ?
Niveau de contextualisation interne - Quel est le niveau d’ancrage de - Les équipes projet mettant en
(David, 1996) l’outil dans l’organisation ? œuvre une nouvelle approche de
gestion de projet
- Entités organisationnelles de
rattachement des projets
Niveau de contextualisation Quel est le niveau d’ancrage de l’outil - Les acteurs externes aux projets
externe (David, 1996; Rouquet, dans le champ institutionnel de (externalisation des services dans
2009) l’organisation ? les projets)
Niveau d’appropriation (De Quel est le niveau d’appropriation de Discours des acteurs projets et
vaujany, 2006a; Dechamp et al., l’outil de gestion ? parties prenantes aux projets
2006) Comment est-il « rendu propre ou
impropre à un usage « socio- Niveau de modification de la
politique », « psychocognitif » ou « méthode de gestion de projet
rationnel » ? adopté au sein des équipes
Relation conception – usage Quels sont les acteurs impliqués dans Analyse des agents accompagnant
(Ségrestin, 2004) la conception-usage d’une méthode les équipes et l’organisation dans
de gestion de projet ? la mise en œuvre d’une nouvelle
Comment se déroule la conception- approche de gestion de projet
usage au sein d’équipes projet ?
125
2. Apport des travaux portant sur l’innovation
managériale
Les travaux portant sur l’adoption et la diffusion des innovations managériales sont
foisonnants. Bien que le concept d’innovation managériale partage de nombreux points
communs avec les outils de gestion, envisager un outil de gestion d’emblée comme une
innovation managériale relève d’une hypothèse à valider. Il figure selon David (1996)
qu’elles se composent aussi d’une philosophie gestionnaire, d’un substrat technique et
d’une vision simplifiée de l’organisation.
Les innovations managériales (IM pour la suite du document) sont décrites comme de
nouvelles structures organisationnelles, de nouveaux systèmes administratifs, de
nouveaux processus et de nouvelles techniques dont l’objectif est d’améliorer la
performance d’une organisation (Birkinshaw et al., 2008; Kimberly & Evanisko, 1981b).
Parmi les différentes innovations managériales remarquables, il est possible de citer le
Total Quality Management (TQM), la production juste à temps, l’évaluation à 360 degrés
et le management par projet (David, 1995; M. J. Mol and Birkinshaw, 2009; Midler, 2012;
Le Roy, Robert and Guiliani, 2013). Cette dernière nous intéresse tout particulièrement
en raison de notre objet d’étude puisque nous avons pu voir dans le chapitre 2 que les
méthodes agiles ont engendré une certaine évolution des référentiels classiques.
Nous souhaitons dans cette section compléter notre cadre conceptuel par les travaux
portant sur l’adoption des innovations managériales (IM). Ce choix se justifie notamment
par le fait que les méthodes agiles et notamment la méthode Scrum se révèlent être des
outils de gestion particulièrement novateurs pour le management de projet. Nous
souhaitons compléter ce raisonnement au niveau de notre phase empirique de cette thèse
en mobilisant la méthode d’analyse critique des innovations managériale proposée par
Adam-ledunois & Damart (2018). Nous mobilisons de concert les travaux portant sur le
processus d’adoption d’une innovation managériale en complément de notre grille
d’analyse.
Il est par ailleurs important d’évoquer en amont de cette section le fait que la littérature
sur les innovations managériales s’est fortement inspirée et appuyée sur les travaux
autour des innovations dites technologiques. Or les travaux fondateurs sur les outils de
gestion considèrent bien ces objets comme des technologies. (Berry, 1983) évoquait à cet
effet, que les outils de gestion « jouent un rôle crucial dans la marche d'une organisation en
imposant aux actions des hommes des lois parfois aussi inflexibles que les machines
techniques ».
126
2.1 Attributs des innovations managériales
La littérature sur les innovations managériales comporte de nombreuses définitions,
les travaux portant sur ce type d’objet de managements sont d’autre part fortement
inspirés des innovations dites technologiques et c’est notamment (Evan, 1966) qui
introduit dans ses travaux une nuance en différenciant les innovations technologiques
(techniques), des innovations administratives. Il considère dès lors que les innovations
administratives prennent place dans le système social de l’organisation et concernent
divers aspects tels que le recrutement, l’autorité, les récompenses et la structuration des
tâches ou l’allocation de ressources.
C’est par le biais des travaux de Baldridge & Burnham (1975) que le terme innovation
organisationnelle est employé pour la première fois. Il se réfère plutôt aux changements
dans les structures et les procédures organisationnelles. Et l’expression « innovation
managériale » a été utilisée pour la première fois par Kimberly & Evanisko (1981)
considérant que « tout programme, produit ou technique qui représente un écart significatif
par rapport à l’état de l’art du management et qui affecte la nature, le lieu, la qualité ou la
quantité d’informations disponibles pour les prises de décisions. » La notion de nouveauté
semble être significative et se confirme avec des définitions plus récentes.
Selon Hamel (2006), l’IM marque une rupture dans la manière dont le travail de
management est réalisé. Il s’agit donc de nouvelles formes organisationnelles, pratiques,
processus ou techniques de management (Damanpour & Aravind, 2012). L’IM modifie de
façon concrète le travail et les pratiques des managers (Le Roy et al., 2013) et s’insère
dans un objectif d’amélioration de la performance de l’organisation qui l’a initié
(Damanpour & Aravind, 2012; Hamel, 2006; Mol & Birkinshaw, 2009).
La nouveauté est définie différemment selon les auteurs. Pour certains, l’innovation
managériale ne peut être définie comme telle que lorsque la pratique est nouvelle par
rapport à l’état de l’art (Kimberly, 1981 ; Birkinshaw et al., 2008), c’est-à-dire qu’il n’existe
pas de précédent connu. Pour d’autres auteurs, la nouveauté est relative à l’organisation
qui met en œuvre l’innovation (Adam-Ledunois & Damart, 2017). Il est donc
potentiellement possible de considérer un objet de management comme une innovation
managériale dès lors que la pratique en œuvre est nouvelle du point de vue de
l’organisation qui la conçoit ou l’adopte (Zbaracki, 1998).
127
d'une technique managériale qui est nouvelle par rapport à l'état de l'art et qui vise à
prolonger les objectifs de l'organisation » (Birkinshaw et al., 2008).
Cette terminologie rend d’autant plus difficile le fait de saisir l’essence même de ce
genre d’objet de management. Nous emploierons ainsi pour la suite de nos travaux le
terme innovation managériale en nous référant à la définition proposée par Birkinshaw
et al., (2008).
128
2.2 Génération, adoption et diffusion des innovations
managériales, quelles différences ?
Les travaux portant sur les innovations managériales dissocient l’activité de création
de l’innovation par rapport à l’adoption. Une innovation managériale est le fruit d’une idée
de départ. La génération de l’IM va suivre un processus de conception pouvant suivre
différents régimes de conception comme nous avons pu le voir précédemment (Canet,
2012). Birkinshaw, Hamel & Mol (2008) présentent ainsi un processus souvent repris
dans la littérature composée de quatre phases :
Une fois générée, l’innovation va suivre une certaine diffusion. Rogers définit cette
action comme « un processus par lequel une innovation est communiquée par certains
canaux au fil du temps parmi les membres d'un système social » (Rogers, 2003, p. 5). Il est
important de préciser ce qu’entend Rogers par « système social ». Le terme désigne aussi
bien la diffusion d’une innovation au sein d’un champ institutionnel, un certain nombre
d’entreprises en lien vont potentiellement se transmettre l’innovation en question. La
diffusion se fait dans une dynamique interorganisation. Puis, le second sens du « système
social » évoqué par Rogers concerne la diffusion au sein d’une même organisation.
Néanmoins la littérature se révèle être particulièrement faible sur ce second volet.
Compte tenu des nombreux travaux portant sur l’adoption des innovations, nous
proposons de clarifier le concept de diffusion d’une IM au sein d’une organisation en
reprenant d’une part les travaux portant sur l’adoption d’une innovation managériale.
Nous verrons au cours de la partie suivant qu’il est nécessaire d’approfondir la manière
dont une organisation entreprend l’adoption généralisée d’une innovation managériale.
129
2.3 Les processus d’adoptions des innovations
managériales
Parmi les différents modèles proposés dans la littérature, rares sont les travaux portant
uniquement sur le processus d’adoption des IM. Damanpour & Wischnevsky (2006),
présentent 7 phases (tableau 16), tandis que Damanpour & Schneider (2006) le réduisent
à 3 phases. La première phase concerne l'initiation et la décision. Elle comprend toutes
les activités liées à la perception des problèmes ou des besoins, à la recherche de
solutions, à la collecte d'informations sur ces solutions, à la formation des attitudes envers
ces solutions et à leur évaluation pour parvenir à une décision (Damanpour, 1991). Dans
notre travail, les membres de l'organisation que nous étudions découvrent l'existence
d'une méthodologie agile, évaluent sa pertinence, l'expérimentent et en discutent entre
eux jusqu'à ce qu'ils prennent la décision de la mettre en oeuvre dans une deuxième phase
(Damanpour & Schneider, 2006).
130
Ces deux types d’innovations sont adoptées en même temps dans bien des cas (Dubouloz,
2014).
Cependant, les recherches ayant été conduites sur l’adoption d’une innovation
managériale mobilisent uniquement une dimension processuelle (Damanpour & Aravind,
2012; Damanpour, 2014; Dubouloz, 2014). Or nous avons trois critiques à ce sujet. D’une
part lorsque les organisations adoptent des innovations, elles le font avec des attentes
élevées, anticipant les améliorations de la productivité et des performances de
l'organisation. Toutefois, l'adoption d'une innovation ne garantit pas sa mise en œuvre ;
les objets adoptés peuvent ne jamais être mis en œuvre (Giuliani et al., 2018).
D’autre part, dans le cadre de nos travaux, les méthodes agiles (que nous considérons
comme des IM) font l’objet d’une certaine dynamique d’évolution et de mises à jour dans
le temps. À notre connaissance, aucune recherche ne prend en considération les
évolutions des cadres méthodologiques adoptées et leur impact sur le processus
d’adoption, ce qui, de façon hypothétique, pourrait remettre en question la séquentialité
de l’adoption.
Enfin les processus d’adoption présents dans la littérature ne prennent pas en compte
la pluralité des contextes organisationnels. En effet comme nous avons pu le voir, les
projets SI d’une organisation sont par définition tous différents. Il est donc important
d’étudier l’organisation du déploiement conduisant à la mise en œuvre généralisée d’une
méthode au sein des projets. Nos travaux ont ainsi pour ambition d’investiguer ce
processus et nos contributions s’inscriront précisément au niveau de ce champ d’études.
Autrement dit, nous souhaitons clarifier les forces qui transfèrent une innovation à
travers les différents acteurs d’une organisation.
Phases
Auteurs
1 2 3 4 5 6 7
Damanpour (1991) Initiation Décision Mise en œuvre Poursuite de l'usage
Damanpour et Wischnesky (2006) Reconnaissance d'un besoin Recherche Evaluation Sélection Adaptation Mise en peuvre Routinisation
Damanpour et Schneider (2006) Initiation Décision Mise en œuvre
Les organisations dépassent dans bien des cas leurs frontières pour apprendre de
l'expérience des autres. Le transfert d'expérience s'effectue par différents mécanismes tel
que l'étude de la mise en œuvre d’une IM dans d'autres organisations, la sollicitation des
connaissances d'experts, l'embauche de consultants, la recherche de réactions des
membres internes, la formation de groupes consultatifs et la réalisation d'enquêtes
auprès des utilisateurs (Mol & Birkinshaw, 2014). Une fois mise en œuvre par plusieurs
131
organisations, l’innovation managériale peut être saisie par des « fashions-setters » qui
vont la promouvoir auprès des organisations sur le marché des modes managériales
(Canet, 2013).
Dans la perspective des modes managériales, il est considéré que les organisations
évoluent dans des conditions d’incertitude telles qu’elles ont tendance à imiter les autres
organisations (DiMaggio & Powell, 1983). Suivre la mode devient alors une question de
légitimité du gestionnaire qui prend la décision d’adoption, à la fois face aux parties
prenantes pour s’assurer de leur soutien (Abrahamson 1991), mais également face à la
hiérarchie.
q https://hbr.org/2016/05/embracing-agile
132
2.4 Le pilotage du changement induit par l’adoption
d’une innovation managériale
À cet effet, les travaux de David (1996) nous permettent de considérer quatre modèles
de pilotage du processus de changement que représente l’adoption d'innovations
managériales. Il identifie : un modèle politique, un modèle gestionnaire, un modèle
technocratique et un modèle de la conquête (tableau 17).
133
Modèle politique Modèle Modèle Modèle de la
gestionnaire technocratique conquête
Phase 1 Impulsion provenant Impulsion provenant L’intention est L’intention est locale
de hauts de hauts sommaire et ne (une équipe projet,
responsables responsables provient pas collaboration entre
(message autour de (message autour de nécessairement de départements)
l’IM) l’IM) hauts responsables
Phase 2 Les acteurs Les acteurs L’innovation est Les relations locales
accueillent accueillent élaborée fonctionnent et le
l’innovation par un l’innovation, indépendamment nouveau mode
discours, ils explorent les de l’organisation qui d’organisation est
inventent le contenu connaissances et va l’accueillir élaboré
du nouveau mode inventent le contenu
de fonctionnement du nouveau mode
de fonctionnement
Phase 3 Accompagnement Accompagnement L’innovation est Extension de
du processus de du processus de livrée aux l’expérience à
contextualisation et contextualisation utilisateurs pour l’organisation
évaluation a mettre en place
posteriori de la dans leurs contextes
qualité du résultat
Deux paramètres sont importants au sujet de ces différents modèles. Des crises
peuvent s’immiscer entre les différentes phases de tous les modèles évoqués par David
(1996). La crise peut se traduire par une situation de gel où les individus devant mettre
en place l’innovation rejettent celle-ci ou ne collaborent pas de façon homogène. Enfin, les
modèles précédemment évoqués peuvent coexister ou se succéder dans une organisation.
134
2.5 L’analyse critique du degré de nouveauté d’une
innovation managériale
Afin de clarifier la nature des innovations managériales, Adam-Ledunois & Damart
(2016 ; 2017), proposent une méthode d'analyse pour déterminer le degré de nouveauté
d'un objet de gestion. Les auteurs s’intéressent aussi bien aux « innovations managériales
en tant qu'objets produits à partir d'idées de gestion et de concepts génériques,
décontextualisés » et aux innovations managériales en tant qu'objets déjà "en usage" au
sein de la population d’une organisation.
Ils proposent ainsi deux approches à cet effet. La première est basée sur les
caractéristiques innovantes de l’objet de gestion en question relative au contexte
organisationnel. Il s’agit là d’analyser le degré de nouveauté de l’innovation au regard des
pratiques internes à l’organisation adoptante. La seconde approche est conceptuelle, et
se fie aux caractéristiques de l’innovation managériale par rapport aux pratiques et
connaissances dans l'état de l'art. Cette approche tend à identifier le degré de nouveauté
de l’innovation managériale par rapport à un ensemble de pratiques et connaissances ne
se limitant pas à une seule organisation.
D’autre part, les organisations peuvent entraîner aussi des modifications d'un outil de
gestion et le transformer en une véritable innovation managériale. La rupture peut se
situer à différents niveaux, au niveau local (si un outil de gestion est utilisé dans d'autres
départements d'une nouvelle organisation pour la première fois) ou à un niveau plus
général (si un objet de gestion n'a jamais été mis en œuvre ailleurs ou s'il n'a été appliqué
qu’au sein d'une population donnée d'organisations).
Quant à l'approche conceptuelle, les ruptures apportées par les outils de gestion sont
plus abstraites. Dans cette approche, la nouveauté d'un outil de gestion est comparée à
l’état des pratiques, méthodes, concepts, outils existants dans l’état de l’art. Un outil de
gestion peut être totalement nouveau dans le monde académique ou peut éventuellement
être négligé dans ce cas il n’est donc l’innovation managériale n’est pas « étiqueté ».
Afin de justifier la dimension dans laquelle un objet de gestion est innovant, les auteurs
proposent de considérer 3 ensembles d'éléments. Ils proposent d'abord d'analyser un
ensemble d'attributs de l'objet étudié (ensemble A), c'est-à-dire la définition et la
rhétorique de l'objet de gestion. Deuxièmement, un ensemble de pratiques dans le
135
domaine d'utilisation de référence (ensemble P)¸ ; il peut s'agir de pratiques au sein d'une
organisation dans laquelle l'objet de gestion est étudié. Il peut être analysé avec une
description historique des pratiques habituelles de l'organisation sur un domaine
d'utilisation ou pour une fonction particulière, à travers son histoire. Et enfin un état des
connaissances dans le domaine de référence (ensemble K), regroupe les concepts,
théories, principes, outils, méthodes, structures, processus ou philosophies développés
dans la littérature académique et qui permet de labelliser les objets de gestion qui servent
la même finalité que l'objet étudié. L’intersection de ces trois ensembles permet ainsi
d’identifier le caractère innovant de l’outil de gestion étudié.
En ce qui concerne l’approche conceptuelle, nous avons mené dans les chapitres 1, 2 et
3 un état de l’art nous permettant de clarifier les attributs clés des méthodes agiles en
nous focalisant principalement sur la méthode Scrum dans le chapitre 2. Nous avons pu
voir par ailleurs que les principes caractérisant l’agilité dans la conception des SI se
diffusent bien au-delà des frontières du développement de logiciels. Le tableau 18
reprend ainsi une synthèse (non exhaustive) des attributs de la méthode Scrum comparés
aux attributs des approches dites traditionnelles du développement de logiciels.
136
Analyse de la méthode Scrum comme innovation managériale conceptuelle
Contrôle qualité
Zone du Éléments Organisation des Suivi de
Cycle de conception Planification (implication des Documentation Mesure du succès
modèle d'identification équipes l'avancement
utilisateurs)
Scrum dans sa Itératif, incrémental auto-organisées et Adaptative avec Contrôle qualité Réduite au strict Un seul indicateur Correspondance du
première adaptatif et pluridisciplinaires plusieurs niveaux précoce et nécessaire au profit d’avancement, le produit livré aux
version concourant (à (chacun des permanent, d'incréments nombre de exigences durant
n'importe quel membres est censé au cours des fonctionnels pour fonctionnalités chaque itération
Attributs de la moment le projet pouvoir accomplir itérations l'utilisateur implémentées
méthode peut s'arrêter si toutes les tâches de (en valeur business)
Scrum l'utilisateur développement) et la charge de
(ensemble A) considère qu'il travail
remplit toutes ses restant à faire
exigences)
Le Code and Fix Non défini Non défini Très court terme Non défini Non défini Non défini Non défini
Développement Séquentiel Équipes avec des Prédictive basée sur Contrôle qualité en En forte quantité Mesure de la Respect des
en cascade ressources de longues plages fin de cycle. pour support à la conformité aux plans engagements
Cycle en V Séquentiel spécialisées et de planification communication, la initiaux et analyse initiaux
137
dirigées par un validation, la des écarts
Ensemble des responsable contractualisation
connaissances
(K) Développement Itératif et Partiellement Contrôle Non défini Mesure des risques Correspondance aux
en spirale incrémental prédictive l'équipe hypothétique de la et des coûts et de spécifications de
(utilisant le de projet doit qualité par le biais l'effort de départ
prototypage) décider de la des prototypes développement
quantité d'efforts à développés
fournir et les
exigences sont sont
Lorsqu'une méthode agile est introduite dans l'organisation et si elle est nouvelle pour
l'entreprise, l’adoption peut être assimilée au processus d'adoption d'une innovation
managériale. En effet, Vaccaro et al.,(2012) ont défini l'innovation managériale comme
étant nouvelle pour l'organisation qui la génère ou l'adopte. La nouveauté de l’outil de
gestion est justifiée si l'organisation n'a pas déjà adopté la nouvelle méthode. L'adoption
d'une méthode agile peut être considérée comme une transition d'un état à un autre
(Sidky et al., 2007).
Les travaux portant sur l’adoption d’une innovation managériale nous permettent de
compléter le cadre conceptuel des outils de gestion sur quatre aspects clés (tableau 19).
D’une part, nous avons pu relever le caractère processuel de l’adoption d’une innovation
managériale. En l’occurrence, ce processus nous sera utile pour comprendre les
différentes phases en œuvre au cours de l’adoption d’une approche agile de gestion de
projet. Nous avons pu par ailleurs souligner un gap théorique au niveau des processus
évoqués dans la littérature au sujet du caractère séquentiel et linéaire des processus ayant
été théorisés. Ainsi le caractère évolutif des méthodes agiles se révèle être un objet
particulièrement intéressant à analyser pour comprendre les éventuelles remises en
question du processus d’adoption.
La section précédente faisait l’objet d’une méthode d’analyse critique des innovations
managériales. Celle-ci nous permettra de mesurer l’évolution d’une méthode au cours du
processus d’adoption au sein d’une organisation. En prenant le cas de la méthode Scrum,
nous avons pu montrer que ce modèle d’analyse fonctionnait bien au niveau conceptuel.
Nous souhaitons ainsi mobiliser le modèle en complément des travaux autour de
l’appropriation des outils de gestion.
138
engendrées par l’adoption des méthodes agile, il nous parait utile d’analyser les sous-
processus de changement accompagnant l’adoption d’une méthode agile.
139
Synthèse du chapitre 4
Ce chapitre avait pour but de dresser le cadre conceptuel de notre travail de thèse en
mobilisant deux courants théoriques. D’une part, celui des outils de gestion, dont les travaux
ont principalement émergé dans les années 1980 en France, tente d’expliquer l’organisation
de l’action collective par les différentes formes d’instrumentation qui y sont associées.
Nous avons pu dresser dans un premier temps les différences terminologiques entre les
règles, objet, outils et dispositifs de gestion. Il figure à cet effet que de nombreux travaux
permettent d’expliquer le processus d’adoption d’un outil de gestion en raison du fait qu’ils
se révèlent nécessairement incomplets et contextuels. Dans cette optique, nous avons pu
présenter les travaux portant sur la formalisation-contextualisation et l’appropriation, ces
voies de recherche explorent les cycles de conception-usage des outils de gestion dans les
organisations. Nous avons pu de plus présenter un raisonnement considérant les méthodes
agiles comme des outils de gestion. Compte tenu des éléments abordés dans le chapitre deux
de la thèse, ce raisonnement nous a permis de conclure que la méthode Scrum se révèle être
un outil de gestion avec des propriétés particulièrement innovantes.
C’est dans cette perspective que nous avons cherché à compléter notre cadre conceptuel
par le biais des travaux portant sur l’adoption des innovations managériales. Dans ce courant
théorique, l’adoption peut être considérée comme un processus, comprenant diverses
séquences d’activités, de comportements et d’évènements qui conduisent à la routinisation
d’une innovation managériale (Gopalakrishnan & Damanpour, 1994). Dans cette approche,
une organisation cherche à adopter de nouvelles pratiques dans le but de tirer un avantage
concurrentiel et d'efficacité organisationnelle. Néanmoins, les travaux identifiés n’expliquent
pas la manière dont une organisation s’organise pour une adoption généralisée de
l’innovation. D’autre part, le processus d’adoption peut aussi être influencé par diverses
forces internes et externes sous l’impulsion des discours d’individus prônant des modes
managériales. Il est en outre important de souligner que le processus d’adoption d’une
innovation managériale s’accompagne de changements.
Il figure cependant, que les travaux portant sur l’adoption des innovations managériales
s’inspirent essentiellement de l’adoption des innovations dites technologiques. Bien qu’un
outil de gestion puisse être considéré comme une technologie gestionnaire pour l’action
collective (nous ne rentrerons pas dans ce débat-là), il nous parait important d’alimenter les
recherches autour de ces nouvelles formes d’organisation. Il semble ainsi intéressant
d’analyser dans un niveau microanalytique les activités qui conduisent à l’adoption d’une
méthode agile dans les projets d’une organisation tout en adoptant un regard macro-
analytique pour comprendre les dispositifs permettant le passage d’un usage contextuel
interne à un usage généralisé.
140
Synthèse du cadre conceptuel
Concepts et Théories
Chapitre 1 Chapitre 2
Historique des approches de Présentation et analyse du
conception de logiciels paradigme des méthodes agiles
Chapitre 3 Chapitre 4
L’adoption des méthodes agiles : L’adoption des méthodes agiles
un état de l’art au travers du prisme des outils de
gestion
141
De nombreux cycles de conception ont vu le jour pour contrer le fort taux d’échecs des
projets SI. Nous avons pu retracer à cet effet le paradigme de la conception agile avec
l’émergence de nombreuses méthodologies pour aider les équipes projet à s’adapter
continuellement à l’environnement complexe qui les entoure (évolutions des
technologies, des besoins utilisateurs, etc.) (Boehm, 2002). Compte tenu de leur caractère
dynamique et des forts enjeux portant sur la réussite des projets SI, la tendance à
l’adoption des méthodes agiles a été particulièrement forte ces dernières années au point
que de nombreuses organisations ont envisagé, comme en témoigne le président du
CIGREF, de les déployer à l’ensemble de leurs projets (Paasivaara & Lassenius, 2016,
2016b).
Nous avons pu voir néanmoins que l’adoption des méthodes agiles ne se révèle pas
nécessairement gage de réussite des projets. Comme le révèle l’émergence du mouvement
DevOps, il figure que l’ensemble des acteurs impliqués dans les projets (développeurs et
acteurs opérationnels) ne semblent pas nécessairement alignés sur les mêmes modes de
fonctionnement, ce qui a pour tendance de faire perdre les bénéfices escomptés de l’agilité
(Hemon & Rowe, 2019).
Parmi les nombreuses méthodes agiles dans l’état de l’art, la méthode Scrum semble
être particulièrement innovante au niveau de son cycle de conception. L’analyse
historique de sa genèse nous permet de comprendre la manière dont un outil de gestion
passe d’une logique contextuelle à une certaine forme de rationalisation. De ce fait, la
méthode Scrum et globalement les méthodes agiles ont donc connu une diffusion large
outre passant les frontières du développement de logiciels pour devenir des approches
de gestion de projet (Conforto et al., 2014; Conforto et al., 2016).
Dans cette optique, nous avons cherché à doter nos travaux d’un cadre conceptuel
construit en deux temps. D’une part, les travaux portant sur l’adoption des outils de
gestion (David, 1996; De Vaujany, 2005; Grimand, 2016; Hatchuel, 1994; Martineau,
142
2017) nous permettent de munir nos futures analyses de modèles permettant d’expliquer
les effets d’une méthode agile sur les dynamiques d’actions collectives. Dans cette
perspective, les travaux sur les outils de gestion permettent de comprendre les
transformations des activités et des organisations au cours du processus d’adoption
(Aggeri & Labatut, 2010). Plusieurs questions émergent de ce cadre conceptuel : que
deviennent les objets, outils et dispositifs de gestion dans les mains des acteurs qui les
instrumentent ? Comment sont-ils « rendus propres » ou impropres à un usage « socio-
politique », « psychocognitif » ou « rationnel » ? (De vaujany, 2006) Autrement dit,
comment sont-ils appropriés par les acteurs d’une l’organisation ?
L’adoption des outils de gestion nécessite encore de caractériser ce qui tend à canaliser
ou à faciliter ce processus afin de permettre aux acteurs d’une organisation de rendre les
trois éléments constitutifs d’un outil de gestion (substrat technique, philosophie
gestionnaire et système de rôle) « propres à un usage » généralisé (Aggeri & Labatut,
2010). Il y a donc selon (Aggeri, 2011)nécessité d’étudier des formes plus ouvertes et
distribuées d’innovation collective, combinant une variété d’instruments et associant
différentes organisations.
Dans un second temps, nous avons complété notre cadre théorique par le biais des
travaux portant sur l’adoption des innovations managériales (Ansari & Zajac, 2010;
Damanpour & Schneider, 2006; David, 1996). Nous avons ainsi pu souligner le faible
nombre d’études portant exclusivement sur des innovations en matière de gestion en
raison de la considération commune des innovations managériales par rapport aux
innovations technologiques.
143
Nous souhaitons caractériser 3 points clés de la généralisation que nous exprimons ci-
dessous sous forme de propositions de recherche auxquelles nos travaux visent à
apporter des éléments de réponse.
D’une part nous souhaitons examiner les dispositifs créés pour structurer la
généralisation d’une méthode. Nous souhaitons investiguer plus précisément la manière
dont les organisations accompagnent les équipes projet, ainsi que les départements
métiers qui ne sont pas engagés dans le développement ou la livraison des projets. Notre
première proposition de recherche aborde donc la question : quels dispositifs
contribuent à la généralisation d’une méthode agile ?
144
Partie 2 : Méthodologie de la recherche et
résultats empiriques
145
Chapitre 5 : Dispositif méthodologique et
posture épistémologique
Chapitre 6 Chapitre 7
Etude de cas pilote et analyse de Narration des trajectoires de
la figure naissante des coachs trois organisations complexes
agiles
146
Introduction
Comme les travaux se sont déroulés dans la cadre d’une convention CIFRE au sein du
cabinet Daylight consulting, nous retracerons les différentes phases de recherche de la
figure 24. Dans une première partie, nous préciserons l’émergence de la problématique
de recherche, le positionnement du doctorant au sein du cabinet, ainsi que sa posture par
rapport à l’objet de recherche étudié. Ces éléments nous permettront de détailler les choix
épistémologiques.
Nous détaillerons dans une deuxième partie les différentes phases de recherche en
précisant nos choix méthodologiques, les modalités de sélection des cas, le recueil des
données, les instruments d’analyse utilisés ainsi que les précautions méthodologiques
mobilisées tout au long du processus de recherche pour assurer sa validité et sa fiabilité.
Nous terminerons ce chapitre par une synthèse des différents choix effectués.
147
1. Contexte, positionnement du chercheur et
choix épistémologique
Les missions intègrent tout autant une dimension stratégique (alignement stratégique
d’un programme, management de portefeuille de projets, efficience de l’organisation à
l’échelle de l’entreprise, de la DSI ou des différentes unités d’affaires) que tactique et
opérationnelle (effectuer un diagnostic d’un projet, sécuriser et assurer un appui au
pilotage de projet, etc.). Le cabinet travaille essentiellement avec des clients privés du
CAC40 ainsi que de grandes administrations publiques.
148
de missions de conseils, ils fournissent en premier lieu un terrain d’investigation
privilégié pour les chercheurs du programme Aurore. La relation construite entre le
doctorant et les entreprises partenaires pour les travaux liés à cette thèse a toujours été
dépourvue de prestations spécifiques durant les investigations. Autrement dit, le
doctorant a toujours été considéré comme chercheur avec une posture d’observateur et
non de consultant prenant part au cours de l’action.
L’objectif des travaux de cette thèse a dès le départ été de nature exploratoire et
explicative en raison du caractère novateur du sujet tant pour les entreprises étudiées
que pour Daylight. Nous cherchons donc à comprendre « comment » s’établit ce
phénomène dans le temps (Langley & Royer 2006). Nous avons ainsi convenu avec
Daylight au début des travaux que la thèse devrait permettre :
1. D’analyser les dispositifs mis en œuvre pour déployer les méthodes agiles
appliquées aux projets SI de grandes organisations ;
2. d’identifier les facteurs clés influençant la généralisation ;
3. d’identifier le rôle des différents acteurs impliqués dans la généralisation ;
4. et enfin, expliquer les évolutions organisationnelles induites par la généralisation.
149
révèle être cohérent pour des travaux s’attachant à expliquer des phénomènes complexes
dans une optique longitudinale (Musca, 2006; Tsoukas, 1989).
D’un point de vue ontologique, la nature de la réalité dans le réalisme critique se révèle
essentialiste selon Thietart et al., (2014). Dans ce cas, la nature de la réalité existe en
dehors des contingences de sa connaissance, elle est indépendante de son observation et
des descriptions humaines que l’on peut en faire. Les défendeurs de ce courant
considèrent que les objets que nous étudions évoluent et sont constitués par des systèmes
ouverts pouvant difficilement être répliqués en laboratoire.
La manière d’observer les mécanismes complexes doivent selon Ohane (2011) cité
dans (Thietart et al., 2014) tenir compte de trois niveaux de réalité :
150
dans la section suivante que le choix de cette posture épistémologique nous impose un
mode de raisonnement spécifique quant aux différents travaux initiés.
L’abduction consiste à émettre des conjectures sur les causes possibles d’un certain
phénomène observé (Catellin, 2004) : « étant donné un fait B et la connaissance que A
implique B, A est une abduction ou une explication de B ». Dans le cas de nos travaux, nous
savons que les méthodes agiles engendrent des changements de fonctionnement dans les
projets. Néanmoins nous ne savons pas comment l’adoption généralisée d’une méthode
agile s’effectue, et les impacts de ce phénomène restent encore flous. Un raisonnement
par abduction tend à faire émerger des conjectures. Ainsi établies, elles devront ensuite
être mises à l’épreuve à travers une analyse théorique rigoureuse (Bhaskar, 1975).
Après avoir identifié dans notre revue de littérature le manque de travaux portant sur
notre objet de recherche, nous avons pu dresser un cadre conceptuel bien établi.
Toutefois, notre approche ne saurait être assimilée à de la déduction ou à de l’induction.
D’une part, nous ne cherchons pas à tester une théorie, et d’autre part nous ne supposons
pas observer la réalité dans l’objectif de formuler des lois universelles débouchant sur
une théorie.
151
de nos conclusions (au sens de Popper, 1995)), qui les distingue des lois universelles. Dès
lors, notre recherche propose des résultats plausibles, et non des conclusions certaines.
Ainsi, dans le cadre de notre travail, le raisonnement abductif consiste à interpréter les
données issues de nos études de cas, en les confrontant à la littérature existante, et ce,
pour élaborer des conclusions plausibles qu’il conviendra de tester ultérieurement pour
tendre vers le statut de règles.
En premier lieu, l’étude de cas est considérée comme une stratégie de recherche
particulièrement adaptée pour comprendre les changements organisationnels et les
phénomènes organisationnels complexes (Giroux, 2003; Hlady-Rispal, 2000). En second
lieu, conformément aux travaux de Yin (1994), le choix de l’étude de cas a directement été
motivé par la nature de notre question centrale de recherche. Le recours à des études de
cas se justifie lorsque « une question de type « comment ou « pourquoi » se pose sur un
ensemble d’événements contemporains sur lesquels le chercheur a peu ou aucun contrôle ».
L’étude de cas est par ailleurs souvent mobilisée dans la littérature portant sur l’adoption
152
des méthodes agiles (Benefield, 2008; Laanti et al., 2011; Paasivaara et al., 2018), elle nous
est donc apparue comme appropriée à la complexité du phénomène étudié. Une fois
décidées sur la méthode des cas comme stratégie d’accès au réel, nous avons dû définir si
notre recherche devait s’appuyer sur un ou plusieurs cas.
L’étude de cas multiple semble appropriée pour nos travaux dans le sens où elle
permet de rendre compte de façon détaillée des processus organisationnels complexes
(Musca, 2006). En effet, étudier les dynamiques de généralisation d’une méthode de
gestion de projet agile nécessite d’analyser le contexte, les différents faits et événements
clés d’organisations ayant lancé ce genre d’initiative.
De plus, l’intérêt de mener plusieurs cas réside dans le fait qu’ils permettent d’accroître
la généralisation des résultats en se donnant la possibilité que les événements et
processus observés ne donnent pas uniquement des analyses à des micros phénomènes
(Miles & Huberman, 2003). La multiplication des cas peut également être utile dans une
logique comparative et pour permettre de trouver des régularités ou des cas contraires
qui inciteront à approfondir la compréhension et l’explication. Son inconvénient est sans
doute de réaliser une analyse moins approfondie de chacun des cas.
Il est par ailleurs important de préciser si la nature des études de cas est intrinsèque
ou instrumentale. L’étude de cas instrumentale traite d’une situation qui comporte un
grand nombre de traits typiques par rapport à l’objet d’étude, fournissant une occasion
d’étude à potentiel élevé (Stake, 1994; Collerette, 1997; David, 2004). Tandis que l’étude
de cas intrinsèque révèle des caractéristiques unique ou très rare, ou encore difficile
d’accès pour la science, et susceptible de permettre de découvrir des choses qui ne sont
pas déjà connues. Nous avons opté dans nos travaux sur des études de cas plutôt
instrumentales en raison du fait que nous cherchons à identifier des régularités entre les
cas.
Comme nous nous appuyons sur les travaux portant sur l’adoption des innovations
managériales. Nous savons que ce processus peut se révéler être long et complexe en
fonction des organisations choisies. C’est pourquoi nous avons opté pour une démarche
en 3 temps. Après avoir formulé notre objet de recherche et afin de conforter notre choix
quant à la stratégie de recherche choisie, nous avons d’abord opté pour le lancement d’une
étude de cas pilote au cours d’une phase exploratoire (tableau 20).
Une étude de cas pilote aide à affiner les plans de collecte de données, tant en ce qui
concerne le contenu des données que les procédures à suivre (Yin, 1994). L’étude de cas
pilote peut se révéler être riche d’enseignements préliminaires et aide notamment à
élaborer des questions pertinentes pour enrichir le design de la recherche. Les premiers
résultats de l’étude de cas pilote nous ont ainsi confortés dans l’idée d’investiguer d’autres
terrains de recherche. Nous avons dans un troisième temps opté pour une phase
explicative des travaux dont le but était de multiplier les études de cas.
153
Au cours des travaux, une place à la discussion s’est révélée être essentielle pour affiner
les investigations dans les organisations choisies. Chaque phase de recherche s’est
clôturée d’une présentation auprès des partenaires de recherche du programme Aurore
afin de pouvoir discuter et amender des résultats dans les différentes organisations
membres. Le tableau ci-dessous synthétise le déroulé des différentes phases de recherche
ainsi que les types d’interactions et la posture du doctorant dans le cadre des travaux.
Principal type
Phase de d'interactions Posture du
Déroulé
recherche avec les chercheur
acteurs
Observation
1.1 Réunion d’orientation de la recherche juin 2016 non
participante Co-construction de
Construction la question de
1.2 Questionnements empiriques des acteurs du
de l’objet de Échanges recherche avec
programme Aurore
recherche informels l'équipe du
1.3 Définition de l’objectif de recherche avec Daylight
- programme Aurore
1.4 Lancement de la convention CIFRE au mois de février Réunions
2017
2.1 Première revue de littérature
2.2 Lancement d’une étude de cas pilote Indépendance du
Phase 2.3 Lancement d’une étude exploratoire auprès des agents Entretiens chercheur par
exploratoire du changement semi-directifs rapport aux acteurs
2.4 Présentation des résultats aux partenaires de entrant interrogés
recherche en juin 2017 exclusivement
3.1 Cas Banque de France dans le cadre
3.2 Cas GRDF d'une
recherche Interactions
3.3 Présentation des résultats préliminaires aux
Phase indépendantes avec
partenaires de recherche au mois de décembre 2018
explicative les acteurs
3.4 Cas Amadeus rencontrés
3.5 Présentation des travaux lors d’une rencontre de
recherche de clôture
Tableau 20 : Posture du doctorant dans les différentes phases de recherches
Nous proposons de détailler dans une seconde partie du chapitre tous les éléments
autour de notre stratégie de recherche, à savoir les critères de sélection des cas, la
synthèse des données récoltées, la méthodologie d’analyse des données au cours des
différentes phases des travaux.
154
2. Le choix d’une stratégie qualitative
2.1 Critères de choix des études de cas
La sélection des cas est une activité devant être menée de façon méticuleuse par le
chercheur. Entre similarité des caractéristiques et diversité des contextes, cette étape se
révèle fondamentale pour mener à bien des analyses pertinentes pour la suite des
travaux. Eisenhardt (2002) fait de la qualité de la sélection un déterminant majeur de
généralisation des résultats. Stake (1998) insiste, de son côté, sur l’importance de
l’adéquation entre les cas choisis et l’objet de la recherche. Pour Yin (1994), ainsi que
Miles & Huberman (2003), les études de cas multiples exigent que l’on soit explicite sur le
choix des cas à étudier (Creswell & Poth, 2017).
Selon Yin (1994), les cas doivent être sélectionnés dans une optique de réplication
littérale ou de réplication théorique. La réplication littérale permet de choisir des cas qui
ont des paramètres similaires et qui devraient obtenir des résultats similaires. L'approche
de réplication théorique est utilisée lorsque les cas ont des paramètres différents et sont
censés obtenir des résultats différents. Cependant, la logique de réplication à elle seule ne
fournit pas la ligne directrice méthodologique pour la sélection de cas multiples.
Ayant pour objectif d’analyser des cas dans une optique de réplication littérale, le choix
des cas s’est fait par le biais d’un échantillonnage théorique (Eisenhardt, 1989) basé sur
les quatre critères proposés par Hlady Rispal (2000) à savoir : la représentativité
théorique, la variété, la répartition équilibrée entre les cas et la richesse des données. Le
tableau 21 présente une synthèse de ces critères, les implications et le degré d’exigence
de chaque critère.
155
Les critères d’échantillonnages impliquent premièrement que les cas soient
suffisamment proches pour être comparés et produire des résultats similaires (Yin,
1994). Pour être sélectionné, un cas doit posséder suffisamment de traits en commun avec
les autres cas de l’échantillon théorique. Autrement dit, une certaine homogénéité des cas
du point de vue de la question à étudier est nécessaire. En lien avec notre revue de
littérature, il nous semblait essentiel de retenir :
- Des organisations suffisamment grandes pour détenir une Direction des Systèmes
d’information ou une entité développant des projets SI ;
- La constitution d’équipes intégrant des acteurs de différentes unités d’affaires ;
- L’existence d’un cadre de management des projets en interne (Méthodologie, outils,
etc.) ;
- L’adoption de la méthode Scrum depuis suffisamment longtemps au sein de
plusieurs équipes projet.
Ces choix nous semblent appropriés puisque les méthodes agiles sont principalement
mises en œuvre dans les projets SI. La dimension historique nous semble essentielle à
prendre en compte pour mieux comprendre les antécédents des cas. Au niveau des unités
d’analyses nous nous pencherons sur les projets SI, les individus liés aux projets (SI et
métier) les départements en charge de porter le développement des projets comme le DSI.
Nous proposons de détailler ces points dans la section 2.2.3 de ce chapitre.
156
propice pour initier des investigations puisqu’une convention de collaboration lie ces
organisations aux chercheurs du programme. Chaque partenaire fournit ainsi un contact
privilégié pour initier ensuite les mises en relation nécessaires pour couvrir les besoins
du chercheur. Ce point réduit ainsi un poids majeur en ce qui concerne la négociation
autour de l’accessibilité au terrain.
Au niveau de l’étude de cas pilote, les critères de choix ne sont pas très explicites.
L’objectif selon Yin (2014) réside dans le fait d’essayer de connaître davantage sur un
sujet dans lequel le chercheur détient peu d’informations. Cette étape est censée fournir
des résultats utiles avec des prétentions minimales pour affiner la stratégie de recherche
des autres cas. Nous avons donc appliqué les critères d’échantillonnage théorique
précédemment évoqués.
Après avoir défini l’ensemble des critères d’échantillonnage théorique, nous avons
constitué un inventaire des membres partenaires du programme Aurore et des clients de
Daylight. Une prise de contact a été initiée auprès de 20 entreprises différentes. Compte
tenu de ces critères et du champ d’investigation relativement restreint par les entreprises
partenaires et clients du cabinet Daylight, la Société Générale a été la première
organisation à nous offrir son terrain de recherche. Il figure de plus qu’il s’agissait de
l’entreprise ayant adopté la méthode Scrum parmi les premières de notre échantillon.
Nous avons donc initié l’étude de cas pilote au sein de cette organisation.
Pour la phase explicative, compte tenu des différentes opportunités terrain qui se sont
présentées à nous, nous avons ensuite opté pour trois organisations de tailles similaires,
mais différentes en termes de vocation, l’objectif étant d’enrichir les analyses (Thiétard et
al., 2014). Au niveau des partenaires du programme Aurore, nous avons collaboré avec la
Banque de France et Amadeus. Notre quatrième choix s’est porté auprès de l’entreprise
GRDF, qui compte tenu de son positionnement comme entreprise privée fournissant un
service public se révèle être un cas original. Nos relations avec un doctorant au sein de
l’organisation nous ont permis de mettre en place un protocole de recherche
collaborative.
Les quatre entreprises étudiées ont toutes décidé d’adopter une ou plusieurs
approches agiles venant se confronter ou s’adapter à un cadre méthodologique
initialement mis en place. D’autre part, elles se sont toutes lancées dans la généralisation
de la méthode Scrum avec différentes approches. Amadeus s’est par exemple lancé depuis
2013 dans plusieurs programmes de transformation agile successifs.
157
Banque de
Société Générale GRDF Amadeus
France
Étude de cas
Objet du cas Études de cas instrumentales
pilote
Développement
Oui Oui Oui Oui
de projet SI
Implication de
parties
prenantes dans
Oui Oui Oui Oui
les projets issus
Représentativité théorique
d’unités
d’affaires
Présence d’un
cadre de
Oui Oui Oui Oui
management
de projet
Année
d'introduction
2011 2015 2012 2013
officielle de
Scrum
État de la
Très avancée Débutante Initié Très avancée
généralisation
Type
Privée Publique Privée Privée
d'entreprise
Présence Internationale France France Internationale
Chiffre 20 milliards 5 milliards 3,5 milliards
4,4 milliards d'euros
d’affaires d’euros d'euros d'euros
Secteur Banque Services
Banque privée Industrie
d'activité centrale informatiques
Effectif total 148 000 11 690 11 802 17 093
Variété et équilibre
Ratio effectif IT
9% 10% 10% 29%
/ Effectif total
Effectif de la
5 651 1200 275 5000
DSI – R&D
Effectif de
collaborateurs
7 322 NC 900 NC
externes
DSI – R&D
Total des
12 970 1200 1175 5000
effectifs DSI - IT
158
2.2 Présentation des différentes phases des travaux
Cette partie propose de retracer le contenu de la phase exploratoire et de la phase
explicative. Nous présentons notamment l’instrumentation ayant été mise en œuvre pour
récolter les données au sein des cas et nous présenterons le protocole d’analyse des
données.
La Société Générale est un groupe fortement présent sur le territoire français ainsi que
sur le plan international. Elle emploie plus de 148 000 salariées au niveau global du
groupe et réalise un chiffre d’affaires de plus de 23 milliards d’euros. L’étude s’est
déroulée au sein du siège de la société à Paris, principalement en ayant traité avec les
acteurs d’une entité créée en 2014 dont le rôle est d’animer la communauté des managers
de projets (nous nommerons cette entité CMP). Nous avons pu d’autre part nous
entretenir avec différents acteurs des DSI en France.
L’entité CMP anime une communauté de plus de 4000 acteurs impliqués dans les
projets au niveau global du groupe, dont la majorité est en lien avec des projets SI. Nous
avons pu d’autre part nous focaliser sur l’une des quatre DSI du groupe puisque la SG
s’appuie sur une structure organisationnelle comportant une DSI par cœur de métier et
compte en France 4 DSI regroupant près de 15 000 individus. L’adoption de la méthode
Scrum a d’abord été initiée au sein de l’une de ces 4 DSI en 2010.
Deux points ont été déterminants dans le choix d’étudier en premier le cas SG. D’une
part, la taille de l’organisation et le nombre de projets en cours sont conséquents. Le
nombre de facteurs et d’acteurs y étant associés (contexte, nombres multiples
d’intervenants hiérarchiques, interactions entre les différents acteurs) fournit un terrain
de recherche particulièrement dense.
Yin (1994) présente six sources de données mobilisables dans le cadre d’études de cas
: la documentation, les archives, les entretiens, l’observation directe, l’observation
participante et la simulation. Eisenhardt (1989), (Pettigrew, 1995) et Stake (1995)
soulignent également cette diversité de sources, pour obtenir une image fidèle et valide
des entreprises étudiées. En effet, la force de la méthode des cas réside dans l’opportunité
de recourir à ces différentes sources dans le cadre d’une logique de triangulation qui
permet ainsi d’améliorer la validité du construit de la recherche.
Nous avons dans un premier temps privilégié les entretiens semi-directifs comme
source de données primaires. Les personnes ayant été interrogées sont principalement
des acteurs clés dans la généralisation de Scrum au sein de la Société Générale (tableau
23). Comme notre unité d’analyse porte principalement sur les projets SI des grandes
organisations, les acteurs ciblés ont principalement été choisis en raison du rôle joué dans
l’accompagnement à la mise en œuvre de Scrum.
D’une part, nous avons d’abord mené plusieurs entretiens semi-directifs avec des
acteurs externes notamment des consultants et formateurs de Daylight intervenu dans la
mise en place du cadre méthodologique de gestion de projet. Puis les entretiens se sont
poursuivis avec des acteurs internes de différents niveaux hiérarchiques des DSI (projet,
directeur de programme de transformation, coachs) ainsi que des acteurs en charge
d’animer la communauté de management de projet. Le choix des individus n’a pas été
précisément défini au départ en raison du fait que l’organisation se révèle très dense.
Nous avons donc progressé dans l’organisation par le biais de mises en relation proposées
par les individus interrogés. Cette manière de procéder peut-être qualifiée au sens de
Girin (1989) d’opportuniste méthodique.
160
en question portait sur l’organisation du coaching des équipes d’une des DSI et la seconde
rassemblait les responsables d’entités dédiés au coaching (centre agile) des quatre DSI en
France. L’objet de cette dernière portait sur la construction d’une formation à destination
de tous les acteurs impliqués dans les projets.
Le déroulé des entretiens se sont appuyés sur un guide construit autour des différentes
phases d’adoption d’une innovation managériale, à savoir : la reconnaissance d’un
besoin ; la recherche ; l’évaluation ; la sélection ; l’adaptation et la mise œuvre
(Damanpour & Wischnevsky, 2006). Nous avons aussi complété les questionnements en
abordant des sujets portant sur les changements engendrés par la mise en œuvre d’une
méthode agile.
161
Le guide d’entretien dont un extrait est présenté en figure 25 a été mis à jour à l’issue
de l’étude de cas pilote. Les entretiens menés au cours la phase exploratoire nous ont
permis de compléter les questionnements pour les entretiens menés au cours de la phase
explicative. Nous reviendrons sur ce point au cours de la section 2.2.4
Dans un second temps, nous nous sommes orientés dans la récolte de données
documentaires. Selon Yin (1994), le rôle des documents consiste essentiellement à
corroborer des informations et à augmenter la validité des autres sources. Les documents
sont également un excellent support pour valider des éléments évoqués lors des
entretiens. La récolte documentaire nous a permis de comprendre plus finement les
événements évoqués en entretiens, ce qui nous a permis de faciliter et d’améliorer la
qualité du codage des données. Nous avons donc eu recours à des données internes
traitant notamment : des supports de présentation abordant les initiatives de
généralisation (plan de transformation, acteurs mobilisés, etc.) ; des documents
provenant des projets ; le cadre méthodologique de gestion de projet au niveau du groupe
et de nombreux supports de formation (tableau 24).
10 70
internes
Présentations
Documents projet 5 30
Support de formation 6 400
Vidéos de témoignages
10 100
transcrites
Documents
externes
Articles de presse 7 15
Rapport d'activités 3 1000
Communication web 4 15
TOTAL 43 1 742
Tableau 24 : Compilation des données secondaires du cas Société Générale
Il figure de plus que nous avons récolté un très grand nombre de données sur le web.
Les vidéos de témoignages d’acteurs des différentes DSI sont nombreuses. La Société
Générale communique énormément sur ses pratiques de travails dans différentes
conférences professionnelles (tableau 25). Nous avons donc profité de cette aubaine pour
récolter les vidéos, les transcrire et les intégrer dans notre corpus de données.
Le tableau 25 liste l’ensemble des vidéos de témoignages identifiés sur le web. Les
éléments de discours nous ont permis de trianguler l’analyse des données dans Nvivo en
veillant à démultiplier les sources lors de l’encodage des nœuds.
162
Entité de Date de
N° Acteur témoignant Liens d'accès au contenu Durée
rattachement publication
Manager DSI et coach https://www.youtube.com/watc
1 DSI 3 13/10/2012 35 minutes
agile h?v=8IsGcFXll18
Directeur d'une DSI et https://www.youtube.com/watc
2 DSI 1 29/09/2014 51 minutes
coach agile h?v=_cY2UAi2Stc
https://www.youtube.com/watc
3 Directeur de la DSI DSI 1 27/06/2014 44 minutes
h?v=sXLFD35PRtk&t=1141s
Chef de projet et https://www.youtube.com/watc
4 DSI 1 04/01/2016 51 minutes
développeur h?v=iZwM9Xstts8
Coach agile et https://www.youtube.com/watc
5 DSI 1 19/12/2016 32 minutes
développeur h?v=LwuBs2N4BiM
Coach agile et https://www.youtube.com/watc
6 DSI 3 08/11/2017 44 minutes
développeur h?v=_zPOaw_R1Sw
Directeur d’un DSI et
https://www.youtube.com/watc
7 responsable d'une DSI 1 25/10/2018 31 minutes
h?v=nFHi7N8Dsy0
unité d'affaires
Directeur d'une DSI et https://www.youtube.com/watc
8 DSI 1 18/11/2018 47 minutes
coach agile h?v=_zPOaw_R1Sw
https://www.youtube.com/watc
9 Coach agile DSI 3 14/07/2019 39 minutes
h?v=y54sxn9O_M8
https://www.youtube.com/watc
10 3 Coachs agiles DSI 1 31/10/2019 34 minutes
h?v=tl2NjXznkLc
6h 48
TOTAL
minutes
Tableau 25 : Synthèse des vidéos et témoignages récoltés
L’étude de cas pilote nous a permis d’initier un premier tour d’analyse des données.
L’objectif étant d’identifier une première approche de traitement des données afin de
préparer au mieux les analyses de la phase explicative. Il est par ailleurs important de
préciser que les analyses menées dans le cas Société Générale (SG) ont été harmonisées
avec les analyses des cas de la phase explicative menées ultérieurement.
163
Notre démarche de codage a d’abord consisté à bâtir un plan général de codage
mentionnant les principaux domaines dans lesquels les codes ont inductivement été
intégrés. Néanmoins comme le préconisent Ayache & Dumez (2011)r, nous avons tout de
même repris une liste de catégories provenant des 5 phases d’adoption des innovations
managériales proposée par Damanpour & Aravind (2012). Dans un second temps, cette
liste a été corrigée et enrichie par la technique du codage thématique proposée par Miles
& Huberman (2003).
Le codage thématique vise à identifier dans les textes, des passages liés à des catégories
ou des événements afin de les coder, les découper, et regrouper ensemble ceux qui ont la
même identification. La figure 26 ci-dessous présente un exemple de codage en pratique
ayant été appliqué aux différentes données récoltées. L’extrait suivant présente une unité
de sens issu du témoignage d’un directeur d’une DSI. Afin d’être étiquetées comme un
événement, nous avons systématiquement cherché à identifier dans les unités de sens : la
temporalité de l’événement, la nature de l’événement et la description de l’événement
(Hussenot & Missonier, 2016). Une fois ces trois caractéristiques identifiées, l’unité de
sens a été étiquetée dans Nvivo par le nom : DSI-1-EV-1- Première adoption de Scrum
par les équipes - présentation au DSI. Ce nœud a ensuite été classifié dans une période
correspondant à l’année 2011.
Description de l’événement
Notre démarche d’analyse des données au cours de la phase exploratoire est ainsi
synthétisée dans le tableau 26 au niveau des 3 premières étapes. Un second tour de
réduction des données a été effectué par la suite en 2020. Au-delà de la reconstitution
chronologique des différents événements caractérisant les mécanismes conduisant à
l’adoption généralisée de la méthode Scrum. Il a fallu créer des relations entre les
r Le codage inductif provenant de la théorisation ancrée, qualifié d’ « originel » ou de « pur », est selon
les auteurs impossible en pratique. Ils préconisent ainsi d’établir une liste de catégories à affiner au cours
du codage des données.
164
événements afin d’identifier les séquences d’événements (Hussenot and Missonier, 2016;
Oiry et al., 2010) (étape 5 du tableau 26).
Il est important de souligner le fait que le traitement des données préliminaires ayant
été mis en œuvre dans l’analyse de ce cas (étape 1 à 3) nous a permis d’affiner nos choix
165
dans la mise en œuvre d’analyses processuelles pour la suite des travaux. Nous proposons
dans la section 2.2.4 le protocole de réduction de données final (étapes 5 et 6 du tableau
26) ayant été appliqué à toutes les études de cas.
L’adoption d’une innovation managériale peut être envisagée sous l’angle des facteurs qui
la favorisent ou des facteurs qui la freinent, voire la bloquent. Cette distinction est à l’origine
de deux courants de la littérature, l’un se réclamant de l’étude des déterminants de l’adoption
d’une innovation, l’autre, plus marginale, de l’étude des barrières (Keupp et al., 2011). Notre
recherche s’est donc consacrée au cours de la phase exploratoire à l’identification de
facteurs qui permettent d’accélérer ou de freiner l’adoption généralisée d’une méthode
agile. Nous avons choisi de mettre en place des entretiens semi-directifs auprès des
coachs spécialisés dans la mise en œuvre de ces approches.
L’intérêt d’analyser la posture de ce genre d’acteur réside dans le fait qu’ils détiennent
par le biais de leurs interventions au sein de différentes organisations, une vision
démultipliée des démarches d’adoption et des évolutions organisationnelles induites par
la généralisation. Ce sont d’autre part des acteurs peu sollicités dans le cadre d’études à
vocation scientifique (Dikert et al., 2016a). Nous avons donc souhaité obtenir la vision des
coachs intervenant en dehors des études de cas étudiés afin d’identifier les déterminants
et les barrières à la généralisation.
Le recrutement des entretiens s’est principalement fait par le biais d’un mailing sur le
réseau social LinkedIn. Dans le cadre de la recherche de profils, nous avons uniquement
utilisé le mot- clé suivant : coach agile. Ainsi, 3700 profils ont été trouvés en France, s’en
est suivi une présélection de profils dont les critères principaux étaient le nombre
d’années d’expérience lié aux approches agiles et l’intervention dans plusieurs
entreprises. Nous avons ainsi pris contact avec 90 coachs et 15 se sont portés volontaire.
Tous les entretiens se sont déroulés avec des coachs qui interviennent en France et se
sont tenus en face à face ou à distance par visioconférence. En moyenne, les coachs ont 7
ans d’expérience dans la mise en œuvre des approches agiles, et sont dans chaque cas
intervenu dans plusieurs organisations (tableau 27).
Chaque entretien a duré en moyenne une heure, et a été appuyé par un guide abordant
deux phases : la première consistait à échanger au sujet du parcours du coach et de son
expérience afin de mieux comprendre les contextes d’intervention. Puis dans un second
temps, il a été abordé le volet de la généralisation en évoquant les facteurs clés du succès
et les freins identifiés. En fonction du déroulé des entretiens, nous avons complété le guide
par le biais de questions d’investigation et d’implication en fonction des points abordés
(Thiétart et al., 2014).
166
Rubin & Rubin (1995) définissent trois types de questions, les « questions principales »
qui servent d’introduction ou de guide dans l’entretien, les « questions d’investigation »
destinées « à compléter ou clarifier une réponse incomplète ou floue, ou à demander
d’autres exemples ou preuves », et les « questions d’implication » qui font suite aux
réponses aux questions principales ou visent à élaborer avec précision une idée ou un
concept. Les questions d’investigation et d’implication ne peuvent être préparées en
amont. Elles doivent être aménagées par le chercheur au fur et à mesure de l’entretien.
Phase de Durée
Expérience liée Nombre
recherche N° Statut Secteur d'intervention du coach en
au coaching d'entreprises suivi
minutes
Entretiens 1 Employé Industrie automobile 6 ans 3 100
menés au interne
cours de la 2 Employé en Énergie - Banque 4 ans 3 65
phase SSIIs
exploratoire 3 Employé Grande distribution 10 ans 10+ 65
interne
4 Indépendant Logistique - Transport 2 ans 2 65
5 Indépendant Banque - Assurance - Industrie 10 ans 10+ 100
6 Indépendant E-commerce 5 ans 4 55
7 Indépendant Banque - Assurance - Industrie 10 ans 10+ 90
8 Indépendant Banque - Assurance 13 ans 10+ 70
9 Employé en Banque - Assurance 6 ans 5 70
SSII
10 Indépendant Banque - Administration publique 14 ans 10+ 60
Complément 11 Employé en Banque - Assurance 6 ans 10+ 65
au cours de la SSII
phase 12 Indépendant Banque - Assurance 10 ans 10+ 55
explicative 13 Employé en Industrie aéronautique 8 ans 10+ 70
SSII
14 Indépendant Banque - Assurance 4 ans 5 70
15 Indépendant Industrie aéronautique 8 ans 10+ 90
Tableau 27 : Récapitulatif des entretiens réalisés avec les coachs agiles
Comme pour l’étude de cas pilote, nous avons procédé à une première phase de récolte
des données auprès de 10 coachs durant la phase exploratoire, ce qui nous a permis de
procéder à la mise en place de premières analyses. Le codage thématique appliqué aux
corpus des données transcrites nous a permis d’aboutir à l’identification de 5 groupes de
facteurs accélérateurs et de 5 groupes de facteurs freinant la généralisation des approches
agiles.
167
La phase explicative nous a conduits dans un second temps à clarifier la posture des
coachs (figure 27). En effet, les coachs agiles ont été perçus dans l’étude de cas pilote
comme des agents clés du changement auprès des équipes projet ainsi qu’auprès des
différentes parties prenantes aux projets. Nous avons donc souhaité approfondir les
analyses de ces travaux par un complément de 5 entretiens, puis en effectuant un codage
thématique autour de la relation conception-usage qui s’établit entrent les coachs et les
différents acteurs d’organisations impactées par la généralisation d’une approche agile.
Cette deuxième vague d’entretiens nous a ainsi permis de clarifier le « coaching agile »
souvent évoqué dans les études de cas.
Figure 28 : Découpage des unités de sens appliqué aux entretiens des coachs agiles
L’ensemble des données récoltées ont été synthétisées dans deux tableaux compilant
l’ensemble facteurs identifiés. Nous présenterons ces résultats dans le chapitre 6. La
deuxième vague de codage de ces travaux a de plus abouti à la création d’une taxonomie
168
permettant de clarifier le rôle et les différentes postures des coachs agiles. Ces travaux se
révèlent particulièrement en phase avec les figures d’acteurs naissantes.
Nous proposons dans cette section une présentation succincte des cas de la phase
explicative afin de préciser les unités d’analyses traitées dans les cas. Nous traitons dans
nos travaux d’études de cas dites « instrumentales », dans cette optique, le cas est lu à
travers une théorie retenue a priori, et l’analyse empirique se fait à l’aune de cette théorie.
Même s’il est nécessaire de prendre en compte un certain nombre d’éléments de contexte
pour une analyse rigoureuse et pour éviter que le cas ne soit qu’illustratif, l’étude de cas
instrumentale génère une double interrogation du cas par la théorie et de la théorie par
le cas (David, 2004).
Fondée en 1800 par Napoléon Bonaparte, la Banque de France (BDF) est une
institution indépendante régie par le droit français et européent. Elle est membre de
l'Eurosystème, qui est le système fédéral comprenant la Banque Centrale Européenne et
les banques centrales nationales de la zone euro. Ses trois principales missions portent
sur la stratégie monétaire de la France, la stabilité financière et la fourniture de services
économiques à la communauté européenne.
La Banque de France est une personne morale de droit public « sui generis », elle ne fonctionne ni
t
169
Merise au départ, le cadre méthodologique a été amélioré par le biais des bonnes
pratiques du PMBoK par la suite.
Les équipes projet de la DSI de la Banque de France ont depuis 2013 mis en place des
premiers essais de projets conduits avec la méthode Scrum. En 2014, Scrum a été adaptée
et alliée avec la méthode de gestion de projet interne et depuis le mois de septembre 2018,
une décision du Gouverneur de la Banque de France impose à tous les projets, la mise en
place de la méthode Scrum.
170
La spécificité de cette étude de cas réside dans le fait que nous ne traiterons pas de la
DSI d’Amadeus, mais plutôt de l’entité dédiée à la recherche et développement (R&D). Les
équipes de la R&D sont composées principalement d’ingénieurs logiciels, ils sont
responsables de l'ensemble du cycle de développement de la conception à la livraison,
ainsi que de la couverture opérationnelle des applications vendues par l’entreprise. Les
rôles des ingénieurs englobent la spécification des produits, le développement de
logiciels, l’assurance qualité et le déploiement opérationnel auprès des clients externes.
L’objet d’analyse ici n’est donc pas la DSI, mais le département R&D et ses projets, dont
les solutions logicielles sont destinées à des clients externes de l’entreprise. Le cas
Amadeus se révèle être un cas particulièrement intéressant pour diversifier les cas.
Créée en 2008, à la suite de l’ouverture des marchés publics de l’énergie, Gaz Réseau
de France (GRDF) à hériter des activités de distribution de gaz naturel de l’organisation
initiale qui était Gaz de France. Aujourd'hui filiale neutre et indépendante du groupe
ENGIE, GRDF est une société anonyme. L’entreprise à la principale vocation de construire,
exploiter et entretenir le réseau de distribution du gaz d’une part. Sa seconde mission
porte sur la distribution du gaz. Délégataire d’une mission de service public, le
développement d’activités numériques tend à prendre de l’importance par rapport aux
activités historiques. Dans le même temps, GRDF, loin d’être uniforme est une
organisation bicéphale où cohabite une organisation centralisée, incarnée par le siège
La certification validant les connaissances et la maitrise des bonnes pratiques proposées dans le
u
171
social de l’entreprise et l’approche en réseau à travers les agences régionales. Le siège
concentre le choix des décisions qui sont ensuite mises en application localement.
La DSI de GRDF est composée au total de 1175 acteurs, dont près de 900 provenant de
centres de services externes. Ce sont essentiellement des sous-traitants intervenant dans
le cadre de contrats de régie avec la DSI. Au niveau applicatif, la DSI gère un patrimoine
de 170 applications et de 184 projets de développement en cours (en janvier 2018). La
DSI de GRDF a notamment fait le choix en 2012 de créer une cellule interne de
développement des projets en mode agile pour accentuer ses efforts dans la
transformation digitale de ses métiers.
Malgré la taille de l’entité et les nombreux projets en cours, la DSI de GRDF est une
entité jeune faisant preuve d’une moindre maturité comparée aux autres cas choisis dans
le cadre de nos travaux. Cette spécificité fait du cas GRDF un premier point de singularité
du terrain de recherche. De plus, la généralisation de la méthode Scrum s’est déroulée non
pas par la mise en place d’un programme de transformation, mais plutôt par la création
d’une nouvelle entité dont la croissance organique engendre la généralisation de Scrum.
Le cas GRDF complète ainsi notre panel d’organisations investiguées.
Pour Lecocq (2002), la validité des résultats d’une recherche est largement déterminée
par la réflexion menée par le chercheur sur le ou les niveaux d’analyse retenus. En
fonction des problématiques, l’unité d’analyse peut concerner aussi bien l’individu, le
groupe, l’organisation dans son ensemble, l’inter-organisationnel, les inter-relations entre
plusieurs niveaux, voire un événement. La détermination du niveau de l’unité d’analyse
fixe les limites nécessaires à la collecte des données, et influence ainsi l’analyse et
l’interprétation de ces dernières.
Concernant les unités d’analyses retenues pour nos travaux. Les méthodes agiles étant
adoptées principalement dans les projets de développement des SI, il nous a paru ainsi
évident d’analyser cette unité d’analyse. D’autre part, comme les projets SI rassemblent
des acteurs de différentes entités (DSI, R&D et unité d’affaires), il nous parait important
d’inclure ces entités dans les unités d’analyses des cas (parties bleues de la figure 29).
172
Figure 29 : Unités d’analyses des cas
La plupart des recherches sur les processus organisationnels portent sur des études de
cas rétrospectives, une fois les résultats connus. Or, il est indéniable qu’une connaissance
préalable du succès ou de l’échec d’un changement stratégique biaise les résultats de la
recherche. L’analyse historique est toutefois nécessaire pour aborder un grand nombre
de questions. Pour limiter le biais précédent, Van de Ven (1995) préconise soit de
démarrer l’étude de cas avant de connaître l’issue de l’action de changement, soit
d’étudier en temps réel un processus de changement stratégique. Il est donc nécessaire
pour le chercheur de se placer lui-même dans la temporalité et le cadre de référence
contextuel des organisations. Cela va impliquer de mener une étude de cas rétrospective
pour comprendre le contexte et les événements qui sous-tendent les mécanismes étudiés.
Langley, Smallman, Tsoukas, & Van de Ven, (2013) précisent qu’il faut veiller à observer
en temps réel les événements et activités liées au développement d’un changement
organisationnel, sans connaître a priori les résultats et conséquences de ces événements
et activités.
La collecte des données dans les trois cas de la phase explicative s’est déroulée de
manière progressive (figure 30). Nous avons recueilli des données processuelles issues
majoritairement d’entretiens semi-directifs, d’observations non participantes, de récits
d’événements et de données secondaires.
173
Figure 30 : démarche de récolte des données
Avant de lancer les investigations dans chaque étude de cas, un protocole de recherche
a été établi sur la base des apprentissages de l’étude de cas pilote. Ce protocole aborde
notamment les besoins du doctorant en termes d’acteurs à rencontrer, des types de
documents à récolter et le temps de présence sur le terrain. Ce protocole a permis
d’encadrer la relation entre le doctorant et un acteur référent dans la mise en relation
avec les informants dans chaque cas.
La suite a abouti sur une série d’entretiens menés de façon systématique et délibérée
avec différents individus à des fins de comparaison. Pour éviter toute restriction, nous
avons veillé à ne pas scrupuleusement rester dans le cadre de notre guide d’entretien
lorsque les acteurs abordaient des sujets ou des faits qui pouvaient influencer l’objet
d’étude. Les entretiens ont été conduits de façon heuristique et émergente à des fins
d’accumulation de la connaissance au sein des différentes organisations.
Le guide d’entretien tel qu’il figure en annexe n’est pas un questionnaire ouvert, mais
un aide-mémoire qui permet de vérifier qu’aucun point important n’a été oublié. Pour
Stake (1995), la flexibilité du chercheur est un élément déterminant du succès de la
collecte des données par entretien. En suivant les recommandations de cet auteur, nous
avons adapté l’ordre et la teneur des questions aux réponses de notre interlocuteur, en
gardant bien à l’esprit le fait que l’entretien semi-directif se fait sur le mode de la
174
conversation (Demers, 2003). Ainsi, l’ensemble des différentes questions, présentées
dans le guide d’entretien, n’a pas toujours été entièrement abordé.
Un des aspects clés de la réalisation des entretiens a consisté à déterminer les acteurs
susceptibles d’apporter des éléments de réponse à notre problématique. Nous nous
sommes intéressés dans cette optique à des acteurs ayant des niveaux hiérarchiques,
fonctions et positions différents vis-à-vis des projets SI.
Au total, ce sont 42 entretiens ayant été menés auprès de 38 personnes dans les trois
cas. Tous les entretiens ont une durée minimale d’une heure, l’inventaire total des
entretiens figure en annexe et comporte les détails concernant la durée des échanges et
les dates de tenue. Comme l’analyse des données tient compte des faits et événements
dans une dimension rétrospective, nous avons veillé à ce que chacun des acteurs
interrogés puisse à minima avoir plus de deux ans d’expérience.
175
Cas Posture du Type de réunion Participants Date de
doctorant l'atelier
BDF Observation non Réunion de définition des nouvelles 6 29/03/2018
participante tâches du Bureau des projets
BDF Observation non Réunion de définition des nouvelles 6 09/04/2018
participante tâches du Bureau des projets
BDF Observation non Réunion de définition des nouvelles 6 15/04/2018
participante tâches du Bureau des projets
GRDF Observation non Lancement d’un projet - Sprint 0 - 10 15/10/2018
participante projet Fabrique Agile
Tableau 28 : Synthèse des réunions et ateliers
Nous avons eu d’autre part recours à des données secondaires récoltées de différentes
manières. Dans le cas de la Banque de France, comme Daylight est intervenu dans le cadre
de missions de conseils, nous avons pu ainsi avoir accès à un corpus de documents
intéressant autour du cadre méthodologique de gestion des projets, des présentations
d’entités internes, et des appels d’offres. Dans le cas GRDF, la récolte de données
secondaire s’est faite en collaboration avec Antoine Henry, ancien doctorant ayant mené
une thèse CIFRE au sein de la DSI de GRDF. Le tableau 29 ci-dessous dresse un état de
l’ensemble des données secondaires récoltées.
Rapport
3 300 2 40 2 200
d'activités
Méthodologie
6 120 1 2
projet
Support de
1 29 1 20
formation
Appel d'offres 3 10
Présentations 4 45 5 50 3 50
Documents externes
Documents
5 30 60 500
projet
Articles de
7 15 18 25
presse
Vidéo de
témoignages
Communication
25 45
web
TOTAL 29 524 87 647 33 320
Tableau 29 : Récapitulatif des sources de données secondaires
176
Il nous semble également important d’indiquer que la collecte des données s’est
poursuivie au-delà de notre présence intensive sur le terrain. En effet, lors des étapes de
retranscription des entretiens et d’analyse des données, nous avons été amenés à
solliciter nos contacts terrain pour des compléments d’information (questions ou
demande de certains documents), essentiellement via l’échange de courriers
électroniques.
Ensuite, lors de restitutions préliminaires, les échanges ont fait l’objet de prises de
notes. Enfin, dans le cadre de la rédaction d’un article, en vue d’une publication dans une
revue ou d’une communication dans un colloque, nous avons systématiquement soumis
les articles à la lecture par les acteurs clés identifiés au sein des entreprises. Cette
validation avait deux objectifs : la validité interne des résultats présentés dans l’article, et
la garantie du respect et du secret de certaines informations divulguées, comme convenu
dans le protocole de recherche établi avec les entreprises.
Avant de préciser la manière dont nous avons procédé pour découper et coder le
corpus, il est important de revenir sur le fait qu’une analyse basée sur un codage qualitatif
peut créer un phénomène de circularité selon Dumez (2016). La circularité dans l’analyse
des données se réfère à un matériau préstructuré par les cadres théoriques mobilisés. Le
chercheur est dans l’illusion d’avoir créé de la connaissance quand il « valide » le cadre
théorique mobilisé sur un matériau empirique. Les analyses préliminaires menées au sein
du cas SG nous ont donc permis d’initier une réduction des données plus fine. Nous avons
ainsi directement procédé à un codage des événements sans catégories prédéfinies.
L’étude de cas pilote nous a permis de conforter nos choix quant à l’appui de nos
analyses sur les approches processuelles. Il existe deux types d’approches processuelles,
l’approche dite « faible » a pour objectif de comprendre les trajectoires d’évolution des
organisations dans le temps ou les démarches d’innovation (Hussenot & Missonier, 2016).
Les fondations de ce courant sont basées sur de nombreux travaux datant des années
1990 (Van de Ven & Poole, 1995), (Pettigrew, 1997) et Langley (1999). L’approche
processuelle dite « forte », a quant à elle, l’objectif de comprendre le mouvement
permanent de définition des acteurs, des technologies et de leurs relations. L’organisation
n’est donc pas considérée comme une entité à un instant t, elle se révèle être plutôt un
mouvement permanent de création d’entités et de configurations.
Nous avons pour notre part, fait le choix d’appliquer une approche processuelle forte
en raison du fait que l’étude de cas pilote ayant été menée nous a permis de mieux
discerner la création de nouvelles entités pour favoriser la généralisation de Scrum. La
question de l'événement pour comprendre l'organisation a été soulignée par de
nombreux auteurs dans les études en théories des organisations (Chia & King, 1998;
177
Hernes, 2014; Van de Ven & Poole, 1995). L’approche par les événements proposée par
(Langley, 1999 ; Hussenot & Missonier, 2016), permettent de relever les défis posés par
la mobilisation d’une approche forte en considérant les événements par des structures
d’événements. Autrement dit, chaque événement se tenant à un instant t est lié par des
événements passés, présents et futurs qui eux-mêmes influenceront l’émergence d’autres
événements. Cette continuité dans l’unité d’analyse permet de révéler des dynamiques
organisationnelles.
En ce sens et compte tenu des différentes étapes évoquées dans la partie 2.2.2, le
traitement des données s’est déroulé en suivant 6 étapes synthétisées dans le tableau 30
que nous proposons de détailler et d’illustrer.
v Nous tenons à remercier Amandine Pascal pour les suggestions de ce cadre d’analyse.
w Computer-assisted qualitative data analysis software
178
analyses reposant sur ses capacités d’interprétation. Une fois les données centralisées,
nous avons pu préparer l’analyse au cas par cas.
Un des moyens pour contrer l’effet de circularité évoqué précédemment réside dans la
technique de la lecture flottante (Ayache & Dumez, 2011). De cette manière, le chercheur
s’imprègne de son matériau de recherche en évitant de créer des catégories issues d’idées
préconçues. La lecture flottante permet de faire connaissance avec les documents à
analyser en laissant venir à soi les impressions et certaines orientations afin de délimiter
le champ d’investigation.
Dans cette optique, nous avons d’abord procédé à une lecture du corpus des données
puis réalisé une première identification des contextes et événements clés en codant le
corpus de données à la main. Nous avons à cet effet utilisé des Post-its et des feuilles de
papier A1 afin de pré figurer les contextes comme sources d’opportunités ou de
contraintes, les événements clés et les faits saillants (une photo des feuilles A1 est
présentée en annexe). Le codage à la main permet une certaine flexibilité dans la création
de schémas de réduction des données de restitution, notamment pour la préparation de
template. Langley, (1999) souligne notamment que la description des contextes est la
première étape de l’analyse processuelle. Il s’agit d’expliciter les différents « niveaux
d’encastrements » qui font émerger les ingrédients.
Étape 3 : Découpage et étiquetage des unités de sens en établissant une chronologie des
événements et des faits saillants
179
- PROJ pour les projets et les programmes ;
- UA pour unité d’affaires ;
- US pour unité support.
Le premier chiffre après cette première référence (DSI-1 par exemple) étiquette une
entité en particulier. Dans le cas Société Générale par exemple, il y a 4 DSI, afin d’éviter un
certain nombre d’acronymes de l’organisation, nous avons préféré numéroter les DSI de
1 à 4.
Les événements étant identifiés comme ingrédients (nous présentons cette étape dans
le paragraphe suivant) suivent un numérotage double. Par exemple la référence DSI-1-
IGRT-2.1 étiquette le second ingrédient de la première séquence d’événement. La
dernière tâche dans l’étiquetage des événements consistait à donner une description
synthétique de celui-ci. La figure 32 présente aussi 3 exemples provenant du cas Société
Générale.
Dans cette étape, les tâches consistent à repérer les ingrédients qui représentent : les
éléments d’un contexte identifiés par le chercheur comme pertinents pour analyser un
processus scientifique (Adeline Gilson dans Mendez 2010 p.58). Chaque ingrédient
identifié a été caractérisé en fonction de sa nature. Nous avons à cet effet établi une
catégorie d’ingrédient émergente comme suit :
- les freins : étiquette des faits ou événements explicitant des tensions entre acteurs
pouvant aboutir à une crise dans les relations internes au cas ;
- les décisions : est une catégorie d’ingrédients rassemblant le choix d’individus ayant
une influence majeure dans les événements ;
- les initiatives : sont les actions d'un individu ou d’un groupe d’individus qui
proposent, entreprennent, organisent des actions. Nous verrons que certaines initiatives
sont planifiées et que d’autres sont émergentes.
- les actants : il s’agit d’individus ayant eu une influence dans le cours des événements,
les actants peuvent avoir une influence positive ou négative (adjuvant, opposant). Les
180
actants sont aussi définis par leur faculté à agir, à avoir un poids, une intensité dans le
déroulement de l'action.
La cinquième étape de nos analyses a consisté à identifier les événements dans chaque
séquence jouant un rôle de pivot ou de basculement dans le cours des actions analysé
dans les cas. Dans nos analyses, les bifurcations s’illustrent au début ou en fin de séquence
d’ingrédients afin de marquer le passage d’une séquence à une autre.
Une fois les séquences d’ingrédients et bifurcations identifiées, nous avons dû qualifier
la nature des mouvements en œuvre pour chaque séquence. Plusieurs auteurs de la
littérature en gestion considèrent les trajectoires de changements organisationnels
comme des mouvements (Mintzberg & Ahlstrand, 1999; Quinn, 1980; Weick et al., 1999).
Nous nous sommes référés à cet effet sur les quatre catégories proposées par Van de Ven
& Poole (1995).
181
intervenus à l’issue d’un processus cyclique de sélection des formes les plus efficaces
d’organisation avec une certaine forme de prescription. Ce moteur associe trois
mécanismes complémentaires : des variations dans les ingrédients se produisent au sein
d’une trajectoire. Ces variations sont conservées ou rejetées via des mécanismes de
sélection. Les évolutions sélectionnées sont conservées et reproduites, via des
mécanismes de rétention.
Enfin, le moteur Cycle de vie : concerne aussi des entités uniques d’une organisation. Ce
type de changement est décrit par les auteurs comme participant d’un « cycle de vie » au
cours duquel l’organisation répond activement à son propre besoin naturel de
changement pour permettre la poursuite naturelle de sa croissance. Le changement est
ici « prévu » et se caractérise par des ingrédients planifiés.
Nous avons opté pour une présentation des séquences sous forme de matrices
chronologiques. L’exemple ci-dessous (figure 33) présente une série composée des
différents types d’étiquetage du matériau récolté en appliquant une chronologie des
ingrédients identifiés. La réduction des données dans l’ensemble des cas nous a permis
de générer 16 séquences d’ingrédients. Celles-ci seront analysées dans les chapitres 6, 7
et 8 afin d’extraire des régularités.
182
Figure 33 : Matrice chronologique des séquences d’ingrédients
Le second type de template choisi pour le découpage de notre matériau est inspiré des
travaux de Bidart et Brochier dans Mendez (2010, pp.174-190). La figure 33 représente
une bifurcation sous la forme d’une vallée au fond de laquelle est planté un grand mât,
dont l’ancrage est assuré par des câbles situés sur les deux plateaux bordant la vallée. Le
mât représente l’événement pivot (le turning point). L’un des plateaux illustre la séquence
précédent la bifurcation et l’autre la séquence qui suit.
Les câbles de la séquence 1 (en orange dans la figure 34) matérialisent les ingrédients
conduisant à la bifurcation. Le template présente l’ouverture d’une alternative qui
caractérise une phase de résolution et qui débouche sur des décisions et d’autres
ingrédients qui marquent l’entrée d’une nouvelle séquence (partie bleue de la figure 34).
Figure 34 : Template illustrant le passage d’une séquence à l’autre par une bifurcation
183
Phases
Étape Activité de réduction des données Support d’analyse
d’analyses
Préparation des données : Appui sur le logiciel Nvivo
• Transcription des entretiens
1 • Synthèse des réunions
• Compilation des documents
Première lecture du corpus de Lecture flottante Ayache & Dumez (2016) afin
données et pré découpage du de s’imprégner du corpus des données et
2
matériau à la main préparer le découpage.
Analyse de Découpage des unités de sens en Cadre d’analyse processuelle proposé par
deuxième 3 établissant une chronologie des Mendez (2010).
ordre (détails événements et des faits saillants
de l’étape 4 Caractérisation des événements ou Les ingrédients sont des faits ou événements
tableau 26 cf. faits saillants selon 5 catégories jouant un rôle majeur dans les processus.
2.2.2) 4 émergentes Nous avons défini cinq types d’ingrédients :
les contextes ; freins ; les décisions ; les
initiatives et les actants.
Analyse des bifurcations délimitant les Préconisations de Bidart et Brochier dans
5 différentes séquences d’événements Mendez (2010 pp.174-190).
Caractérisation des moteurs de Reprise des quatre moteurs proposés par Van
chaque séquence de ven & Poole (1995) à savoir :
6
Évolutionniste ; Cycle de vie ; Dialectique et
Téléologique.
Présentation Création de matrices chronologiques Modélisation des données par des matrices
et élaboration 7 chronologiques et templates (Ayche &
des résultats Dumez, 2016).
Tableau 30 : Synthèse du processus de réduction des données affiné pour la phase
explicative
184
2.2.6 Présentation des analyses
En se basant sur une revue de la littérature dans le champ de la gestion, Langley (1999)
propose aux chercheurs plusieurs pistes de méthodes de présentation des données.
L’auteur énumère ainsi 7 stratégies : la narration (« narrative strategy »), la quantification
(« quantification strategy »), l’utilisation de cadres théoriques alternatifs (« alternate
templates strategy »), la théorie enracinée (« grounded theory strategy »), la
représentation visuelle (« visual mapping strategy ») et enfin la délimitation temporelle
(«temporal bracketing strategy »).
Nous parcourrons dans les chapitres 6 et 7 chaque cas. Nous veillerons à débuter la
restitution par une présentation des contextes puis nous procurerons les différentes
séquences en proposant des détails quant à chaque ingrédient.
185
Pour accéder à un bon niveau de validité, la validité interne en recherche qualitative
s’établit principalement par la prise de certaines précautions que nous décrivons comme
suit (inspiré de Moyon, 2011) et synthétisées dans le tableau 31.
L’une des premières précautions réside dans le fait que les données recueillies nous
offrent la possibilité de comprendre le contexte historique des différentes DSI étudiées.
Pour accroître la validité interne de la recherche, nous avons systématiquement veillé à
multiplier les sources tout en croisant les données primaires et secondaires dans nos
analyses (Baumard & Ibert, 1999). Nous avons ainsi mobilisé notre matériau empirique
pour donner du sens aux événements identifié. Nous reviendrons sur la validation interne
des données après avoir présenté précisément les résultats et analyses ayant été menés.
La validité externe concerne quant à elle la généralisation des résultats. Elle cherche à
établir le domaine dans lequel les résultats obtenus peuvent être généralisés.
Dans l’optique de favoriser une validité externe de notre travail, nous avons opté dans
l’un des cas pour l’analyse d’un département R&D et non d’une DSI. L’objet d’une
validation externe étant de valider les possibilités de reproduction de l’étude par d’autres
chercheurs ayant attrait à une généralisation. Il s’agit de s’assurer que si l’on mesure le
même phénomène avec le même instrument de mesure dans un ou plusieurs cas
différents, on obtient des résultats similaires. Nous avons ainsi pris le soin de lancer
l’étude de cas Amadeus en tenant cherchant à renforcer la validité externe de nos travaux.
186
Démarche de la recherche Résultats de la recherche
Validité du construit Fiabilité Validité interne Validité externe
Vérifier que la S’assurer que dans Apprécier la Établir le degré de
démarche de des conditions pertinence et la généralisation des
recherche, les outils similaires de collecte cohérence des résultats
de recueil et d’analyse et d’analyse des analyses
Principe
187
Synthèse du chapitre 5
Un recueil de données - L’entretien a été la source principale de données. Il a été complété par
basé sur plusieurs l’analyse de documents et dans une moindre mesure, par l’observation non
sources d’évidence participante.
Une démarche - Par la mobilisation d’un cadre d’analyse mettant en exergue les contextes,
d’analyse fondée sur les ingrédients, bifurcations, séquences et moteurs des différentes trajectoires des
analyses processuelles cas ;
- ayant traité 3 unités d’analyses : les projets, les unités d’affaires et les
départements techniques des projets (DSI ou R&D).
Une restitution des - Les narrations des cas sont appuyées par la formalisation de templates et de
résultats narrative matrices chronologiques.
188
Chapitre 6 : Etude de cas pilote et analyse de
la figure naissante des coachs agiles
Chapitre 6 Chapitre 7
Etude de cas pilote et analyse de Narration des trajectoires de
la figure naissante des coachs trois organisations complexes
agiles
CHAPITRE 6 : ETUDE DE CAS PILOTE ET ANALYSE DE LA FIGURE NAISSANTE DES COACHS AGILES........... 189
INTRODUCTION ...................................................................................................................................... 190
1. ANALYSE PROCESSUELLE DE LA GENERALISATION DE SCRUM DANS LES DIFFERENTES DSI DE LA SOCIETE GENERALE ........ 191
1.1 D’une expérimentation concluante à la généralisation programmée de Scrum ............................ 196
1.2 La diffusion du modèle de la DSI 1 vers le groupe Société Générale .............................................. 227
1.3 Synthèse des différentes séquences ............................................................................................... 247
2. ANALYSE DE LA FIGURE D’ACTEURS NAISSANTE LIEE A LA GENERALISATION DES METHODES AGILES .............................. 252
2.2 Rôles des coachs agiles .................................................................................................................. 252
2.3 Facteurs accélérateurs de la généralisation constatés par les coachs ........................................... 260
2.3 Facteurs ralentisseurs de la généralisation constatés par les coachs ............................................ 262
189
Introduction
Dans le cadre de la phase exploratoire, nous avons initié une étude de cas pilote auprès
de la Société Générale afin de mieux comprendre les différents mécanismes et séquences
en œuvre au sein de ses Directions des systèmes d’information. Ce cas se révèle
particulièrement complexe à étudier en raison des nombreux acteurs présents dans les
différentes DSI. Au-delà de la vision séquentielle des faits analysés dans ce cas, nous avons
pu identifier de nouvelles figures d’acteurs ayant un rôle particulièrement important dans
le processus d’adoption. Il s’agit notamment des coachs agiles. Nous proposons de
présenter ce cas pilote de manière narrative en retraçant les séquences des principales
DSI.
En lien avec l’étude de cas pilote, nous avons orienté dans un second temps nos
investigations auprès des coachs intervenant dans le processus d’adoption des méthodes
agiles de plusieurs organisations. Ces agents du changement se révèlent être très sollicités
pour accompagner les équipes projet dans l’appropriation d’une méthode agile. La
deuxième partie de ce chapitre présente les analyses issues de 15 entretiens semi-
directifs avec les coachs.
190
1. Analyse processuelle de la généralisation de
Scrum dans les différentes DSI de la Société
Générale
Fondé en France par un groupe d’entrepreneur en 1864 « pour favoriser le
développement du commerce et de l’industrie en France », le siège de la Société Générale
(SG) est localisé au sein du quartier d’affaires parisien à La défense. Contrairement aux
banques mutualistes et coopératives structurées autour d’une caisse nationale auxquelles
sont affiliées les caisses locales, la SG fait partie des banques dites « commerciales »
prenant la forme d’une Société Anonyme appartenant à des actionnaires divers.
La Société Générale emploie plus de 148 000 salariés présents dans 67 pays au niveau
international et réalise un chiffre d’affaires de plus de 23 milliards d’euros. La banque
accompagne plus de 31 millions de clients dans le monde par des services reposant sur
trois pôles complémentaires. Tout d'abord, la banque de détail en France, connue au
travers des agences et de la banque en ligne, mais aussi la Banque hors de France.
Deuxièmement, les services financiers comme les métiers d'assurances et les
financements d'équipements et le troisième cœur de métier proposent des services pour
les grandes entreprises, pour les instituts financiers et pour le service public au travers
des activités de marché.
191
gèrent près de 25 000 serveurs, 70 millions de notifications en temps réel générant un
total de 40 petabytes de données. L’application smartphone réservé pour les clients
professionnels et particuliers est utilisée par 4 millions d’individus.
Les quatre DSI françaises du groupe ont depuis les 20 dernières années connu de
nombreuses vagues de réorganisation. Nous avons pu constater dans les communiqués
du syndicat national de la Société Généralex que l’adoption des méthodes agiles est un
motif de réorganisation :
Les données ayant été récoltées nous permettent principalement de nous focaliser sur
la DSI 1 et la DSI transverse 3. Nous présenterons néanmoins quelques aspects liés au DSI
2 et 4 puisque ces quatre entités partagent certains services.
192
La DSI 1 : est l’entité dédiée au métier de la banque de grande clientèle et solutions
investisseurs. Cette dernière a pour responsabilité, sur le plan mondial, de fournir aux
lignes métiers de la banque de financement et aux fonctions support, l'ensemble des
moyens informatiques et SI nécessaires à leur fonctionnement.
La DSI 2 : est un centre de services partagés destinés à doter les entités et filières
(Risques, Finances, Ressources humaines, Moyens généraux, Secrétariat général …) du
groupe de solutions informatiques globales (applications / logiciels utilisés par tout le
groupe). Le DSI 2 est aussi destiné à doter les entités et filières du groupe SG de solutions
informatiques globales et/ou mutualisées.
DSI 4 TOTAL
DSI 1 DSI 2 DSI 3
2016
Ratio effectif IT / Effectifs
15%
totaux SG
Effectif 1 633 2 677 1 341 5 651
Pourcentages d’internes -
par rapport à toutes les 28.9% 47,4 % 23,6%
DSI
Effectif des prestataires 7 322
2 091 2 968 2 263
Pourcentages d’internes
et d’externes par rapport 28,5% 40,5% 31%
à toutes les DSI
Totaux 3 724 5 645 3 604 12 973
Tableau 33 : Totaux des effectifs internes et externes dans les DSI de la SG
Les données ayant été récoltées portent aussi sur une entité au niveau du groupe. Nous
avons pu lancer plusieurs entretiens semi-directifs avec les acteurs organisant la
communauté des managers de projets (CMP). L’entité CMP anime une communauté de
193
plus de 4000 managers de projets au niveau global du groupe (incluant des acteurs projet
de la DSI et autres unités d’affaires), dont la majorité est en lien avec des projets IT.
Profondément marquée par la crise financière de 2008 et les pertes colossales liées à
l’affaire Kerviel, la SG a depuis 2010 entamé une bascule vers le digital en cherchant à
renforcer la relation client et à transformer son modèle opérationnel. À cet effet, la
transformation du modèle opérationnel du réseau d’agences internationales a été initiée
dans le but de standardiser, mutualiser et centraliser les processus et les ressources : « les
plateformes informatiques des principales implantations étrangères sont ainsi alignées sur
les systèmes et les réseaux France » (Extrait du rapport d’activité 2010).
Ce genre de réglementations ont plusieurs impacts dans l’organisation des DSI de la SG.
D’une part l’utilisation de multiples services en ligne et le fractionnement des systèmes
d’information accentuent la vulnérabilité des DSI aux cyberattaques. D’autre part,
l’évolution des réglementations tend à apporter de profondes modifications dans les
architectures techniques obligeant ainsi la DSI à acquérir de nouvelles connaissances
quant aux architectures plus ouvertes permises par le cloud computing.
y Les API permettent aux développeurs de pouvoir utiliser un programme sans avoir à se soucier du
fonctionnement complexe d'une application. Ce genre d’architecture permet de favoriser les relations entre
plusieurs applications de façon simplifiée.
z Directive sur les services de paiement 1, il s’agit d’une directive de l'Union européenne conçue pour
réglementer les services de paiement et les prestataires de services de paiement dans tous les États
membres de l'UE et de l'EEE. L'initiative a été signée en novembre 2009 et est entrée en vigueur le mois
suivant. Son objectif est triple : stimuler la concurrence sur le continent européen, améliorer la qualité des
services et protéger les consommateurs.
194
Afin d’apporter plus de précisions quant aux incertitudes liées à l’environnement de la
SG nous proposons de détailler certains aspects clés liés à son environnement externe.
Les néo-banques sont aujourd’hui très offensives sur le marché bancaire. Et plus
généralement, des Fintech menacent les banques sur des activités de niche comme les
activités de gestion d’actifs. Pour contrer ces perturbations majeures dans le marché
bancaire, les banques investissent en masse dans des services avec des offres digitales et
proposent de nouveaux types de contrats comme les assurances dommage et prévoyance.
L’intérêt de ce cas réside dans le fait que le terrain étudié est une entreprise dans le
domaine du secteur bancaire (domaine peu étudié dans la littérature) et prenant place
dans un marché fortement concurrentiel. Nous proposons dans les sections suivantes de
nous pencher dans un premier temps sur la DSI 1.
aaLa loi de séparation et de régulation des activités bancaires, définitivement adoptée le 18 juillet 2013,
a pour objectif de protéger les dépôts des épargnants tout en orientant la finance vers l’économie réelle.
L’analyse des causes de la crise financière et du rôle joué par les banques a conduit le Gouvernement à
vouloir légiférer pour séparer les activités purement spéculatives des banques de celles destinées au
financement de l’économie réelle. (https://www.economie.gouv.fr/reforme-bancaire)
195
1.1 D’une expérimentation concluante à la généralisation
programmée de Scrum
Avec un portefeuille de projets IT dont la densité est de plus d’un milliard d’euros par
an, l’introduction de la méthode Scrum à la SG débute au sein de la DSI 1 en 2010. Cette
première séquence se révèle courte dans la durée, mais les nombreux ingrédients
identifiés contextualisent l’enchaînement des séquences suivantes. Nous avons pu
reconstituer quatre phases précisant les différents mécanismes en œuvre ayant conduits
la DSI 1 à généraliser la méthode Scrum au sein de ses projets SI.
Avec pour priorité de recentrer son modèle économique chahuté dans le nouveau
contexte économique mondial, la Société Générale se réorganise et lance la mutualisation
et la localisation de ses ressources, le pilotage renforcé de ses processus en misant sur le
numérique. C’est ainsi que débute une période de grande remise en question du
fonctionnement au sein de la SG et l’une des premières entités à initier des réflexions à ce
sujet est la DSI 1 : « Les banques sont obligées de réinventer leur business model parce que
nous avons de nombreuses contraintes, puisque nous devons faire preuve de beaucoup de
transparence auprès des régulateurs, il y a donc une nécessité de digitaliser la banque »
(directeur de la DSI 1).
L’entité lance dans cette optique des réflexions stratégiques pour améliorer le
fonctionnement de la DSI 1 et les services qu’elle délivre aux unités d’affaires (DSI-1-
IGRT-1.1). Pour ce faire, le directeur de la DSI 1 n’hésite pas à se comparer aux autres
banques dans un premier temps :
196
« Ça fait une dizaine d'années qu'on fait des comparaisons. On se compare à
un benchmark de banques. […] Jusqu'au jour où, il y a 4 ans en arrière, on s'est dit,
mais il y a un truc qui ne va pas. En fait, on se compare aux gens qui sont comme nous,
mais qui sont aussi mauvais que nous […]. Donc, on a regardé les géants du web et
quand on regarde les gens du Web et la manière dont ils font du SI, ce n’est pas du
tout le même benchmark » (directeur de la DSI 1).
« Le client n'est jamais disponible. Il n’est jamais assez proche des équipes de
développement. Et il ne fait pas l’effort de comprendre nos suggestions. Il n’est jamais
disponible, change perpétuellement d'avis. Et ce qui fait qu'à la fin. Vu toutes les
difficultés, il y a énormément de mal à s'impliquer dans les différents problèmes
rencontrés » (selon un responsable de domaine de la DSI 1).
197
amènent de façon linéaire à la réussite en un certain temps qui s'il espère en tout cas
prédictible. En réalité, ce mode de fonctionnement est une promesse non tenue »
(selon un responsable de domaine de la DSI 1).
Le troisième ingrédient contextuel est schématisé par la figure 35. Ce support nous a
été présenté par un coach agile interne et montre ainsi la séparation établie entre les
différents acteurs de la DSI 1. Le terme Build désigne dans le langage des praticiens les
tâches de développement à proprement parler, i.e. la conception incluant les tâches de
codage des logiciels. Quant au Run il désigne les tâches de maintenance des applications.
Ces dernières nécessitent quasiment plus de codage ce qui a donc pour tendance de
séparer les individus en charge de la maintenance.
198
Figure 35 : Séparation des équipes dans la DSI
Le quatrième ingrédient contextuel de cette séquence porte sur la fin d’un programme
de transformation dont le but était de mettre en place du Lean management auprès de
toutes les équipes de la DSI 1 (DSI-1-IGRT-5.1). Or selon le directeur de la DSI 1, cette
approche ne s’applique pas à la conception, mais plutôt à la maintenance :
199
Parallèlement à ce chantier, l’introduction de la méthode Scrum dans la DSI 1 provient
d’équipes de développeurs (DSI-1-IGRT-7.1) :
Les bénéfices liés à l’adoption de Scrum sont rapidement identifiés tant par les
développeurs que les acteurs métiers. Les équipes ayant adoptés Scrum étaient en
capacité de livrer du code plus rapidement. D’autre part, comme des Product Owner ont
été mis en place au sein des unités d’affaires en lien avec la DSI 1, les utilisateurs avaient
la possibilité de ne pas systématiquement émettre des besoins fixes. L’organisation
adoptée dans les projets permet une plus grande adaptabilité des équipes IT aux regards
des besoins changeant des unités d’affaires. Dans ce sens, un responsable de la DSI 1
évoque :
« Si le métier change d’avis tout le temps, on peut tenir les délais, le budget et le
scope […] ça avec les méthodes agiles c'est possible, donc on prend plutôt
généralement les choses à contrepied auprès des métiers. On est très rapidement
transparent et on va leur dire voilà ce qui se passe si vous changez d'avis. […] Donc,
le changement est possible. Le changement pour le futur est préféré au changement
de ce qu'on a déjà construit dans les applications. Mais comme on pratique vraiment
une méthode de développement, on peut retravailler les éléments qui ne conviennent
pas. On fait que des démos fonctionnelles à 100%, changer d'avis, c'est à dire
compléter un besoin. Reste possible » (selon un responsable de domaine de la DSI
1).
À la suite des différentes expérimentations dans les équipes de la DSI 1, des retours
d’expériences sont présentés auprès du directeur adjoint de la DSI 1. Le passage d’un
usage contextuel de Scrum à sa généralisation au sein des projets IT débute ainsi par la
volonté de cet acteur de les mettre en œuvre à tous les projets (DSI-1-IGRT-8.1).
« Suite à ce que ces manageurs m'ont montré, on s'est dit ça c'est vraiment
très bien, il faut vraiment qu'on diffuse ça beaucoup plus à l'échelle de l’IT de
l’entreprise. Donc, on est parti sur ça. Et puis après, en tout cas à la Société Générale,
chez nous, on lance un programme, on structure un programme, on donne des
objectifs à 3 ans, on y va, on fait un peu du futur step, mais on y va. Donc, on est parti
200
comme ça et on a dit il faut que la plupart des équipes IT utilisent ces méthodes-là. Et
c’est là qu’on parle de, Scrum, Kanban, ScrumBan, etc. » (Selon le directeur adjoint
de la DSI 1).
L’introduction de Scrum par les équipes projet nourrit les réflexions entamées autour
de la réorganisation de la DSI 1. La remontée d’information entre les acteurs
opérationnels et le directeur adjoint de la DSI 1 permettent d’aboutir à la décision de
généraliser Scrum à l’ensemble des projets.
201
Référence Type
Séquence 1 Période Description de l'ingrédient Moteur
Ingrédient d'ingrédient
Remise en question 2010 CONTEXTE Des réflexions sont initiées au sein de la Dialectique
du fonctionnement DSI pour améliorer la livraison de ses Contexte
de la DSI 1 et projets
émergence de la US-IGRT- Françoise Mercadal-Delasalle directrice
méthode Scrum 1.1 de l'innovation et des ressources du
Actant
dans les projets groupe lance les réflexions autour de la
transformation numérique du groupe.
Les acteurs métier (trading) rencontrent
DSI-1-
des problèmes récurrents avec les Frein
IGRT-2.1
équipes de la DSI-1
Les modes de conception sont
principalement basés sur un cycle
DSI-1-
séquentiel avec une séparation des Frein
IGRT-3.1
différents acteurs intervenant dans les
projets (DSI - Dev Ops - Business, etc.)
Le fonctionnement séquentiel fige les
DSI-1- relations entre la DSI et les métiers de
Frein
IGRT-4.1 trading dont les besoins changent très
souvent
Un programme Lean IT est en cours de
DSI-1- finalisation au sein des équipes de la DSI,
Frein
IGRT-5.1 mais rencontre peu de succès auprès des
équipes projet
DSI-1- Lancement de la simplification du SI par
Décision
IGRT-6.1 le décommissionnant d'applications
DSI-1- Introduction de Scrum par des essais au Initiative Évolutionniste
IGRT-7.1 niveau des équipes
Le directeur adjoint de la DSI 1 entend
DSI-1-
parler de l'approche Scrum et propose Actant
IGRT-8.1
2011 de la déployer à l'ensemble des équipes
Tableau 34 : Synthèse de la première séquence du cas de la DSI 1 SG
202
1.1.2 Séquence 2 : Généralisation de Scrum au sein des équipes de
développement
Les réflexions stratégiques et surtout les nombreux freins identifiés dans la première
séquence aboutissent au lancement d‘un programme de transformation agile ayant pour
but de déployer la méthode Scrum à toutes les équipes de la DSI. Cet événement
caractérise une bifurcation dans la trajectoire de généralisation de la méthode Scrum
puisqu’il matérialise la décision du directeur de la DSI 1 de généraliser l’approche à toutes
les équipes.
« Quels sont les drivers qui nous ont amenés à emprunter le chemin de l'agilité en
général ? Alors, en fait, il y a trois grands drivers. Le premier, c'est que vous l'avez vu,
l'industrie financière est dans une révolution, les régulateurs nous imposent
évidemment beaucoup plus de transparence, beaucoup plus de capacité,
d'adaptabilité sur l'ensemble de transactions. Mais ils imposent également un certain
nombre de règles de contraintes sur les ressources, les banques sont obligées de
réinventer leur business model. […] Le deuxième grand driver, c'est celui qui vient de
digital. Tout le monde en parle. C'est vrai, il y en a partout. C'est le buzz word. Mais
la question qui se pose à la banque au moment où elle est obligée de réinventer son
business model est donc d'investir dans son IT. Quelque part, il y a une nouvelle donne
avec le digital. Et comment tirer parti de cette nouvelle donne du digital ? Ces deux
éléments sont deux éléments extrêmement importants. »
« En 2011, on s'est focalisé beaucoup 2011 2012 sur la partie production. Encore
une fois, c'est comment mettre la qualité sur mon système de production avant d'aller
à l'étape suivante. Notre vision statement en 2012 c’est un SI simple, agile, efficace
dans un monde de risques contrôlés. C'est toujours notre vision à long terme » (selon
le directeur de la DSI 1).
203
problèmes de fonctionnement entre équipes IT et métier, la phase précédente donne lieu
principalement à une remise en question du fonctionnement de la DSI 1.
Afin d’accompagner les équipes de la DSI 1 dans la mise en œuvre de ces approches, le
directeur de la DSI 1 engage des coachs pour accompagner les différentes équipes. Un
centre agile est créé pour accompagner les différents acteurs projet de façon individuelle
et par équipe (DSI-1-IGRT-1.2). Le centre agile est une entité interne composée
principalement de coachs externes. Les missions de cette entité portent sur les 4 points
suivants :
Le centre agile est ici positionné comme un fournisseur de services pour les équipes
plutôt opérationnelles : « Au départ, on avait un centre agile qui avait pour vocation à faire
percoler les valeurs de l'agilité, donc avoir une logique de flux d'itération. Mais au sein des
équipes projet uniquement avec les devs et les analystes métier » (selon un coach agile).
204
l’adoption de Scrum. L’idée est d’inciter les équipes à prendre part à la transition
d’approche (DSI-1-IGRT-2.2) :
« La première année, c'est un boulot de tous les jours que d'expliquer l'agilité,
pousser l'ensemble des équipes et du métier. Ce que je rappelle quand même que
l'agilité, vous le connaissez sûrement suppose un certain engagement non seulement
des équipes projets en IT, mais des équipes métiers. Mais en fait, dans la deuxième
année, vous poussez plus la deuxième phase à partir du moment où vous dépassez le
seuil des 25 30% des équipes » (selon le directeur de la DSI 1).
Nous classifions cet ingrédient comme une initiative. Bien qu’elle soit plutôt de l’ordre
d’un comportement proactif du directeur de la DSI 1, ce comportement à une réelle
incidence dans l’adoption de la méthode Scrum dans les équipes de la DSI 1. À cet effet, en
2012 les chiffres sont plutôt positifs quant au taux d’adoption dans les équipes. Scrum et
Kanban sont adoptées de façon plus soutenue au sein de la DSI est se révèle être imposée
pour les métiers (DSI-1-IGRT-3.2).
Le discours autour de la forte généralisation semble être le même du côté des acteurs
métier. En ce sens un responsable d’une équipe métier évoque :
« En 2012, on s'est rendu compte, toujours sur notre job, que finalement, les
cycles avec lesquels on gérait nos projets, nos portefeuilles projets n’étaient plus du
tout adaptés. […] Il fallait qu'on revoie complètement la gestion de notre portefeuille
projet, ce qui était compliqué parce que plusieurs grosses dizaines de millions d'euros
sur l'année. On n'a pas encore donné de chiffres, mais vous pouvez imaginer. Et du
coup, la question, c'était comment on fait pivoter le management sur l'allocation des
priorités et une fois qu'on a fait pivoté le management, comme on arrive à faire le lien
avec les équipes derrière puisqu’évidemment, les projets en salle des marchés, c'est 85
à 90 % de l'informatique. Donc, on travaille avec les équipes, avec les équipes de la
DSI 1. C'est comme ça qu'on est arrivé jusqu'en 2015 avec la moitié des équipes en face
d'activité de marché. Je pense qu’on devrait être pas loin de 80 à 85% des équipes qui
fonctionnaient en agile pour aller au bout. On s'est rendu compte que ça marchait très
bien localement sur quelques équipes en face de quelques applications. »
205
Les coachs agiles constatent aussi cette forte diffusion :
« L’agile fonctionne par viralité. Les équipes qui n’y sont pas veulent en être.
L’effet méthodes agiles sur la motivation des équipes est très intéressant, la
reconnaissance du travail accompli est immédiate » (selon un coach agile).
Malgré le fort degré de mise en œuvre de la méthode Scrum au sein des équipes de la
DSI 1, les bénéfices escomptés ne sont pas au rendez-vous (DSI-1-IGRT-4.2). Les murs
précédemment évoqués entre les différentes équipes de la DSI sont toujours présents.
Ceci illustre notamment que ce sont uniquement les équipes de développement et les
business analystes qui adoptent la méthode Scrum. En réalité, au lieu de livrer de manière
fluide les applications et les fonctionnalités aux utilisateurs finaux, nombreux sont les
temps morts qui ralentissent la conception des projets.
Dans cette optique, une nouvelle initiative est lancée par des équipes de
développement et des équipes infrastructures. Ils expérimentent une approche DevOps
caractérisée par : la mise en place d’outils d’automatisation des tests, un alignement dans
le fonctionnement entre les analystes métiers, les développeurs et les équipes
infrastructures, et une implication plus forte de l’utilisateur final (DSI-1-IGRT-5.2).
À cet effet, l’expérimentation est aussi présentée auprès du directeur de la DSI 1, mais
aussi au directeur général de la Société Générale (DSI-1-IGRT-6.2).
206
mettre en place une culture DevOps à base d'automatisation de mesures et de
partage » (retour d’expérience d’un coach agile interne).
Le slide présenté (figure 37) désigne bien les frictions qu’il peut y avoir entre les équipes
de développement
L’usage du jeu pour sensibiliser les équipes semble être un moyen privilégié par les
coachs agiles pour faire émerger les dysfonctionnements entre les équipes de la DSI 1.
Cette sensibilisation conduit les équipes à amplifier les efforts dans l’amélioration de
livraisons des projets SI. Or selon le directeur de la DSI 1, cela demande un vrai
207
changement de culture auprès des individus, en ce sens, le directeur de la DSI 1 évoquait
en 2015 :
« On est au tout début. Les résultats sont extrêmement prometteurs dans les
applications, la qualité vue à la fois du côté client et la valeur ajoutée issue du côté
client sont extrêmement bonnes, mais c'est une vraie rupture. Quand j'ai poussé les
équipes pour aller sur le continuous delivery, ils m'ont expliqué qu'on va passer de
l'agilité à du craftmanship. Si vous regardez le niveau de maturité entre l'agilité et le
continuous delivery, il y a un certain nombre de niveaux suivant » (selon le directeur
de la DSI 1).
La séquence que nous venons de présenter se traduit ainsi par un moteur téléologique
(tableau 35). D’une part, le lancement du programme de transformation agile affiche
l’ambition et la volonté de généraliser la méthode Scrum auprès de toutes les équipes de
la DSI 1. Les taux d’adoptions présentées dans les discours du directeur de la DSI 1 et du
directeur adjoint précisent d’autant plus le suivi des objectifs de généralisation. Cette
séquence d’ingrédients se différencie bien de la séquence 1 dans le sens où les initiatives
sont plus nombreuses dans cette séquence. Quasiment tous ces ingrédients ont été liés à
la volonté de généraliser Scrum. La trajectoire de généralisation est ici fortement
encadrée par les initiatives de sensibilisation des différents acteurs hiérarchiques et
l’accompagnement des coachs agiles.
« Tous les coachs en interne ils prennent le tome (le guide de mise en œuvre de
Scrum), ils disent « ok on va faire à notre sauce » et de toute façon comme le centre
agile est à la dérive tout le monde fait un peu comme il veut en fait. […]. En gros il y a
deux temps : un temps où j'étais avec un coach avec qui j'adhérais pas mal, qui faisait
208
un peu à sa sauce, et un deuxième temps où j'étais avec un coach qui était plus en
PMO qu'un coach d'ailleurs, qui lui prenait le tome, l’appliquait à la lettre, de façon
très linéaire » (selon un coach agile externe).
En réalité, les pratiques de coaching sont très divergentes et ne vont pas toutes dans le
même sens d’accompagnement. Le discours précédent montre bien la recherche d’une
certaine marge de manœuvre dans la co-construction des pratiques agiles avec les
équipes projet. Tandis que d’autres acteurs suivent plutôt les directives prises par les
responsables du programme de transformation.
Référence Type
Séquence 2 Période Description de l'ingrédient Moteur
Ingrédient d'ingrédient
Généralisation DSI-1- Lancement de la "transformation agile" Téléologique
de Scrum 2011 BIFURCATION- déploiement de Scrum et Kanban à toutes les
1 équipes de la DSI
Création d'un centre agile
composé de coachs pour
DSI-1-IGRT-
accompagner les différents acteurs Initiative
1.2
projet de façon individuelle ou par
équipe
Sensibilisation du directeur de la
DSI-1-IGRT-
DSI 1 auprès des différentes Initiative
2.2
équipes.
Scrum et Kanban tendent à se
DSI-1-IGRT- déployer de façon plus soutenue
Initiative
3.2 au sein des métiers par l’initiative
de responsables d’équipes
L’adoption de Scrum est assez
forte dans les projets néanmoins
les bénéfices escomptés ne sont
DSI-1-IGRT- pas au rendez-vous. Malgré
Frein
4.2 l'adoption de Scrum dans les
équipes de la DSI la conception est
encore lente - Mur entre les
équipes projet et les développeurs
Lancement de premières
DSI-1-IGRT-
expérimentations d’une approche Initiative
5.2
DevOps
DSI-1-IGRT- Présentation du problème auprès
Initiative
6.2 de Frédéric Oudéa (DG de la SG)
DSI-1-IGRT- Sensibilisation de la DSI autour de
Initiative
7.2 DevOps et du continuous delivery
Le directeur de la DSI est
DSI-1-IGRT- convaincu qu’il faut organiser les
2014 Actant
8.2 équipes vers de l’intégration
continue
Tableau 35 : Séquence portant sur la généralisation de Scrum
209
1.1.3 Séquence 3 : Mise en place d’une organisation fast IT
« Le problème c'est qu'en fait, ça n’apportait pas tant de valeur que ça, parce
qu’ont créé du code beaucoup plus rapidement. Le problème, c'est qu'on avait encore
des cycles. Je suis assez schématique dans ce que je dis, mais les tests sont restés en
cycles en V. Donc on avait beaucoup plus de code produit, mais le code produit ne
sortait pas en prod, donc il n'avait pas de valeur produite puisque n'était pas en
production pour l’utilisateur » (selon le directeur adjoint de la DSI 1).
D’autre part, nous avons pu voir que les coachs ont dû adapter leur accompagnement
et ont joué un rôle d’éclaireur quant à la mise en exergue de ce problème. Enfin le
directeur de la DSI 1 était déjà convaincu de ce nouveau niveau de maturité à atteindre.
Ces quatre ingrédients tendent à réduire l’amplitude de la rupture en fin de séquence 2
(figure 38).
Dans la séquence 3, l’objectif lié au programme continuous delivery of value est clair,
Afin de livrer les projets et les fonctionnalités de manière plus rapide, la DSI doit changer
de mode d’organisation de ses équipes au-delà des pratiques de gestion de projet. Les
directeurs de la DSI 1 tiennent un discours assez précis quant à la vision de cette
séquence:
210
« Donc c'est là qu'on a avancé à la deuxième transformation, au deuxième
étage de la fusée qu'on a appelé Continuous Delivery, qui est très à la fois DevOps et
tout ce qui est outillage technique. On emploie une image de chaîne de construction
automobile pour décrire une chaîne de construction logicielle plus automatisée »
(selon le directeur adjoint de la DSI 1).
« Si toute votre chaîne n'est pas en continuous delivery, vous allez buter vite
sur des difficultés. La première question, c'est la nécessité de transformer l'intégralité
de la chaîne et la nécessité si vous voulez vous rendre utile à votre business, vraiment.
[…]. Ça ne veut pas dire que toutes les applications doivent être en continuous. Ça
veut dire que là où vous avez besoin d'agilité, il va falloir que cette chaîne soit fluide
entre les équipes » (selon le directeur de la DSI 1).
Dans cette séquence, les objectifs sont dès le départ assez clairs, la SG investit 8 millions
d’euros et subdivise ce plan d’investissement en 3 grands chantiers. D’une part l’objectif
est d’atteindre 32 applications en interne dont le mode de fonctionnement est basé sur
Scrum et sur DevOps.
« Alors, c'est notre objectif pour 2014. Sur 2014, on divise en quatre grands
chantiers. Le programme continuous delivery chez moi. Donc l'investissement pour
donner un ordre de grandeur, c'est 8 millions d'euros sur la partie pure
transformation qu'on a investis pour avoir 32 applications donc on ne on rajoute pas
de fonctionnalités pour avoir des applications qui sont en mode continuous delivery.
Donc, on va voir à la fin de l'année deux applications qui sont dans le niveau 3 qui est
DevOps » (selon le directeur de la DSI 1).
À travers ce passage, nous comprenons qu’il n’est pas possible de généraliser le mode
de fonctionnement Scrum et DevOps à toutes les équipes de la DSI 1. DevOps fait figure
d’un niveau de maturité à atteindre par les équipes intervenant dans 32 applications. C’est
un moyen ici d’ajourer un objectif aux équipes ayant préalablement adopté Scrum.
« On a fait des lab. […] On veut que la chaîne soit continuous delivery et on ne veut
pas qu’une application. Souvent un métier n'est pas sur une application, mais sur un
groupe d'applications. Donc, en fait, ce sont de grands plateaux dans nos tours de la
défense. On va prendre un plateau, on va mettre toutes les applications d'une même
chaîne tous ensemble donc on a deux chaînes que nous allons mettre dans des labs
avec quelques utilisateurs » (selon le directeur de la DSI 1).
211
Le deuxième levier d’investissement porte sur la formation des différents acteurs de la
DSI 1. En effet l’adoption de Scrum et la suppression des frontières entre les équipes de
développement et les équipes infrastructure modifient profondément la répartition des
tâches. L’objectif est des piloter les infrastructures avec le paradigme et les outils des
développeurs. Des « go fasts » sont mis en place pour inciter les individus à s’autoformer
(DSI-1-IGRT-2.3).
Ce dispositif est incitatif puisqu’une fois les acteurs formés et les différentes équipes
alignés, il figure que ce n’est qu’à cette étape que les individus peuvent être accompagnés
par un coach agile.
Enfin, le troisième type d’accompagnement porte sur les techniques de codage. Ce qui
est appelé en l’occurrence le coaching « craftmanship » ou l’artisanat du code. L’idée est
d’accompagner les développeurs dans la création d’applications de bonne qualité
technique. La qualité du code est un prérequis pour fluidifier le processus de conception
d’une application (DSI-1-IGRT-3.3) :
212
ensuite, c'est de déployer, c'est d'accompagner sur le terrain toutes ces équipes »
(selon un coach agile externe).
Développer la qualité du code créé par les équipes de la DSI 1 nécessite une certaine
harmonisation des langages de programmation utilisés au sein de la DSI 1. À cet effet, le
programme continuous delivery de la DSI 1 porte sur la convergence des langages et
environnements de développement (DSI-1-IGRT-4.3) :
Le virage vers l’intégration continue n’est pas uniquement une affaire de compétences
ou d’organisation des équipes comme nous venons de voir. Les 8 millions d’euros investis
dans le programme sont aussi consacrés au développement des technologies facilitant le
déploiement continu d’application et l’automatisation de certaines tâches comme les tests
des applications. Le programme donne lieu à une expérimentation d’une part et à la mise
en œuvre du cloud computing (DSI-1-IGRT-5.3). Cette architecture technique permet de
mettre en place des environnements beaucoup plus rapidement dont les bénéfices sont
partagés par plusieurs parties prenantes :
« J'ai besoin d'avoir mon infrastructure comme code et donc de donner la possibilité
à mes équipes de développement de provisionner, dé provisionner les environnements.
Pouvoir aller très vite dans la partie développement » (selon le directeur de la DSI 1).
L’accompagnement dispensé par les coachs agiles dans cette séquence ne porte pas
uniquement sur les compétences des individus dans ces nouveaux environnements de
travail. Il porte d’autant plus sur un changement de culture (DSI-1-IGRT-6.3). L’objectif
213
est d’accompagner les individus à casser les comportements « client-fournisseur » entre
les différentes équipes de la DSI 1. Cet accompagnement dispensé par les coachs agiles est
une initiative proactive puisque ce changement a été anticipé par les membres du
programme de transformation.
Nous voyons enfin apparaître dans cette séquence des liens entre le programme
continuous delivery mené au sein de la DSI 1 et un programme porté par les ressources la
direction des ressources humaines. Ce dernier converge avec le programme de la DSI 1
puisqu’il vise à valoriser les individus au sein de la banque (DSI-1-IGRT-7.3).
Le dernier ingrédient de cette séquence porte plutôt sur un nouvel actant. Le directeur
de la DSI 1 quitte ses fonctions pour devenir directeur de la DSI 3 de la SG, l’entité dédiée
aux infrastructures et aux technologies de l’information du groupe. C’est donc en octobre
2016 qu’un nouveau directeur est nommé au sein de la DSI 1 (DSI-1-IGRT-8.3). Ce nouvel
actant va essentiellement préserver la trajectoire de généralisation de la méthode Scrum
poursuivie au cours du programme continuous delivery de cette séquence 2. Néanmoins il
a la volonté d’aller au-delà des 32 applications ciblées au cours du programme continuous
delivery. Son ambition est de généraliser le mode de fonctionnement triptyque (Scrum –
DevOps et Craftmanship) à l’ensemble de la DSI 1. Cet actant marque là une nouvelle
rupture puisque les objectifs et la mise à l’échelle de ce fonctionnement nécessitent de
nouveaux dispositifs.
214
La trajectoire de généralisation de la méthode Scrum a pris une toute autre ampleur
dans cette séquence (tableau 36). De nombreuses évolutions peuvent être constatées à
cet effet : nouvelles techniques et langages de programmation ; environnement
technologique orienté cloud computing ; rassemblement des différentes équipes autour
d’un seul et même endroit ; évolution des responsabilités des individus. Toutes ces
évolutions ne sont donc pas uniquement liées à la mise en œuvre de la méthode Scrum,
mais à la mise en œuvre d’un triptyque composé de la méthode Scrum, d’une approche
DevOps et des techniques de software craftmanship. C’est donc cet ensemble d’approches
qui permettent aux 32 applications de la DSI 1 d’être dans un cycle d’intégration continue.
Référence Type
Séquence 3 Période Description de l'ingrédient Moteur
Ingrédient d'ingrédient
Mise en place DSI-1- Lancement d'un programme continuous Téléologique
d’une organisation 2014
BIFURCATION-2 delivery of value
Fast IT (intégration DSI-1-IGRT-1.3 Création de labs et Initiative
continue)
réaménagement des locaux
DSI-1-IGRT-2.3 Création de Go-fast pour Initiative
inciter les individus à prendre
des initiatives et devenir
autonomes
DSI-1-IGRT-3.3 Accompagnement des Initiative
équipes par le biais des
techniques du software
craftmanship
DSI-1-IGRT-4.3 Harmonisation des langages Initiative
de programmation
DSI-1-IGRT-5.3 Expérimentation et mise en Initiative
œuvre des technologies cloud
2015
computing
215
1.1.4 Séquence 4 : Mise à l’échelle du programme continuous delivery
Dans cette séquence la bifurcation ne provient pas de freins rencontrés par les équipes
plutôt par l’arrivée du nouveau DSI. Lors de son arrivée, le précédent programme
continuous delivery portait essentiellement sur les équipes IT. C’est en 2017 que la mise à
l’échelle du fonctionnement initié dans la séquence précédente est lancée (DSI-1-
BIFURCATION-3).
216
Figure 39 : Objectifs du programme de transformation agile at scale
Les trois objectifs affichés (figure 39) portent sur l’accroissement de la valeur produite
par les équipes de la DSI auprès des acteurs métier. La convergence des pratiques et des
technologies au niveau international, et l’extension du fonctionnement en place dans les
projets par les différents acteurs en support (Gestion budgétaire par exemple).
Dans cette optique, une organisation des équipes au niveau international est à prévoir.
Dans la recherche de ce nouveau mode d’organisation, la DSI 1 a été accompagnée par un
cabinet externe. En termes de méthodologie, le directeur de la DSI 1 n’a pas souhaité
appliquer à la lettre une méthode d’agilité à l’échelle en particulier. Les équipes ont pioché
des idées dans diverses entreprises et méthodes existantes pour ne retenir une
organisation inspirée de l’entreprise Spotify. Pour les grands projets, le choix s’est porté
sur la cadre Scaled Agile Framework (SAFe).
217
différents pôles métiers du trading (les managers de projets) ainsi que des prestataires
de services souvent externes. Plus le degré d’amplitude est fort (en ce qui concerne le
nombre d’acteurs à coordonner pour chaque entité en lien avec le projet), plus les projets
devront être structurés pour délivrer au mieux les résultats attendus. La création de
chaînes de valeur métier consiste à créer des équipes pluridisciplinaires en rassemblant
tous ces acteurs en une même équipe. La différence par rapport à la séquence précédente
porte sur le nombre d’acteurs de différents départements à intégrer dans la même équipe.
L’approche DevOps mise en place dans la précédente séquence ne porte que sur le
rapprochement des développeurs et des responsables infrastructures de la DSI 1.
Le modèle d’organisation développé par le cabinet de conseil externe (figure 40) est
censé inclure tous les acteurs impliqués dans une chaîne de valeur (DSI-1-IGRT-1.4). La
chaîne de valeur n’est pas reprise au sens de Porter (1985), mais désigne plutôt
l’ensemble des activités et des acteurs impliqués dans les étapes de construction de
solutions qui fournissent un flux continu de valeur à un utilisateur. Le modèle proposé est
néanmoins censé être adapté aux différents contextes de la Société Générale.
« Pour être clair, je n'ai jamais fait exactement la même chose parce que les
problématiques sont diverses et variées. C'est plus une guideline et ça s’adapte à
chaque contexte » (selon un coach agile externe).
Le modèle créé porte essentiellement sur la création de features teams. Celles-ci sont
composées comme nous pouvons le constater dans la figure 40, de tous les acteurs
impliqués dans la conception des applications (Développeur, responsable de
218
déploiement, etc.) en comprenant un Product Owner et un Agile master. Ce dernier a
principalement pour rôle de faciliter la tenue des différents rituels au cours de la
conception des applications (il s’agit simplement du Scrum Master). D’autre part, une
feature team est censée appliquer les rituels de la méthode Scrum de façon autonome.
« C’est comme une startup. C'est une petite équipe de 5 à 9 personnes colocalisée
et cross fonctionnelle, c'est-à-dire en capacité de délivrer des fonctionnalités de
manière autonome, en ayant la capacité de développer une fonctionnalité de A à Z de
la supporter et de la maintenir. » (Selon un coach agile externe).
Le choix de mettre en place des features teams est aussi motivé par le changement de
mode de conception. Contrairement aux équipes classiques en gestion de projet, une
feature team reste impliquée dans la maintenance et l’évolution de l’application au gré
des rituels Scrum pour une durée indéterminée.
Deuxièmement, comme les features teams sont composées d’acteurs ayant différents
rôles, des communautés transverses entre features teams ont été mises en place pour
rassembler les acteurs partageant les mêmes expertises. Les chapitres (chapter dans la
figure 40) : « sont des communautés qui sont en charge de développer les compétences,
partager les connaissances, améliorer et homogénéiser les pratiques et innover. Et donc,
effectivement, on a mis en place un management au niveau des chapters pour faciliter la
coordination » (selon un coach agile).
Le fonctionnement entre les features team est composé de deux scénarios possibles.
D’une part, le modèle présente des mécanismes de light synchro entre deux features
teams. Directement inspiré du cadre Large Scale Scrum, il s’agit de quatre rituels de
fonctionnement : la mise à jour du backlog produit par les différentes équipes, la
planification des sprints, deux-ateliers de conception multiéquipes et un échange
quotidien (Daily Scrum) entre les membres des équipes. Les rituels de light syncro sont
principalement mis en place pour le développement de petites applications.
« En fait, on a mis en place des mécanismes syncro qui sont dimensionnés par
rapport au contexte. On met en place des mécanismes légers que l'on a appelé light
syncro qui sont dérivés de Large-Scale Scrum » (selon un coach agile).
Dans les cas d’applications plus critiques, le modèle prévoit une organisation en trains.
Plus communément appelé Agile Release Train (ART), ce mode de synchronisation est
219
directement inspiré du cadre Scaled Agile Framework. Les trains rassemblent plusieurs
équipes feature teams pluridisciplinaires et disposent toutes des capacités logicielles,
matériel pour définir, mettre en œuvre, tester, déployer, et exploiter les applications
majeures pour la SG. Un ART est aussi rythmé par le biais d’un cycle de conception basé
sur des itérations courtes (2 semaines). La synchronisation des features teams s’effectue
autour d’un rituel nommé le Program Increment planning (PI Planning) se tenant toutes
les 10 semaines, dont l’objectif est de réunir toutes les features teams (parfois plus d’une
centaine) pour planifier les 10 semaines suivantes de développement.
Le modèle organisationnel créé pour la DSI prévoit des communautés entre les features
team. Pour cela, les créateurs du modèle ont repris le principe des guildes proposées dans
le modèle Spotify. Il s’agit dans le cas de la DSI 1 d’individus provenant de n’importe quelle
feature team désirant partager et développer une expertise autour d’un sujet technique
ou fonctionnel. Les guildes sont autoorganisées et sont basées sur le volontariat. Le
second type de communauté créée dans le modèle concerne les ligues. Une ligue
rassemble des experts d’un sujet, architecture, développement, etc., et sont obligatoire
pour les membres de features team. Ces deux types d’interactions sont essentiellement
destinés dans le modèle à développer de bonnes pratiques entre pairs.
Toutes les features teams, qu’elles soient organisées en Train (ART) ou pas sont
rassemblées dans une nouvelle méta-entité organisationnelle nommée la Tribu. « Une
tribu, c'est un groupe de personnes, dont la taille est inférieure à 125 personnes. Pourquoi
125 ? C'est le nombre de Dunbar qui décrit le nombre de personnes avec lesquelles une
personne peut maintenir une relation sociale avec un groupe d’individus. Pourquoi cette
contrainte ? C'est simplement pour optimiser la coordination et la communication au sein
de la tribu » (selon un coach agile externe).
Tous les acteurs impliqués dans une tribu ne sont pas nécessairement en France, ce
modèle s’étend donc au niveau d’équipes internationales. Dernier acteur clé du modèle
créé dans cette séquence, il s’agit du tribe manager. Il s’agit du responsable hiérarchique
des individus composant une tribu.
220
Pour mettre en œuvre le modèle organisationnel, les rôles et les différentes pratiques
de travail proposé dans le modèle précédent, il figure qu’une des premières initiatives de
cette séquence porte sur la création d’un processus de mise en œuvre des features team
transversales (DSI-1-IGRT-2.4). Plusieurs étapes ont été créées pour identifier les
différents acteurs à intégrer dans les features teams. À cet effet, une équipe composée
d’un responsable de la DSI 1 et un responsable métier identifient conjointement les
applications où les besoins métier sont les plus critiques (guilding team dans la figure 41)
et tentent de composer une équipe pluridisciplinaire entre IT et métier par le biais de
rencontres et d’ateliers (DSI-1-IGRT-3.4).
« Un point qui est intéressant, c'est qu'au niveau de la transformation des tribus à
la Société Générale, on met en place ce qu'on appelle des guiding teams. Donc, on
s'appuie sur des opérationnels pour effectuer la transformation. Ça a deux intérêts.
Le premier intérêt, c'est qu'il y a moins besoin de coachs. Deuxième intérêt, c'est que
les transformations soient pérennes et se maintiennent dans le temps. Donc après,
c'est la Guilding Team qui va continuer à améliorer la tribu. » (Selon un coach agile
externe).
Nous pouvons constater ici l’émergence d’une nouvelle figure de coach (coach
agile@scale dans la figure 41), dont le rôle est d’accompagner la guilding team dans
l’application et l’adaptation du modèle organisationnel créé (DSI-1-IGRT-4.4). Le coach
agile@scale facilite à cet effet la construction des features teams au cours des différentes
réunions avec les acteurs de la DSI et des métiers. Son rôle se révèle être central pour
faciliter les relations entre des acteurs qui ne se connaissent et devant en même temps
changer de manière de travailler :
« Et donc, nous, ce qu'on fait, c'est qu'on coach les guildings team. Donc le coach
at Scale qui est en charge de la transformation d'une tribu coach la guilding team est
garant du respect des grands principes, de l'agilité et de l'agilité à l'échelle et propose
une démarche dans le contexte de la définition de la structure organisationnelle et
facilite les différents workshops » (selon un coach agile externe).
221
Figure 41 : Processus d’identification des features teams dans la DSI 1
Pour piloter au mieux la mise en œuvre du nouveau modèle, toute une série
d’indicateurs a été mise en place pour mesurer la satisfaction des différents membres
d’équipes (DSI-1-IGRT-5.4) (figure 42). Par exemple, quand une feature team est créée,
un des axes importants de collaboration entre les différents membres de l’équipe porte
sur leurs engagements mutuels. À cet effet, pour casser comme nous l’évoquions
précédemment la relation « client-fournisseur » entre ces acteurs, un indicateur de
« disponibilité » entre les acteurs de la DSI 1 et les acteurs des unités d’affaires d’une
feature team a été créé (visibilité du PO et satisfaction du business dans la figure 8).
222
Pour aider les individus à passer le cap de la transition, les différentes parties
prenantes impactées par le programme de transformation ont été accompagnées pour
mieux travailler au sein (ou en collaboration) des feature team en place (DSI-1-IGRT-6.4).
Les acteurs ayant fait l’objet d’une attention particulière sont les responsables
hiérarchiques de la DSI 1 :
223
justement justifier de la mise en œuvre de ces moyens. Un deuxième point aussi, on
parlait de valeurs pour le métier. C'était vraiment le point clé de posture de la DSI. Et
dès lors qu'on se pose sur le sujet, de vouloir apporter de la valeur au métier ou à
l'entreprise au sens large. Alors dans ce cas, il faut ici aller en parler au-delà des
frontières de la DSI » (selon le directeur de la DSI 1).
En 2019, près de la moitié de la DSI 1, soit plus de 3 000 personnes, a basculé dans le
nouveau mode organisation. La DSI 1 compte 60 tribus, chaque feature team est composée
en moyenne de 10 personnes par feature Team représentant un total de 600 feature
teams opérationnelles dans le monde. Du côté des métiers en lien avec la DSI 1, près de
300 Product Owners sont alliés à cette organisation.
Cette séquence traduit une vraie mise à l’échelle du mode de fonctionnement initiée au
cours des précédentes séquences. Le programme de transformation agile@scale se
caractérise par un grand nombre d’initiatives ayant pour but d’ancrer le mode
d’organisation basé sur des équipes travaillant en mode Scrum, mais qui ont été ici
nommées des feature Team à l’échelle de toute la DSI. Un modèle organisationnel a été
créé par des coachs externes à cet effet en début de séquence. La trajectoire ici se
caractérise par un cycle de vie puisque l’objectif est de déployer le modèle organisationnel
préalablement créé. Les ingrédients identifiés dans cette séquence (tableau 37)
traduisent essentiellement le dérouler d’un plan préparé et laisse. Les ingrédients sont
principalement proactifs aux différents contextes de travail.
Nous retenons une nouvelle fois que la figure du coach reste encore importante dans
cette séquence puisqu’ils accompagnent les individus à « porter » la transformation. Bien
que les initiatives soient portées par une équipe d’acteurs dédiée au programme
agile@scale, la stratégie de déploiement du nouveau mode d’organisation mobilise
fortement les acteurs opérationnels.
224
« On voit de la pollinisation s'effectuer dans différents endroits de la Société
Générale. Je pense qu'on a commencé assez tôt par rapport au groupe et aujourd'hui,
on voit dans CHU, chez ALD. On voit toutes ces bonnes pratiques se polliniser. On n'y
est pas encore à 100%. Pour faire un parallèle avec notre parcours, c’est venu du CIO
et du COO, on a maintenant embarqué le CEO. Bon bah, c'est un peu la même histoire
pour tout le reste du groupe. Il faut arriver à cranter, le dernier cercle. Là, je pense
que quand on leur a cranté, on aura gagné » (selon un responsable métier).
225
Référence Description de Type
Séquence 4 Période Moteur
Ingrédient l'ingrédient d'ingrédient
Le déploiement DSI-1- Lancement d'un programme agile@scale Cycle de vie
du continuous 2017 BIFURCATION-3
delivery
DSI-1-IGRT-1.4 Création d’une Initiative
approche basée sur
Spotify et SAFe pour
les grands
programmes
DSI-1-IGRT-2.4 Création d’un Initiative
processus
d’identification et de
création de features
teams sur le plan
international
DSI-1-IGRT-3.4 Création de Guilding Initiative
teams
DSI-1-IGRT-4.4 Mise en place du Initiative
coach agile@scale
DSI-1-IGRT-5.4 Création Initiative
d'indicateurs de
confiance entre
équipes IT et métier
DSI-1-IGRT-6.4 Accompagnement Initiative
des manageurs de
département de la
DSI
DSI-1-IGRT-7.4 Mise en place d'un Initiative
programme de
montée en
compétences pour
les métiers
DSI-1-IGRT-8.4 Engagement et relai Actant
du directeur de la
2020 DSI 1
Tableau 37 : Synthèse des ingrédients de la séquence 4
226
1.2 La diffusion du modèle de la DSI 1 vers le groupe
Société Générale
Les différentes séquences identifiées précédemment ont notamment inspiré plusieurs
entités au sein de la Société Générale. Les premières entités ayant repris le mode de
fonctionnement créé par la DSI 1 sont les autres DSI (2, 3 transverse et 4). La DSI 1 a joué
un rôle moteur dans l’injection des méthodes :
Ce sont principalement par le biais d’échanges entre praticiens que Scrum et les autres
approches mises en place au sein de la DSI 1 se sont diffusées dans d’autres entités du
groupe. Il n’est pas aussi à exclure les changements de responsables mutés de la DSI 1
vers les autres DSI. À cet effet, le directeur de la DSI 1 qui opérait jusqu’en 2016 a été muté
au sein de la DSI 3 Transverse. Nous avons ainsi pu constater dans nos données que
l’arrivée de cet acteur a pu jouer un rôle majeur dans la réorganisation de la DSI 3
transverse.
Les données ayant été récoltées autour du cas de la DSI 3 se révèlent être bien plus
faibles par rapport aux données récoltées pour la DSI 1. Nous proposons de retracer les
deux séquences identifiées autour du cas de la DSI 3 de façon plus succincte.
La DSI 3 Transverse est une entité composée de nombreux acteurs. Près de 4000
individus présents dans 40 pays accompagnent les employés de la Société Générale dans
la mise en place de technologies de l’information. Il peut aussi bien s’agir de la mise à
disposition des téléphones, ordinateurs, mais aussi des infrastructures pour héberger les
différentes applications de la banque. Cette DSI accompagne tant bien les métiers, mais
intervient en supports des autres DSI pour les infrastructures informatiques.
La DSI 3 est issue d’un plan d’efficacité opérationnelle qui consistait à industrialiser les
processus et à optimiser les ressources du groupe en créant des centres de services
partagés. L’objectif était notamment de réaliser des économies par la mutualisation des
ressources. Cette entité a donc vu le jour en 2009 résultant d’une fusion de certains
centres de services. Cette entité se révèle être le plus important des centres de services
227
partagés dans le groupe puisque les infrastructures représentent entre 40 % et 50 % des
coûts informatiques de la Société Générale.
Dès la création de l’entité en 2009 et jusqu’en 2014, les équipes de la DSI 3 travaillent
essentiellement en appliquant le référentiel ITIL (Information Technology Infrastructure
Library) pour assurer la maintenance de grands volumes d’infrastructures en place. Au
niveau de la mise en place de nouvelles infrastructures pour les différents projets de la
banque, les équipes travaillent en mode séquentiel pour les nouveaux équipements à
mettre en place. L’alliance des pratiques issues du référentiel ITIL et d’un mode projet
séquentiel de mise en place de nouvelles infrastructures tend ici implicitement à siloter
les équipes de la DSI 3.
Une grande remise en question de l’organisation est lancée à la suite d’une étude menée
en interne révélant la mauvaise perception des services de la DSI 3 (DSI-3-IGRT-1.1). En
ce sens un coach agile de la DSI 3 évoque : « La considération client dans le référentiel ITIL
passe au second plan ». Les équipes de la DSI 3 doivent faire face à de nombreuses
sollicitations très diversifiées. Par exemple, lorsqu’une équipe projet demande une base
de données, celle-ci peut être de multiples formes ce qui tend à ralentir la réactivité en
raison de nombre conséquent des possibilités techniques.
Le modèle DevOps créé dans la DSI 1 se déverse dans la DSI 3 et la vision est beaucoup
plus orientée sur la servicisation des infrastructures. L’objectif est de fluidifier la mise en
place des plateformes techniques en cassant les silos entre les équipes de la DSI 3. L’idée
est d’autre part de développer des « ponts » qui permettent de connecter les applications
plus facilement entre elles. Les interfaces de programmation plus connues sous
l’acronyme API sont des technologies qui permettent justement de plus facilement créer
des synergies entre applications.
228
C’est donc en 2014 qu’un premier chantier de réorganisation de la DSI 3 débute dont
l’objectif est de mettre en place plus de fluidité dans le fonctionnement des équipes. Cette
séquence débute par l’expérimentation de technologies cloud pour faciliter
l’hébergement de nouvelles applications (DSI-3-IGRT-2.1).
Afin d’accompagner le changement technique, tout comme la DSI 1, la DSI 3 lance une
réorganisation de ses équipes en y injectant l’approche Scrum pour les équipes qui
développent de nouvelles plateformes pour les projets (DSI-3-IGRT-3.1). Néanmoins
l’initiative est émergente et provient des équipes opérationnelles et ne se révèle pas
encore être le fruit d’un déploiement organisé par un programme de transformation.
Compte tenu du mur entre les Dev et les Ops on a réfléchi. On a beaucoup réfléchi
avec nos architectes. […], on a imaginé notre roadmap infrastructure intégrant le
cloud. On a voulu viser très haut en mobilisant du monde et on s'est dit et bien pour
le faire, on va aller voir dans nos équipes les Ops qu'on connait et qui ont envie de
travailler autrement […]. On en a identifié quatre ou cinq personnes qui avaient envie
de le faire et qui voulaient lancer ce projet avec nous. Et puis, on a revu avec nos
architectes, tous ensemble, notre offre, notre super roadmap pour créer une première
expérimentation. (Selon un opérateur d’infrastructures de la DSI 3).
229
En 2014, donc, on avait notre ambition. On avait nos équipes, on avait nos outils,
on a commencé notre expérimentation, donc on a travaillé dessus pendant plusieurs
semaines et au bout de plusieurs semaines et bien ça a fonctionné. On a réussi à créer
une machine virtuelle et créer notre base de données et la manipuler. Et c'est là qu'on
s'est dit POC validé, c'est vachement bien, mais en fait, finalement, c'est le début des
problèmes parce que nos bêta-testeurs qui étaient super impliqués sont devenus de
vrais utilisateurs. […] Et puis nos développeurs, je vous l'ai dit, nous, on a un contexte
très international ils se parlent beaucoup entre eux. […] nos équipes à l'international
nous ont posé beaucoup de questions. C'est quoi le support ? Comment on fait quand
vous n’êtes pas là ? […] comme ça a fonctionné, on a eu de plus en plus de demandes
et nous, on n'était pas organisés. On ne savait pas forcément comment prioriser. On
découvrait vraiment le monde du développement et on s'est dit il va peut-être nous
falloir un product owner. Et du coup, on a recruté un PO » (selon un opérateur
d’infrastructures de la DSI 3).
Comme les équipes clientes de la DSI 3 sont principalement des développeurs des
autres DSI de la Société Générale, les équipes fournissant les services d’infrastructures
cloud de la DSI 3 ont dû s’aligner sur le mode de fonctionnement des autres DSI. Dans la
figure 43, le point de découplage correspond à une jonction qui se matérialise par le rôle
du Product Owner des platforms teams qui récoltent et priorisent les besoins des
développeurs (feature teams dans le schéma).
230
C’est notamment en 2016 que les événements vont s’accélérer par le biais d’un nouvel
actant. Le directeur de la DSI 1 prend la tête de la DSI 3 en octobre 2016. Sur la base de
son expérience dans la précédente entité, il impulse le lancement d’un programme de
transformation pour une réorganisation de la DSI 3 (DSI-3-IGRT-4.1). Débute ainsi une
nouvelle séquence en 2017 puisque la bifurcation est ici déclenchée par un actant ayant
la volonté de reproduire ce qui a été fait dans la DSI 1. La première séquence était plutôt
dans une dynamique dialectique, le changement et la remise en question provenaient
essentiellement des acteurs opérationnels. Dans cette seconde séquence liée à la DSI 3, le
moteur devient téléologique compte tenu des nombreuses initiatives lancées (séquence 2
du tableau 38).
On retrouve par exemple la création d’un centre de coaching agile pour accompagner
les équipes dans la mise en place de Scrum et faire diffuser une nouvelle culture de travail
auprès des différentes équipes (DSI-3-IGRT-1.2). Pour accompagner les changements de
fonctions dans les équipes Scrum, un passeport compétences et des modules de
formations en ligne sont proposés à tous les membres de la DSI 3 (DSI-3-IGRT-2.2 et DSI-
3-IGRT-3.2). Des communautés de pratiques sont mises en place par le centre agile afin
de favoriser les partages d’expériences au sein de la DSI 3. Cette communauté se réunit
autour d’événements qui portent sur les nouvelles pratiques de travail. Les sujets sont
larges et ne portent pas exclusivement autour des pratiques de Scrum (DSI-3-IGRT-4.2).
« Ça fait quelques années qu'on faisait du dev et qu’on n’était plutôt pas assez bon
sur le sujet. Là, on a rencontré des équipes qui étaient montées sur les six derniers
mois et en échangeant, elles ont chacune échangé trois minutes sur un sujet qu’elles
maîtrisaient. Eh bien, même nous, dans notre équipe, on a appris plein de choses. […]
ça nous a changé des méthodes de travail dans une équipe qui était quand même
soudée depuis deux ans et qui, finalement, a pris d'autres choses » (selon un
opérateur d’une équipe infrastructure).
Ces flux d’échanges qui se traduisent par des partages d’expériences et des feedbacks
entre acteurs opérationnels ne se limitent pas qu’à la DSI 3. Des individus d’autres DSI
sont invités et même le PDG de la Société Générale est associé à ces événements. En 2017,
le PDG s’est d’ailleurs illustré en s’initiant au monde du développement de logiciels en
intégrant une équipe de la DSI 3 pour travailler sur une API.
231
Pour encadrer la réorganisation des nombreuses équipes de la DSI 3 dans un nouveau
mode de fonctionnement. La méthode Scrum est privilégiée pour toutes les équipes.
Lorsque plusieurs équipes ont besoin de se synchroniser, les choix sont ici ouverts et
soumis au choix des équipes. Aucun cadre de référence n’est privilégié. Par exemple, une
équipe à Hong-kong a notamment mis en œuvre en 2016 les pratiques issues du guide
Large Scale Scrum pour structurer un grand programme informatique (DSI-3-IGRT-5.2).
Pour sensibiliser les acteurs des couches managériales plus élevées, un MOOC de
sensibilisation à l’agilité en général est lancé en 2018 (DSI-3-IGRT-6.2). Il s’agit d’un cours
asynchrone en ligne animé par les coachs du centre agile de la DSI 3.
Figure 44 : Mise en place des trains SAFe dans les équipes européennes de la DSI 3
232
Référence Type Moteur
Séquence 1 et 2 Période Description de l'ingrédient
Ingrédient d'ingrédient
1.Adaptation de 2014 DSI-3- Le chantier de réorganisation par la Dialectique
l'approche BIFURCATION- pratique DevOps débute et tranche avec le
DevOps 1 fonctionnement initial
DSI-3-IGRT- Insatisfaction des métiers Frein
1.1 forte envers la DSI 3
DSI-3-IGRT- Premiers essais d'un dispositif Initiative
2.1 cloud public dans une
application et mise en place
2015
d’un Product Owner pour
faciliter les relations entre les
différentes équipes IT
DSI-3-IGRT- LA DSI met en place une Initiative
3.1 réorganisation de ses équipes
2016
pour fluidifier la conception
des applications internes
DSI-3-IGRT- Un nouveau directeur est Actant
4.1 nommé au sein de la DSI 3
2. Réorganisation DSI-3- Lancement de la transformation Téléologique
de la DSI 3 par la 2017 BIFURCATION- agile@scale
généralisation de 2
Scrum et SAFe DSI-3-IGRT- Mise en place d'un centre Initiative
1.2 agile - coaching des équipes
DSI-3-IGRT- Création d'un passeport Initiative
2.2 compétences
Création de modules de Initiative
formation
DSI-3-IGRT- Organisation d'événements Initiative
4.2 internes et création de
communautés de pratiques
DSI-3-IGRT- Adoption de Large Scale Initiative
5.2 Scrum dans une équipe à émergente
Hong-kong
DSI-3-IGRT- Sensibilisation des acteurs deInitiative
2018
6.2 la DSI par le biais d'un MOOC
DSI-3-IGRT- Lancement d'un premier train Initiative
7.2 SAFe
DSI-3-IGRT- Lancement d'un second train Initiative
8.2 SAFe "My Digital Workplace"
DSI-3-IGRT- Renforcement du coaching Initiative
2019
9.2 auprès des équipes émergente
DSI-3-IGRT- Lancement de 2 Trains SAFe Initiative
10.2 émergente
Tableau 38 : Reproduction du modèle de la DSI 1 vers la DSI 3
233
1.2.2 La diffusion des features team au sein des DSI 2 et 4
Comme nous l’introduisions au début de cette partie, la Société Générale est composée
de quatre DSI en France. Les données récoltées nous ont permis d’identifier des
mécanismes de généralisation de Scrum par la mise en place de feature team au sein des
DSI 2 et 4.
234
Nous retrouvons aussi des similitudes quant à la manière d’opérer la généralisation.
Une des initiatives clés ayant été identifiée dans le programme de transformation de la
DSI 2 porte sur la mise en place d’un centre agile de coaching.
« Le centre agile du BSC est composé de 15 coachs répartis sur les 3 sites majeurs
du BSC. Cette transformation agile se réalise sur 2 grands axes : l'agile au sein des feature
teams et l'agile@scale pour l'ensemble de l'organisation du BSC, tribu par tribu » (extrait
d’un communiqué de la DSI 2).
L’extrait suivant révèle d’autre part la manière dont la DSI 2 suit de près la
généralisation. La cible pour 2020 porte sur la mise en place de 30 tribus au sein de la DSI
2 afin d’intégrer toute l’entité dans ce nouveau mode d’organisation.
235
planifiés entre 2018 et 2020. Cette séquence se traduit notamment par un moteur
téléologique.
La DSI 4 s’est aussi lancée dans la généralisation de Scrum ainsi que d’autres méthodes
comme en témoigne l’extrait du communiqué du syndicat national de la banque
(surlignage jaune dans la figure 46). Néanmoins les données récoltées nous laissent peu
distinguer si la généralisation est programmée ou ponctuée.
Les acteurs à accompagner ne sont pas uniquement les individus de la DSI 4. Les
individus au sein des unités d’affaires en lien avec la DSI 4 sont aussi censés être
accompagnés par les coachs agiles. Néanmoins l’accompagnement ici est moins
prescriptif par rapport à ce que nous avons pu identifier dans la DSI 1. Les individus des
unités d’affaires sont plutôt sensibilisés à la philosophie du manifeste agile.
Enfin, les données récoltées au sein du cas de la DSI 4 nous permettent d’illustrer un
phénomène particulièrement intéressant en ce qui concerne les mécanismes de
généralisation de Scrum dans toutes les DSI de la Société Générale. La « Mise en place et
l’animation des communautés de pratiques en relation avec les autres centres de
compétences agiles de Société Générale », présenté comme un rôle du coach agile au sein
237
de la DSI 4, révèle un mécanisme de partage de connaissances établi entre les différentes
DSI de la Société Générale. Comme la DSI 1 a été précurseur dans les méthodes et modes
d’organisations autour de Scrum des features teams et du modèle SAFe généralisé à
l’ensemble de ses équipes, les DSI 2, 3 et 4 se sont inspirées et alignées à son mode
d’organisation tant sur les approches mises en œuvre que sur les mécanismes pour opérer
la généralisation. Le point 4 de la figure 46 illustre bien la maturité de la DSI 1, mais aussi
le rôle moteur dans la diffusion de ses pratiques aux autres DSI en raison des bénéfices
constatés par les équipes.
« ITEC [DSI 1]: qui a une plus grande maturité dans l’implantation d’agile et a
démarré sur Agile@Scale il y a plus de 3 ans chez ITEC/CTY et FCC. La généralisation
à tout ITEC a commencé en 2017. Les remontées des salariés d’ITEC sont
particulièrement intéressantes pour toutes les autres directions » (extrait d’un
communiqué du syndicat national de la banque).
Compte tenu des nombreuses initiatives identifiées au sein des différentes DSI de la
Société Générale, nous avons pu observer d’autres mécanismes exogènes aux différentes
DSI pour accompagner la montée en compétences d’individus des différentes unités
d’affaires de la SG. En effet, les projets ne portent pas uniquement sur les systèmes
d’information et les chefs de projets peuvent aussi être rattachées au sein des différentes
unités d’affaires du groupe. Dans le but de soutenir la professionnalisation des chefs de
projet de l’ensemble du groupe, une communauté a été lancée en 2014.
D’une part, leur rôle est d’assurer l’animation de la communauté en ligne pour favoriser
les partages d’expériences, les partages de documents livrables et l’actualité des projets.
Le réseau social est ensuite divisé en sous-groupes, où chaque membre peut suivre et
238
contribuer aux différents échanges. En ce sens, un des acteurs de la CMP définit son rôle
comme :
« Regrouper les parties prenantes des projets […] approfondir, questionner, mettre
en exergue certaines difficultés, certaines facilités pour pousser une effervescence de
groupe. On est amené à dynamiser cette communauté et à les faire réfléchir, les
amener au même endroit, d'une part en les regroupant. » (Selon un organisateur de
la CMP).
Le second rôle des acteurs de la CMP porte sur l’organisation d’ateliers, conférences et
retours d’expériences en physique pour favoriser les échanges entre pairs au sein de la
communauté. Malgré la forte dimension internationale des individus rassemblés sur le
réseau social, les événements se tiennent principalement dans les différents campus
parisiens du groupe.
239
Dans une logique de montée en compétences des porteurs de projets et de programmes
de la SG, le dernier rôle des acteurs de la CMP porte sur la mise en place de formations. En
collaboration avec les ressources humaines du groupe, les acteurs de la CMP créent des
parcours de formations en gestion de projet. Ces formations sont ensuite dispensées dans
la plupart des cas par des acteurs externes de la SG comme en témoigne la figure 49 qui
liste les types de formations recherchées par la CMP. L’accent est principalement mis sur
le management de projet, de programmes et de portefeuille de projet et le module portant
sur les différentes approches agiles était déjà demandé en 2014.
Figure 49 : Liste des formations demandées dans le cadre d’un appel d’offres de la
CMP
Au niveau de la cible, ces formations sont à destination de tous les membres du groupe
potentiellement « acteurs de la transformation » :
Compte tenu du fort taux de mise en œuvre de la méthode Scrum dans les différentes
DSI de la SG, la professionnalisation de la communauté de management de projet est aussi
fortement influencée par les actions de généralisation qui se déroulent au sein des
différentes DSI. La CMP a dû initier plusieurs ateliers pour harmoniser les pratiques de
travail afin de formuler une base commune dans le cadre méthodologique. Dans un atelier
réunissant les responsables de centres agiles des différentes DSI, la responsable de la CMP
évoquait :
« L'idée de cet atelier est de semer les graines pour que l’agilité avance de manière
commune. ITECH [la DSI 1] ne sera pas agile tout seul. ITIM [La DSI 4] ne sera pas
agile tout seul. Les métiers ne seront pas agiles tout seuls. Ce qu'on constate
aujourd'hui, c'est que l'agilité, c'est la responsabilité de chacun et qu'on est obligé
d'être cross entité et travailler tous ensemble. […] Il faut qu'on parle ensemble et il
faut qu'on ait une même façon de penser » (selon la responsable de la CMP en mai
2017).
Comme les différentes DSI se sont toutes lancées dans des actions de généralisation, il
figure que les acteurs métiers sont très peu accompagnés dans les changements de rôles
et de fonctionnement engendré par la mise en œuvre de Scrum (via des features teams)
dans un cycle d’intégration continue (continuous delivery). Les différentes
réorganisations au sein des DSI sont d’ailleurs comprises par les acteurs métiers comme
un chantier ciblant uniquement les membres des différentes DSI :
« J'avais fait des sondages auprès des métiers, on ne peut pas se transformer si on
fait de l’IT pour l’IT ou du métier qu’avec le métier. Ça ne marche pas. Et donc arriver
à faire vraiment du collaboratif qui donne du sens sur des chaînes de valeur complète,
c'est ça qu'on vise. […] Ce qui m'a été dit dans les sondages, c'est que le mot continuous
delivery auprès des métiers, auprès des sponsors. C’est hyper connoté techos et ça
donne l'image que c’est une tuyauterie super huilée, mais c’est perçu comme l’affaire
de l’IT » (selon un coach agile de la DSI 1).
241
Figure 50 : Ateliers de mise à jour du cadre méthodologique de management de projet
intégrant l’agilité à l’échelle
Le cadre méthodologique a connu une seconde mise à jour majeure en 2018 pour
intégrer les éléments clés issus des initiatives de mise à l’échelle de la méthode Scrum par
la méthode SAFe (modèle provenant principalement de la DSI 1). Cette mise à jour portait
sur la définition et la clarification des nouveaux rôles, des nouvelles responsabilités, des
nouveaux rituels et mode de fonctionnement. La mise à jour du cadre méthodologique
s’est faite en plusieurs temps par le biais d’ateliers réunissant les membres de plusieurs
entités (figure 50).
242
Figure 51 : Liste des rôles nécessitant une reconnaissance des RH
Entre 2014 et 2018, les formations ont dû aussi être mises à jour. Un premier parcours
de formation a été construit autour de la méthode Scrum préalablement adoptée dans la
DSI 1 : « nous avons vraiment capitalisé sur le travail de la DSI 1 de sorte à l’étendre à tous
les managers de projets du groupe » (selon la responsable de la CMP). Celles-ci portaient
principalement autour des rôles du Scrum Master et du Product Owner.
D’autre part, comme les acteurs métier jouent principalement le rôle d’émetteur des
besoins dans les projets, et comme ce sont ces individus qui utilisent les applications
développées par la DSI, la CMP a donc misé en priorité sur la formation des acteurs
métiers :
« Dans la méthode Scrum le rôle de Product Owner (PO) est celui qui émet les
besoins, nous avons donc mis en place une formation PO générale destinée à
l’ensemble de la couche métier » (selon la responsable de la CMP).
En 2016, les formations à destination des managers de projets du groupe ont été
complétées et deviennent de vrais parcours de spécialisation. C’est dans cette optique que
la CMP a mis en place un programme de formation adapté à ces acteurs plus opérationnels
dans les métiers de l’entreprise.
« Nous avons choisi, pour les formations certifiantes (Scrum Master et Product Owner),
de valider les acquis des stagiaires en leur faisant passer les assesments proposés par la
Scrum.org (PSM Niv1 et PSPO Niv1), car à notre sens, ils sont les plus rigoureux sur le marché
actuellement [évaluation individuelle - QCM de 80 questions – 1 heure – seuil pour réussir
> 85 % de bonnes réponses – à passer en ligne] » (selon un formateur).
bb La certification PMI ACP permet de valider les connaissances de nombreuses méthodes agiles et des
différentes pratiques y étant associées.
244
Le parcours sur la méthode Scrum est conservé et afin de doter les différents acteurs en
lien avec les projets au sein de la Société Générale, une formation portant sur le design
thinking est mise en place.
« L’agilité est très poussée par les SI, et ils prennent le lead. Pour que nos équipes
deviennent innovantes, il faut aussi que l’on utilise des approches nouvelles et si on
veut aller vite, les équipes innovantes sont souvent basées sur un mode de
fonctionnement agile, mais pour clarifier la manière dont les métiers affinent leurs
visions et l’émission des besoins, nous avons introduit la formation Design thinking »
(selon la responsable de la CMP).
Entre 2017 et 2020, ce sont plus de 4300 personnes qui ont suivi les différentes
formations du cursus. Ce chiffre permet d’une certaine manière d’apprécier le niveau de
contextualisation interne de la méthode Scrum.
Figure 53 : Catalogue des formations portant sur les méthodes agiles en 2018
Entre 2014 et 2018, il est intéressant de constater la manière dont les rôles de la CMP
évoluent pour favoriser la généralisation de la méthode Scrum. Les ateliers avec les
différents centres agiles, la reconnaissance et la définition des nouveaux rôles avec les
ressources humaines contribuent à contextualiser Scrum auprès des différentes unités
245
d’affaires du groupe. Le tableau 40 ci-dessous compile l’ensemble des mécanismes initiés
par la CMP pour favoriser la généralisation.
Plusieurs acteurs ont notamment évoqué l’influence de la DSI 1 dans les choix réalisés
par la CMP. Cette influence se matérialise de plusieurs formes. D’une part, nous évoquions
précédemment le fait que la CMP organise des ateliers de capitalisation dans les projets
réunissant des volontaires. Il figure que pour certains managers de programmes de la DSI
1, la contribution est obligatoire :
« J'ai l'impression que c'est dans leur ADN d'aller au-delà de ce qu’ils mettent en
place. J'ai l'impression que c'est un peu dans leur ADN de se poser la question du
pourquoi. […] Alors que pour les autres DSI c’est moins le cas » (selon un animateur
de la CMP)
« Les équipes de la DSI ont tiré l’ensemble du groupe dans le fonctionnement avec
le continuous delivery, la DSI 1 ça a toujours été le modèle dans la Société Générale
c’est la locomotive, les autres DSI ont tendance à copier la DSI 1 » (selon la
responsable de la CMP).
D’autre part, lors d’un atelier organisé avec les différents centres agiles des DSI pour
organiser la formation Devenir agile ensemble, (formation d’introduction aux approches
agiles et au mode de fonctionnement agile à l’échelle) nous avons pu observer la manière
dont la personne représentant la DSI 1 a fortement influencé les choix collectifs pour son
contenu. En établissant une proposition de syllabus devant être validé et complété par les
membres des autres DSI, cette action révèle bien la maturité liée au sujet. La personne à
246
d’ailleurs su faire preuve d’une grande capacité de persuasion auprès des toutes les
personnes présentes.
D’une part, c’est l’insatisfaction des services proposés par la DSI 1 auprès des entités
métier qui pose un problème. Parallèlement, la méthode Scrum est mise en œuvre de
façon émergente dans les équipes de la DSI 1 et se diffuse notamment par des mécanismes
d’échanges et de partages informels comme des retours d’expériences de retour
d’expériences entre développeurs.
Dans un troisième temps, les bénéfices escomptés dans la mise en œuvre de Scrum
auprès des équipes de développement ne sont pas au rendez-vous. Des problèmes
structurels et des soucis de communication entre les différentes équipes chargées du
développement des applications entravent la bonne mise en œuvre de Scrum. Pour
combler ces freins, le directeur de la DSI 1 lance une réorganisation des équipes afin de
favoriser la collaboration et l’intégration continue des applications.
La méthode Scrum est dans cette troisième phase mise en œuvre pour aligner toutes
les équipes sur les cadences de développement, notamment sur des itérations de même
durée. Puis, une approche DevOps est mise en place pour accélérer le déploiement des
applications (Continuous delivery). Cette approche est notamment composée d’une part
d’un rapprochement physique des différentes équipes travaillant sur les mêmes
applications, la mise en œuvre de technologies pour automatiser des tâches de faible
valeur ajoutée comme les tests, puis les développeurs sont accompagnés par des coachs
247
pour veiller à ce que les codes créés par les développeurs soient de qualité (Software
craftmanship).
248
est de faire collaborer tous les acteurs d’une chaîne de valeur métiers (des développeurs
aux utilisateurs) de façon plus optimale afin d’éviter les écueils liés à la séparation des
parties prenantes. Tous les acteurs d’une chaîne de valeurs sont ainsi intégrés dans des
feature teams qui fonctionnent avec la méthodologie Scrum. La DSI 1 cherche ainsi à
maximiser la valeur des applications produites aux besoins utilisateurs en tenant compte
de façon réactive, des évolutions des besoins. Un méta modèle organisationnel de ces
feature team est mis en place pour organiser les potentielles dépendances. Il est
notamment composé du cadre Scaled Agile Framework et de certains principes
d’organisation de Spotify.
Dans le cas de la DSI 3, les séquences sont différentes puisqu’elles sont essentiellement
nourries des apprentissages de la DSI 1. Néanmoins, les éléments déclencheurs de la
généralisation et des différentes séquences sont quasiment les mêmes. D’une part, il y a
une forte insatisfaction des services proposés par la DSI 3, ce qui contribue à faire évoluer
le mode d’organisation des équipes. La DSI 3 applique ici directement les principes
d’organisation de la DSI 1. Au cours de la deuxième séquence identifiée pour la DSI 3, c’est
l’arrivée d’un nouveau directeur qui va déclencher des initiatives de généralisation
planifiées. Le mécanisme privilégié ici repose essentiellement sur du coaching des
équipes.
249
adoptées préalablement. La séquence 2 questionne donc le lien entre la mise en œuvre
d’innovation managériale en lien avec la mise en œuvre d'innovations technologiques.
250
SAFe et d’éléments du modèle
Spotify.
Le dernier point de synthèse du cas porte sur une vue plus macro de la généralisation.
Nous avons en effet évoqué la manière dont la DSI 1 avait commencé à initier très tôt la
généralisation de la méthode Scrum. Nous proposons donc en figure 54 une
schématisation des mécanismes de généralisation qui s’effectuent au-delà de la DSI 1.
251
2. Analyse de la figure d’acteurs naissante liée à
la généralisation des méthodes agiles
La phase exploratoire des travaux s’est poursuivie par des entretiens menés avec des
coachs agiles. Nous avons pu voir dans la précédente étude de cas l’émergence de cette
nouvelle figure d’acteurs pour accompagner les différentes équipes de la DSI et des unités
d’affaires dans la mise en œuvre des nouvelles méthodes adoptées. Dans la poursuite des
travaux exploratoire, nous avons donc cherché à préciser le rôle des coachs, et leur point
de vue au sujet des mécanismes accélérant et/ou freinant la généralisation d’une méthode
agile.
252
« En fait, l'agilité va beaucoup rimer avec une culture d'amélioration continue, et
ma préoccupation quand je suis avec une équipe ou une organisation c'est de
répondre à la question comment installer une culture d'amélioration continue. L'idée
c'est qu'il ne faut pas faire de l'agilité pour faire de l'agilité, mais c'est plus comment
installer la culture d'amélioration continue ? Pour l'installer, mon travail de coach
est de créer du temps pour qu'ils essayent des choses autour de l'agilité pour qu'ils se
disent qu'ils l'ont essayé et qu'ils voient l'intérêt que ça a afin qu'ils se demandent la
valeur que ça leur rapporte, que ce soit pour une équipe ou pour une organisation. »
(Coach 1).
« En fait, le but est de faire prendre conscience que les gens font partie d'un système
et à mon sens, il faut une adhésion au départ. Et il y a un adage qu'il faut insuffler aussi
c'est le fail mais fail fast, et en France il y a un gros trou au sujet de l'acceptation de
l'échec » (coach 14).
« C'est d'abord une transformation humaine, j'ai un client, j'aime beaucoup ce que
l'on fait chez eux depuis un certain temps, il y a des prestataires, des équipiers internes,
et externes sur le site à Avignon. Et les équipiers externes ont accès aux coachs comme
les équipiers internes. Il n'y a pas de différence. Et là, c’est plus facile pour œuvrer au
rapprochement des équipes » (coach 7).
« Il faut que tout le monde soit solidaire et se dise si on peut vous aider. C'est limite
une nouvelle culture de fonctionnement. C'est une culture parce qu’en France l’échec
n’est pas toléré et ça pèse souvent dans la collaboration en équipe » (coach 8).
253
En tant que prêcheur de nouvelles valeurs, les coachs agiles s’appuient essentiellement
sur les valeurs et les principes du manifeste agile. Lorsqu’ils interviennent dans les
différentes équipes, les coachs commencent souvent par la communication de cette
philosophie gestionnaire.
Troisièmement, les coachs agiles œuvrent sur les perspectives d’appropriation des
méthodes agiles en tentant de lever les barrières cognitives des individus.
« L'agilité est un processus cognitif à la base qui doit être construite dans une
intelligence collective et pas isolément dans une petite équipe et ça implique des
évolutions culturelles au sens des valeurs, il y a des freins considérables liés à la volonté
de contrôler notre rôle est d’essayer de casser les anciens modes de management en
remettant au centre l’humain » (coach 7).
Cette première catégorie de rôle est assez riche. Tous les coachs interrogés nous ont
exprimé l’importance des nouvelles valeurs à mettre en œuvre pour installer un nouveau
cadre méthodologique. Une fois ce premier travail réalisé, dans un second temps les
coachs accompagnent les individus dans la mise en œuvre d’une méthode.
254
2.2.2. Facilitateur des dynamiques de groupe
Les coachs œuvrent dans la facilitation des interactions entre différents acteurs
impliqués dans les projets. Comme les méthodes agiles sont principalement mises en
place du côté des équipes de développement de la DSI, il figure que les coachs
interviennent de différentes manières auprès de ces acteurs (Volet technique,
méthodologique, collaboration, etc.). Nous avons pu d’autre part constituer une
taxonomie des différents acteurs accompagnés par les coachs agiles (tableau 43). Nous
proposons de détailler point par point les différents accompagnements.
Comme les premiers acteurs à travailler avec des méthodes agiles sont les acteurs
opérationnels de la DSI et principalement les développeurs, les coachs agiles
interviennent souvent auprès de ces acteurs. D’une part en tant qu’experts
méthodologiques, ils accompagnent les équipes de développement dans la mise en œuvre
d’une méthode.
« Alors c'est variable, au départ c'était vraiment au niveau des équipes IT, mais ça
va de plus en plus vers les métiers. Ma dernière mission par exemple sur la partie R&D
chez Atos c'était 150 personnes. Je suis maintenant chez un éditeur, c'est beaucoup
plus petit, mais c'est toute l'organisation qui se met en mode Scrum » (coach 4).
255
Compte tenu des nombreux acteurs en lien avec les projets SI, les coachs agiles
interviennent dans la fluidification des interactions entre les différents individus
impliqués dans les projets :
« Souvent, les entreprises ont une maîtrise d’œuvre (MOE) et une maîtrise
d’ouvrage (MOA), des business analystes, etc… on veut simplifier cette organisation
en ayant un informaticien qui soit artisan, qui connaisse bien son métier et qui soit
capable de se comprendre directement avec les métiers » (coach 9).
La facilitation des dynamiques d’équipes projet passe ainsi par le fait de casser les
dépendances entre les différents acteurs :
« Pour bien mettre en œuvre l'agilité, il faut essayer de casser des dépendances et
mettre en place des écosystèmes avec des buts propres » (coach 4).
« Je trouve que justement aujourd'hui ça c'est une contrainte, l'agilité ne doit pas
parler de business et d'IT, ça doit être transversal, mais c'est avant tout une équipe.
Et effectivement casser les silos est un enjeu de la transformation. Des entreprises
mettent beaucoup d'énergie pour casser ces silos et la transformation doit dépenser
beaucoup d'énergie à casser ces silos en fait » (coach 8)
« Selon certains managers, l'agilité ça ne marche pas et le gars en est sûr. Donc
certains vont tout faire pour empêcher que l'agilité touche leur secteur, ces managers
sont sceptiques, et ils ont surtout peur de perdre leur pouvoir. En agile, les managers
sont beaucoup moins prépondérants que dans un monde avec des chefs partout. Il
faut donc les accompagner vers de nouveaux repères » (coach 1).
« Dans un autre cadre le point le plus dur à traiter aujourd'hui ce sont les
managers, ceux qui étaient les plus proches des équipes logicielles comme les
managers d'équipes logiciels sont plutôt accueillante du changement, mais comme
ont élargi les personnes composant les équipes n'ayant pas vécu le début de l'agile au
256
sein de l'organisation, car on s’en est occupé 4 ans plus tard c'est vraiment compliqué.
Ces gens-là vont se braquer, il faut donc accompagner et comprendre leurs
problématiques, ils ont des responsabilités importantes, l'ingénierie système on est
dans l'intégration de plein d'équipes et ce sont de grands budgets, des projets
critiques avec le client. Donc la dimension manager est un point qu'il ne faut vraiment
pas négliger. Précisément le middle management d'ailleurs c'est même toute
l'activité middle management » (coach 10).
Les méthodes agiles nécessitant une implication forte des futurs utilisateurs, il figure
que les équipes au sein des unités d’affaires ne consacrent pas assez de temps aux projets.
Dans cette optique, les coachs agiles œuvrent auprès des responsables des unités métier
dans la compréhension des changements induits par la mise en œuvre d’une méthode
agile.
« L'agilité n'est pas une fin en soi. Il n'y a pas de modèle cible, et finalement mon
rôle est par exemple dans certain cas, c’est de faciliter la compréhension de ce
qu’implique la mise en œuvre d’une méthode, je vais donc piocher sur ce qu'il se fait
dans l'agilité, il y a peut-être des pistes ailleurs et je vais apprendre au manager à
parler aux équipes, je vais faire de la formation à la facilitation parce que ça va les
aider, il va peut-être falloir que je forme les mecs de base pour les conduire à mener
une réunion. Je vais aider et mettre des moyens dessus » (coach 3).
Au niveau des acteurs opérationnels du côté des unités d’affaires, les coachs agiles
interviennent principalement dans la compréhension et la facilitation des nouveaux rôles
à tenir.
« Donc tous les MOE MOA et ce genre de chose on veut s'en détacher à court terme
c'est les métiers qui ont la connaissance, mais la chose qui nous intéresse c'est à la fin
que l'on ait des informaticiens qui soient capables de parler le langage des métiers. On
ne veut pas de MOE MOA et de business analyste, etc… on veut simplifier cette
organisation en ayant un informaticien qui soit artisan, qui connaisse bien son métier
et qui soit capable de se comprendre directement avec les métiers » (coach 13).
257
Compte tenu de postures de facilitation, les coachs agiles sont considérés comme des
acteurs clés du changement induit par l’adoption généralisée d’une méthode agile. Sur ce
point nous avons pu identifier un troisième rôle qui est notamment mis en œuvre
lorsqu’une organisation généralise une méthode par le biais d’un programme de
transformation.
Un certain déracinement est souvent caractérisé par le fait que les organisations font
face à des situations compliquées. L’émergence de la transformation telle qu’elle est
conçue par les coachs, provient dans de nombreux cas principalement d’une rupture.
Cette rupture peut par exemple être dans certains cas une crise, comme l’évoquent
plusieurs coachs : « Les organisations ne changent que si elles ont besoin de changer, et
souvent le besoin de changer vient d'une crise. S’il n'y a pas de crise, il n’y a pas de
changement, s’il n’y a pas d'ambition forte, il n’y a pas de changement. Donc s’il n’y a pas de
besoin, il n’y a pas de changement » (coach 10). En l’occurrence, la rupture permet de
mettre les différentes parties prenantes en condition du changement.
En tant que catalyseur du changement, les coachs agiles interviennent auprès des
équipes projet dans la co-construction d’une méthode adaptée par essais et amélioration
continue. En effet comme la méthode Scrum se caractérise d’un substrat technique ouvert,
258
celle-ci est dans bien des cas complétés par des pratiques de planification, d’estimation
des tâches.
« Le coach intervient pour proposer des options et ensuite les mettre en place.
Typiquement l'idée c'est de proposer les différentes méthodes Scrum a tel avantage,
kanban tel avantage et puis on le met en place. Il y a des choses qu'ils ne peuvent pas
inventer aussi, le planning poker, l’animation d’une rétrospective, etc. ils ont besoin
d'accompagnement là-dessus » (coach 14)
« J'aime bien faire le coaching expérientiel, c'est le fait que je vais te donner des
outils, tu vas sincèrement les essayer, tu gardes ce que tu veux garder. L'idée est dans
l'expérimentation d'outils et de pratiques de sorte à trouver au mieux une bonne
solution. Il faut ensuite enlever certaines mauvaises pratiques, les faire oublier. Il y a
beaucoup d'outils que l'on diffuse par le biais du jeu, mais qui sont en fait des outils
intellectuels. Le lego for Scrum est génial pour ça » (coach 1).
Les entretiens menés avec les coachs agiles nous ont d’autre part permis d’identifier
des facteurs qui contribuent à la généralisation d’une méthode agile et à contrario, les
facteurs qui freinent le processus. Nous proposons dans la prochaine section de présenter
les différents groupes identifiés.
259
2.3 Facteurs accélérateurs de la généralisation constatés par
les coachs
Nous proposons dans cette partie de lister les agents, dispositifs ou éléments
intrinsèques à une organisation ayant été identifiés lors des entretiens que nous
rassemblons globalement sous la dénomination de facteur. Quatre groupes rassemblant
au total 35 facteurs accélérateurs ont été identifiés.
Groupe 1 - Focus sur le niveau organisationnel : Nous avons recueilli un grand nombre
d’éléments au sujet de ce groupe. C’est celui qui a comptabilisé le plus grand nombre
d’occurrences dans le codage qualitatif. La généralisation étant principalement porté par
la DSI, de nombreux coachs ont évoqué l’importance de coordonner une démarche de
généralisation qui intègre les différentes couches de l’organisation, non seulement de la
DSI, mais aussi les différentes unités d’affaires : « Le pilote de la transition est l'ensemble
de la structure, il ne faut pas avoir de démarche uniquement top down dans un pôle, il faut
conjuguer une démarche de changement multidirectionnelle dans l’organisation » (coach 7)
et il faut « agir à tous les niveaux de l’organisation simultanément » (coach 1).
Les managers font partie des acteurs ayant fait l’objet de nombreuses occurrences. Les
coachs insistent sur le rôle important qu’ils doivent tenir : « La transformation vient de
l'intérieur, le manager va permettre à la transformation de se dérouler, il va faire en sorte
qu'il n'y a pas de bloqueurs, il va peut-être lever les bloqueurs qui vont empêcher la
généralisation d'arriver. Le manager n'est pas pilote, mais il est facilitateur, il doit avoir du
sponsorship, il doit donner envie de changer » (coach 10).
260
Groupe 4 – Les dispositifs à exploiter : cette catégorie de facteurs a été très riche en
retours d’expérience des coachs et fait par exemple référence aux postures
d’accompagnement précédemment évoqué.
« J'aime bien faire le coaching expérientiel, c'est en fait, le fait que je vais te donner
des outils, tu vas sincèrement les essayer, tu gardes ce que tu veux garder. L'idée est dans
l'expérimentation d'outils et de pratiques de sorte à trouver au mieux une bonne solution.
Il faut ensuite enlever certaines mauvaises pratiques, les faire oublier. Il y a beaucoup
d'outils que l’on diffuse par le biais du jeu, mais qui sont en fait des outils intellectuels »
(Coach 1).
Nous avons ainsi pu remarquer l’importance de la co-construction des pratiques /
outils entre les équipes projet et les coachs. D’autre part, un des dispositifs les plus mis
œuvre porte sur la création de communautés de pratiques. Ce genre de dispositif permet
de favoriser les échanges entre pairs pour faciliter le partage d’outils et de bonnes
pratiques :
Faute de pouvoir évoquer tous les facteurs de chaque groupe, la liste d’ensemble est
proposée en annexe 4 et 5. Les résultats présentés dans cette partie ont pour un certain
nombre été déjà identifiés dans la littérature. Cependant, les entretiens avec les coachs
agiles nous ont permis tout de même d’approfondir et de préciser plusieurs facteurs. Nous
proposons dans le tableau en annexe 5 une comparaison des facteurs déjà identifiés par
rapport aux résultats de l’étude de Dikert, Paasivaara & Lassenius (2017).
261
2.3 Facteurs ralentisseurs de la généralisation constatés
par les coachs
Si la littérature regorge de nombreux papier évoquant les défis (Hobbs & Petit, 2017),
ils sont finalement peu contextualisés dans une démarche de généralisation. Ainsi, comme
pour la partie précédente, nous avons identifié de nombreux facteurs freinant les
dynamiques de généralisation.
Les entités métiers s’approprient peu les approches agiles principalement en raison du
fait que les acteurs sont peu sensibilisés selon les coachs. « On a essayé de faire infuser ce
genre de nouveau rôle (Product owner – Scrum Master), mais c'est compliqué, car ils ne
ressentent pas le besoin. Il faut d’abord passer par une grosse action de sensibilisation et de
communication » (coach 7).
262
Groupe 3 - Gestion des différents paradigmes de gestion de projet : les approches agiles
sont particulièrement disruptives dans la manière d’organiser et de piloter un projet, ce
changement de paradigme peut donc générer des difficultés dans la conjugaison de
différentes approches : « Un autre problème que l'on a eu à un moment c'est la cohérence
des initiatives entre elles, à un moment il y avait une transformation agile continuous
delivery, en même temps de la généralisation de Scrum, et en même temps de la
professionnalisation des chefs de projet, en même temps de l’offshore à Bangalore. Les
initiatives en soit sont bien, mais quand tu les matchs, ça fait n'importe quoi. C'est vraiment
un problème des grandes structures » (coach 9).
Concernant le mauvais sens donné aux approches agiles : « Ce qui est un peu compliqué
pour moi dans les grandes organisations c'est qu’elles vont se focaliser sur les méthodes et
pas sur l'esprit qui est derrière. C'est là où j'ai du mal avec les grandes organisations dans
lesquelles je ne me retrouve pas moi. Soit ce sont des petits écosystèmes qui vont devenir
agiles. Soit, ils vont déployer juste l'outillage sans le sens qu'il faut » (coach 5).
Il figure que les coachs agiles ont tous désigné la généralisation d’une méthode agile
comme une transformation. Les nombreux freins identifiés montrent bien le besoin
d’accompagnement au changement induit par la généralisation. Comme pour les facteurs
263
accélérateurs, l’ensemble des facteurs freinant le processus de généralisation ont été
compilés dans un tableau en annexe.
264
Synthèse du chapitre 6
Dans ce chapitre 6, nous avons présenté les résultats de notre phase exploratoire qui étaient
composés d’une étude de cas pilote et d’entretiens exploratoires. L’analyse du cas Société
Générale nous a permis d’identifier au total 6 séquences dans le processus de généralisation de la
méthode Scrum en tenant compte de deux DSI du groupe. La présentation des différents
ingrédients de chaque séquence nous a ainsi permis d’identifier les éléments qui contribuent à
déclencher la généralisation d’une méthode agile de gestion de projet. Nos analyses nous ont
permis enfin d’identifier les mécanismes et les différentes dynamiques à l’œuvre.
L’étude de cas pilote nous a permis de valider un certain nombre d’éléments dans notre
approche méthodologique. La présentation des différentes séquences composées d’ingrédients,
de bifurcations caractérisées par des moteurs nous sert ainsi de support à l’analyse comparative
au cas de la phase explicative. Cette approche permet donc l’élaboration des résultats théoriques
de la recherche, lesquels sont détaillés dans le chapitre 8 de cette thèse.
Dans un second temps, les entretiens menés avec les coachs agiles nous ont permis de clarifier
leur rôle de cette nouvelle figure d’acteurs. Nous avons pu qualifier trois postures. D’une part ils
enrôlent le rôle de prêcheurs de nouvelles valeurs, matérialisées par les principes et valeurs du
manifeste agile. Cette posture est nécessaire pour préparer la mise en œuvre d’une méthode agile.
À cet effet, les coachs facilitent aussi les nouvelles dynamiques de groupe en accompagnant les
différents acteurs impliqués dans les projets. Nous avons pu identifier à cet effet une taxonomie
de facilitation. Enfin, en tant que guide engagé dans le changement, les coachs agiles se oeuvrent
comme des catalyseurs du changement à l’échelle d’une organisation.
Enfin, une seconde analyse du discours des coachs agiles nous a permis de dresser un
panorama des facteurs accélérant la généralisation d’une méthode agile et les facteurs qui freinent
le processus.
265
Chapitre 7 - Narration des trajectoires de
trois organisations complexes
Chapitre 6 Chapitre 7
Etude de cas pilote et analyse de Narration des trajectoires de
la figure naissante des coachs trois organisations complexes
agiles
266
Introduction
Nous exposons au cours de ce chapitre 7, les trois cas étudiés lors de la phase
explicative. Cette présentation reprend comme dans le chapitre précédent une forme
narrative. Les unités d’analyses présentées sont explicitées afin de retracer les différents
ingrédients, bifurcations et moteurs au cours des différentes séquences de chaque cas. En
procédant ainsi, nous permettons au lecteur de repérer les spécificités contextuelles des
cas étudiés et de juger que chaque cas présente des similitudes ou des différences.
Afin de faciliter la lecture de ce chapitre, nous avons opté pour une présentation
séquentielle et exposé chaque cas l’un après l’autre. Nous suivrons l’ordre dans lequel ont
été menés les travaux en commençant par le cas Amadeus (1), nous poursuivrons avec le
cas Banque de France (2) et nous clôturons ce chapitre par le cas GRDF (3).
267
1. Analyse du cas Amadeus
La société est implantée dans le monde entier par le biais de hubs centraux et de
bureaux régionaux qui aident à commercialiser les produits d'Amadeus et fournissent des
services à la clientèle. Au total, ce sont plus de 19 000 employés dans le monde qui
contribuent aux différentes activités du groupe. Le siège social de l’entreprise se trouve à
Madrid, les principales activités de recherche et de développement de produits sont
situées à Nice et les opérations principales sont gérées à Munich. L’entreprise est
notamment cotée en bourse et fait partie de l'index espagnol IBEX 35, qui comprend les
entreprises le plus importantes d’Espagne.
268
Le modèle économique d'Amadeus repose essentiellement sur trois groupes de
clients : les fournisseurs de voyages, les vendeurs de voyages et les acheteurs de voyages.
Dans la chaîne de valeur présentée en figure 55, les relations commerciales des groupes
respectifs sont principalement basées sur les systèmes de réservation proposés par
Amadeus. Dans cette chaîne de valeur, les fournisseurs de voyages distribuent leurs
produits par le biais des systèmes électroniques de réservation et de distribution. En
retour, Amadeus perçoit des frais d'utilisation et de réservation pour offrir ses services.
Les sièges d'avion représentent la plus grande part de ces réservations de voyage. Les
frais perçus pour les réservations de voyages représentent environ 70 % des recettes
d'Amadeus et le niveau de participation des prestataires définit le montant des frais de
réservation payés.
269
sites web et compagnies aériennes d’opter pour une adaptation des prix en fonction de
l’offre et de la demande. cc
Le second métier au cœur d’Amadeus réside dans l’offre « Airlines IT ». Ces services
permettent de mettre en place des plateformes informatiques de gestion de clientèle
permettant de fournir des solutions pour la réservation, l'inventaire et le contrôle des
départs dans les aéroports. Ces solutions permettent notamment de couvrir l’ensemble
du cycle de vie d’un voyageur comprenant les recherches, l’achat, la préparation du
voyage, le voyage et le retour du voyageur auprès des compagnies aériennes.
Ce virage stratégique initié en 2012 est synthétisé par un historique dans le tableau 44
avait notamment pour but de réduire la dépendance vis-à-vis des compagnies aériennes.
Amadeus a décidé de changer d'orientation stratégique, passant d'un système de
réservation classique à un fournisseur de services technologiques de solutions pour
l'industrie du voyage et du tourisme qui vont au-delà de la distribution.
cc Plus connue sous le nom de yeld management. Les systèmes d’Amadeus permettent de gérer les tarifs
et les capacités disponibles des fournisseurs et vendeurs de voyages pour optimiser les taux de remplissage
des compagnies.
270
Afin de mettre l'accent sur cette orientation, Amadeus a changé son nom de société,
passant de Global Amadeus Travel Distribution SA à Amadeus IT Group SA. Le slogan
« votre partenaire technologique », qui complète le nom de la marque, se révèle être un
indicateur de cette approche stratégique. Amadeus vise ainsi à devenir le premier
fournisseur mondial de services IT pour l'ensemble du secteur du voyage.
271
1.1.2 Structuration des unités d’affaires et de la R&D
La R&D contribue énormément au cœur de métier d’Amadeus puisque c’est dans cette
entité que les produits logiciels sont développés par différentes communautés
d’ingénieurs. Celles-ci sont organisées comme un réseau de centres technologiques à
travers le monde. Ces centres technologiques sont totalement autonomes et partagent les
responsabilités des domaines fonctionnels, des activités transversales et des projets des
clients. La communauté d'ingénieurs Amadeus est organisée en un ensemble d'équipes
intégrées dans chaque unité commerciale, complétées par deux grandes unités
transversales pour les activités techniques communes à savoir les plateformes
technologiques (infrastructures) et les Services partagés de base.
La R&D sur les services partagés de base (CSS) est responsable des demandes de
réservation, de tarification et d'achat de billets d'avion, ainsi que les fonctionnalités de
paiement, qui sont communes au système de réservation et aux différents produits
informatiques. Le CSS est également responsable de la gouvernance de la qualité des
outils de développement et des méthodologies de gestion projet pour toutes les unités
d’affaires.
Une fois le contrat signé, un manager de projet est assigné en interne. Son rôle porte
essentiellement dans le pilotage des ressources des différentes divisions du département
272
R&D afin de délivrer les solutions envisagées par les clients. L’organisation des projets au
sein d’Amadeus dépend ainsi d’une structure organisationnelle matricielle. En termes de
pratiques méthodologiques, une forte sensibilité aux bonnes pratiques du PMI ont été à
plusieurs reprises évoquée au cours des entretiens. Nous reviendrons sur ce point dès la
première séquence du cas.
Un des faits marquants ayant eu lieu au cours de ces 10 dernières années dans l’activité
R&D d’Amadeus, réside dans la nomination en 2012 d’un nouveau directeur de l’entité.
Compte tenu de la stratégie de diversification et des investissements croissants dans la
R&D, les deux priorités selon l’ancien directeur portaient notamment sur le
développement de plateformes performantes en termes de suivi des voyageurs, ainsi que
sur la réactivité de ses équipes :
273
1.2 Analyse des séquences de généralisation
Dans cette optique nous avons pu constater une forte politique de certification des
chefs de projet chez Amadeus. En effet la certification Project Management Professionnal
(PMP) du Project Management Institute est privilégiée pour fournir aux chefs de projets
un socle de connaissances. Il est par ailleurs important de préciser que cette certification
est particulièrement lourde à passer, elle nécessite de longs mois de préparation avec un
examen de 4 heures. Tous les chefs de projets ayant été interrogé au cours de nos
entretiens étaient certifiés PMP.
Nous avons pu de plus identifier deux autres éléments dans cette période. D’une part,
une très forte culture portant sur la mesure de la performance est maintenue par la
direction d’Amadeus :
« On reste une société où le top management a entre 55-60 ans ayant toujours eu
l'habitude des KPI extrêmement précise, on est une société qui est dirigée par un
ancien CFO, donc qui reste quand même extrêmement dans la gouvernance de la KPI,
savoir combien un projet a couté va falloir toujours le demander aux gens de reporter
leur temps » (selon un PMOdd).
dd Project Management Officer : il s’agit notamment de consultant internes chargé d’accompagner les
chefs de projet dans le pilotage du développement des projets.
274
D’autre part, la stratégie de diversification du groupe touchait à cette époque
essentiellement les équipes de la R&D. Elles sont à cet effet fortement mobilisées pour
développer de nouveaux produits à destination des aéroports. Dans cette dynamique, une
nouvelle entité voit le jour pour développer ces services. Quant aux ingénieurs travaillant
sur la conception des logiciels, la R&D continuera à appliquer les bonnes pratiques issues
du CMMI jusqu’en 2012 sans réévaluation de la maturité par la suite.
« Alors j'en entendais parler un peu [la méthode Scrum] parce qu’en fait j'étais dans
une équipe de coordinateur de projets et il y avait une personne dans l'équipe qui
travaillait sur un projet qui était mené en agile et lui il avait le rôle de Scrum Master,
c’étaient les débuts » (selon un PMO).
« J’ai des souvenirs d’avoir vu passer un fichier Excel qui rassemblait les bonnes
pratiques de Scrum, et ce fichier se passait d’équipe en équipe » (selon un troisième
PMO).
Les équipes de la R&D impliquées dans les projets avaient une certaine marge de
manœuvre quant aux pratiques de travail. Comme nous l’évoquions, la jonction entre la
R&D et les unités d’affaires est matricielle. Tous les acteurs ne sont pas nécessairement
dédiés à plein temps dans les projets, générant ainsi certaines libertés dans la mise en
œuvre de pratiques. D’autre part, le département méthode à l’époque ne reconnait pas
encore officiellement la méthode Scrum.
Nous avons qualifié ce dernier ingrédient d’initiative émergente en raison du fait que
la méthode n’est pas encore réellement reconnue en interne. Les acteurs se partagent des
retours d’expériences par le biais d’échanges informels et contribuent à diffuser la
méthode de cette manière au sein des équipes de la R&D. En parallèle les chefs de projets
sont fortement accompagnés dans les bonnes pratiques du PMBoK, ce qui leur laisse une
certaine marge de manœuvre quant au mode de fonctionnement à adopter.
275
L’initiative émergente et le contexte nous conduisent à marquer cette séquence
d’ingrédients d’Evolutionniste. L’objet de la mise en œuvre de la méthode Scrum ne
provient pas d’un acteur en particulier, il figure que les équipes mettent en place la
méthode en considérant elle-même leur propre besoin. Le tableau 45 reprend ci-dessous
l’ensemble des ingrédients présentés.
276
1.2.2 Séquence 2 : La reconnaissance de Scrum comme nouvelle approche
Dans cette deuxième séquence, les ingrédients sont radicalement différents et l’arrivée
d’un nouveau directeur de la R&D va radicalement changer le cours des événements. La
bifurcation ici ne détient pas vraiment de freins antécédents (figure 58), en raison du fait
que la nomination de ce nouvel acteur s’explique par le départ à la retraite de son
prédécesseur. Plusieurs acteurs nous ont relayés qu’une nouvelle donne au sein de la R&D
provenait de ce nouveau directeur :
« Un responsable qui venait de SAP, qui à instaurer une sorte de renouveau dans
l'approche du développement qui était à la tête des 6000 personnes jusqu'à peu encore
et c'est cette personne qui a essayé d'instaurer une nouvelle façon d'appréhender les
cycles de développement, il nous a fait rentrer dans l'agilité de plein fouet et donc là on
a vu des augmentations de budget pour le coaching, une structuration de l'approche
agile, il y a eu une accélération » (selon un membre du PMO)
Deux freins ont notamment nourri la nouvelle dynamique impulsée par le nouveau
directeur de la R&D. D’une part, il relève que les pratiques de travail sont très diversifiées
dans les différentes équipes (R&D-IGRT-2.2) et d’autre part, il constate un certain manque
de réactivité dans les projets en raison de la complexité des architectures techniques
(R&D-IGRT-2.2).
« J'ai commencé à travailler dans ce qu'on appelait les fronts office, on avait un
temps des mises à jour des logiciels, qui entre le moment ou le client exprimait son
besoin et le moment ou on mettait en production, il se passait 9 mois, on peut en faire
des choses en 9 mois, mais en l'occurrence certains ont trouvé que c'était long, parce
277
que les besoins métier avaient pu changer entre temps » (selon un manager de
projet).
« Les PMO ont été à la base la volonté de Hervé Couturier arrivé en 2012 de SAP donc
c'était un grand changement pour AMADEUS. […] Et compte tenu de notre nouveau
positionnement, on se compare à des sociétés comme Oracle, SAP ou Accenture donc des
fournisseurs de services IT et pas comme des GDS. Dans cette transformation si vous
voulez, le choix de Hervé Couturier était instrumental puisque c'est quelqu'un qui venait
de SAP et il voulait faire évoluer les choses » (selon un membre du PMO).
« Il est arrivé avec un certain bagage qui a donné à Alpha une accélération de cette
transformation, je pense que c'est indéniable » (selon la responsable de la communauté
de management de projet).
278
sur la mise en place de formations à destination des équipes de la R&D. Celles-ci sont
principalement menées par des cabinets de conseil externes (R&D-IGRT-4.2.1).
D’autre part, l’accompagnement des équipes s’effectue dans un premier temps par la
montée en compétences des acteurs au sein des PMO. Ce sont notamment les premiers
acteurs habituellement dédiés à l’appui aux projets (R&D-IGRT-4.2.2) :
D’autre part, comme l’évoque l’extrait précédent, des coachs sont recrutés pour
accompagner les équipes. Il est assez intéressant de constater dans ce cas l’émergence de
cette nouvelle figure d’acteur pour accompagner les différentes équipes projet. En ce sens,
un chef de projet évoquait (R&D-IGRT-4.2.3).
« Nous avons été principalement accompagnées dans la mise en place des pratiques
d’estimations en mode agile, des pratiques de planifications et d’auto-organisation par
des coachs agiles » (selon un chef de projet).
« Nous les accompagnons dans la mise en place du cadre méthodologique, mais l’idée
c’est aussi de leur fournir des pratiques qui sont adaptées en fonction des contextes. Il
nous arrive souvent de proposer de mettre en place Kanban » (selon un coach agile).
Lorsqu’une équipe souhaite se lancer dans un projet par le biais de la méthode Scrum,
celles-ci doivent valider une liste de prérequis (Formation suivie, nominations d’un Scrum
Master et Product Owner, etc.). Cette procédure est nommée Agile Boarding pass en
interne et se révèle être le support permettant de valider qu’une équipe se lance dans de
bonnes conditions (R&D-IGRT-4.2.4).
Afin « d’outiller » les différentes équipes et rendre accessible à tous les projets les
pratiques méthodologiques privilégiées en interne, un cadre méthodologique est
formalisé au cours de cette séquence (R&D-IGRT-4.2.5). L’objectif est notamment
d’homogénéiser les différentes pratiques mises en œuvre pour favoriser la collaboration
entre plusieurs équipes. Le cadre méthodologique nommé AMAMET signifiant Amadeus
Methodology, tiens compte à la fois des bonnes pratiques du PMBoK (notamment en ce
qui concerne le séquencement des tâches, les indicateurs clés de performance) et des
pratiques et rituels de la méthode Scrum.
279
Enfin, dernière initiative planifiée au cours de cette séquence concerne la mise en place
ambassadeurs pour favoriser la contextualisation de la méthode en interne (R&D-IGRT-
4.2.6). Il s’agit essentiellement d’acteurs ayant préalablement travaillé avec la méthode
Scrum qui se mobilisent pour partager des retours d’expériences au sein des événements
organisés par la communauté de management de projet.
Au-delà de ces initiatives, les données récoltées dans le cadre du cas Amadeus nous
permettent de faire apparaitre un certain nombre de freins. En 2014, afin d'évaluer la
mise en œuvre de la méthode Scrum, une évaluation de la maturité des équipes est lancée
(R&D-IGRT-5.2). L'objectif était de mesurer la mise en œuvre effective de Scrum dans les
équipes de développement et de mieux comprendre comment Scrum est mis en place. Il a
notamment été observé que de nombreuses équipes de développement ont adopté Scrum,
mais la méthode n'est pas appliquée fidèlement et révélant une hétérogénéité de mise en
œuvre.
« Nous sommes normalement tous en Scrum, mais nous ne le sommes pas vraiment
dans le sens où nous n'avons pas de ScrumMaster ; par exemple nous avons un testeur
Scrum, nous avons toujours un chef de projet […], mais si nous voulions vraiment
appliquer l'agile comme sur le papier nous n'y sommes pas du tout » (selon un chef
de projet).
Un Product Owner est censé par exemple représenter un utilisateur final et faciliter la
synchronisation des différentes équipes de développement impliquées dans un projet. Un
coach agile évoquait à cet effet : « Certains chefs de département de la R&D sont devenus
Product Owner en gardant une posture de commande et de contrôle sans promouvoir la
notion de responsabilité partagée prévue dans Scrum ».
La culture de l’excellence technique est assez forte au sein de la R&D, en ce sens, les
responsables font preuve : « d’un management orienté à 20% sur de l’humain et 80% sur
la technique » (selon un coach agile). L'expertise et les orientations des responsables sont
fortement présentes caractérisant ainsi simplement un affichage de mise en œuvre de la
méthode Scrum sans réelle appropriation du fonctionnement proposé.
Même si l'objectif n’était pas de standardiser la méthode à toutes les équipes, celle-ci
n’était pas rendue obligatoire pour les équipes de développement. À ce stade, les mises en
œuvre divergentes remettent en cause l'ambition du programme.
« Certaines équipes ont adopté Scrum en se disant que ça leur donnerait moins de
contraintes dans les projets, la méthode a été comprise comme une transformation
de lâcher prise » (selon le directeur des services d'ingénierie du développement).
280
Au cours de nos entretiens, de nombreux acteurs ont signalé le manque d'implication
des ressources humaines (RH). Comme Scrum propose de nouveaux rôles, ceux-ci n'ont
été adoptés que de manière « virtuelle » :
« Je ne sais pas ce qu'ils font, mais le vrai problème c’est qu'aux RH, cela prend du
temps. Cela affecte l’humain, la définition des rôles, des périmètres, peut-être des
salaires […] Cela prend aussi du temps parce que nous avons des syndicats très forts
en France, et je ne sais même pas si un jour cela sortira ou si la prochaine
transformation arrivera plus tôt » (selon un PMO local).
L'aspect virtuel fait référence au fait que les acteurs et les processus sont peu ancrés
dans les politiques internes de l'organisation, car le champ de déploiement reste limité à
la R&D (R&D-IGRT-6.2). Les chefs de projet continuent à être formés et certifiés sur le
PMBoK, ce qui crée des dysfonctionnements dans la collaboration entre les acteurs
composant un projet.
Une des difficultés majeures rencontrées dans la faible maturité des équipes de la R&D
réside dans le taux de rotations des acteurs. L’organisation est particulièrement dense et
de nombreux individus proviennent de société de services externes. Les équipes sont
ainsi souvent renouvelées au cours du développement des projets ayant ainsi pour
principale incidence de réduire la performance des équipes (R&D-IGRT-8.2).
« Malgré la forte incitation à mettre en œuvre Scrum, nous avons décidé de faire
un pas en arrière pour consolider les réalisations, et mieux préparer le reste du
déploiement » (selon le directeur du développement des services d'ingénierie).
Suite à l'évaluation, une nouvelle mesure est créée en 2014. Avant de lancer un projet
en mode agile, un système de pré-évaluation du projet a été mis en place entre les PMO
locaux et les projets pour initier le lancement du projet en mode agile.
Afin de combler les problèmes identifiés, cette séquence se termine par le biais d’un
dernier ingrédient préparant la suite des événements. Un mode de fonctionnement
inspiré du modèle de l’entreprise Spotify est expérimenté. L’idée est de mettre en place
281
des tribus d’équipes Scrum pour faciliter la coordination et la synchronisation des
différentes équipes (R&D-IGRT-8.2). Nous verrons dans la séquence suivante que ce mode
de fonctionnement sera privilégié pour l’ensemble de la R&D.
282
R&D-IGRT- __Déploiement de la méthode Initiative
4.2.1 Scrum dans les équipes R&D planifiée
par la formation
R&D-IGRT- __Le rôle des PMO se Initiative
4.2.2 renforcent dans planifiée
l'accompagnement des chefs
de projets
R&D-IGRT- __Coaching de sensibilisation Initiative
4.2.3 aux pratiques de planification, planifiée
estimation, etc.
R&D-IGRT- __Mise en place d'un Agile Initiative
4.2.4 Boarding Pass - évaluation a planifiée
priori des validant des
prérequis
R&D-IGRT- __Création du cadre Initiative
4.2.5 méthodologique AMAMET planifiée
R&D-IGRT- __Mise en place Initiative
4.2.6 d’ambassadeurs dans la planifiée
communauté de management
de projet pour favoriser les
retours d'expériences
R&D-IGRT- Une évaluation de la maturité Initiative
5.2 des équipes de la R&D est
2014 lancée révélant
l'hétérogénéité de mise en
œuvre de Scrum
R&D-IGRT- Le déploiement cible Frein Dialectique
6.2 principalement les individus
de la R&D sans impliquer les
ressources humaines
R&D-IGRT- Des failles de fonctionnement Frein
7.2 (synchronisation, outils
utilisés) sont constatées entre
les équipes R&D et les chefs
de projets
R&D-IGRT- Fortes rotations du personnel Frein
8.2 dans la R&D et dans les
différentes unités d'affaires
283
1.2.3 Séquence 3 : Vers le déploiement de Scrum
Le programme Agility est lancé avec 3 objectifs précis : la réduction du time to market,
qui porte ici plus précisément sur le délai de mise en production des nouvelles
fonctionnalités développées par les ingénieurs de la R&D. Le deuxième objectif défini
porte sur une amélioration de la réactivité des équipes de développement en tenant
compte des différents projets et des clients. Le troisième porte sur l’efficacité des équipes,
l’objectif est de réduire les « coûts de friction » organisationnels, il s’agit là des
mésaventures engendrées par la mauvaise synchronisation des équipes pouvant générer
du double travail dans certains cas.
Cette séquence aboutit donc très tôt à la création du modèle ASAM. Avant d’évoquer
les autres initiatives pour déployer ce mode de fonctionnement, précisons certains
aspects. Comme le présente la figure 61, le modèle reprend les lignes organisationnelles
284
de la R&D correspondant aux liens avec les différentes unités d’affaires. Dans le précédent
mode de fonctionnement, plusieurs acteurs d’une ligne organisationnelle pouvaient être
mobilisés selon différents niveaux d’implications dans les projets. Dans le nouveau mode
de fonctionnement, l’idée est de rassembler les compétences nécessaires pour favoriser
des équipes pluridisciplinaires, avec des individus dédiés à plein temps pour un projet
(partie en pointiller de la figure 61). Ce regroupement en tribu est un moyen de gérer la
complexité selon le créateur du modèle, une tribu peut contenir entre 40 et 120 personnes
chez Amadeus.
De nouveaux rôles émergent dans cette séquence. D’une part, le Product Owner tel qu’il
est envisagé dans la méthode Scrum n’est pas au positionnement initial. Il s’agit selon un
coach agile d’un « Back Product Owner » en raison de son positionnement au sein de la
R&D et non auprès du client final. Deuxièmement un Product Owner de tribu est mis en
place afin de coordonner et prioriser l’ensemble des besoins des différentes équipes.
Celui-ci interagit principalement avec les différents chefs de projets étant eux-mêmes en
lien avec les différents clients.
Chaque tribu détient aussi un Tribe Leader dont le rôle porte sur la facilitation du des
différentes interactions. Il s’assure que les équipes de sa tribu disposent du meilleur
environnement possible pour exercer et livrer leurs produits par incréments. Le Tribe
Leader peut gérer l’ensemble de sa tribu et être un point de contact avec les autres tribus.
Enfin, chaque tribu dispose également d’un coach dédié pour accompagner les équipes
dans la mise en œuvre de pratiques adaptées. Il intervient aussi auprès des équipes pour
faciliter les dynamiques de groupe en animant notamment certains rituels comme les
réunions de planification ou démonstration.
285
La création de ces différents rôles représente un second ingrédient lié à la création du
programme Agility (R&D-IGRT-1.3.2). Plusieurs initiatives planifiées sont ainsi lancées
pour déployer ce nouveau mode d’organisation. Les recettes sont d’ailleurs quasiment les
mêmes que le premier programme de transformation. Le déploiement du modèle
organisationnel en tribus pour toute la R&D se fait par le biais de coaching auprès des
équipes ; de communications dans les différents événements des communautés de
pratiques ; puis, par le renforcement des formations certifiantes.
L’un des premiers évoqués concerne le fait qu’une tribu est dédiée à plusieurs projets
et maintenances en parallèle, un membre du PMO évoque notamment :
Une chef de projet évoque aussi ses difficultés à interagir dans ce nouveau mode
d’organisation :
« Avant on avait les organisations matricielles simples, c’est-à-dire qu’on avait des
équipes expertes sur des sujets ou qui étaient gérées par des managers à qui on
demandait de livrer telle ou telle chose pour tel et tel projet, c’est une organisation à
double entrée. J’ai une ligne hiérarchique de manageurs, et puis j’ai des projets en
transverse qui ont des demandes et donnent des budgets. Une fois qu’on avait les
estimations, on donnait le budget aux lignes d’organisation verticales. Avec l’agilité,
on a toujours ces organisations verticales, parce qu’il faut des manageurs pour les
gens. Mais les manageurs vont donner leurs ressources à des tribus, et le tribe leader
n’est pas forcément le manageur des gens. Ça complique beaucoup la manière dont
nous pilotons les projets ».
286
Un coach agile précise de plus que l’une des problématiques réside dans la capacité de la
R&D à mobiliser assez de ressources pour répondre à toutes les sollicitations :
« Tout est basé sur le fait qu’on n’a pas la capacité pour tout développer, je ne
connais pas encore de projets qui arrivent dans les temps chez Amadeus et où il y a
la bonne capacité pour tout développer dans ce qui est marqué dans le contrat. Avant
on avait une capacité fixe pour un seul projet […] maintenant on a une capacité fixe
pour adresser plusieurs projets au sein d’un produit, pour faire simple sachant qu’il y
a n produits. »
Afin de clarifier le mode fonctionnement évoqué par les différents acteurs en lien dans
les projets, la figure 62 détaille les différentes interactions entre chefs de projet et acteurs
de la R&D. Le cercle orange dans la tribu désigne les équipes Scrum. Comme les équipes
de la R&D servent plusieurs clients avec le même produit, un chef de projet peut
représenter ici un client. Ainsi contrairement à ce qui est évoqué dans le discours des
présentations officielles, les équipes de la R&D sont sollicitées pour de nombreuses tâches
freinant ainsi la réactivité recherchée par les responsables de l’entité.
Figure 62 : Modélisation simplifiée des interactions entre une tribu et les chefs de
projets
« C’est très compliqué. On a donc la partie commerciale, les commerciaux, etc. qui
discutent avec les clients, on a les project manager (PM) qui discutent les parties
fonctionnelles avec les clients, ensuite les PM discutent avec ce qu’on appelle les
analystes fonctionnels en interne et les fonctionnels analystes discutent avec les
287
développeurs. Donc entre temps, donc nous en tant que project manager aussi on
intervient à certains moments, etc. pour coordonner tout ça, mais il y a beaucoup de
perte d’informations » (selon un chef de projet)
« Je ne dis pas que c’était parfait et que c’était mieux avant, parce que
théoriquement c’était vraiment pour le time to market, la customer satisfaction, parce
que le monde de l’IT évolue et il faut qu’Amadeus soit là-dedans. Mais, Amadeus est
une énorme entreprise, un énorme bateau, super long à faire virer, et on a une
architecture tellement compliquée. Pour rajouter une information sur votre écran
BtoC quand vous achetez un vol, des fois il faut traverser 4 couches, appeler 6 services
à droite à gauche, et donc forcément c’est compliqué parce que vous n’avez pas une
Scrum team qui est dédié à un projet. L’architecture est très compliquée, et du coup
on a beaucoup de dépendances » (selon un chef de projet).
« Il y a des petites équipes, des équipes scrum, etc., mais les mecs qui sont là-dedans
ils ne sont jamais autonomes parce qu’il faut qu’ils attendent l’aval d’un tel, qui lui-
même est en mode sprint et qui n’a pas le temps, car son projet est plus prioritaire. Il
n’y a rien qui n’est calé avec rien, chaque organisation à ses propres cycles du coup
c’est très très difficile de faire avancer les projets alors que quand on avait un
planning sur beaucoup plus de temps c’était plus facile d’orchestrer tout le monde »
(selon un chef de projet)
Le nouveau modèle cible matérialisé par l’approche ASAM est destiné dans cette
séquence uniquement les équipes de développement de la R&D et n’inclut pas
nécessairement toute la chaîne de valeur d’un projet (UA-PROJ-IGRT-3.3), plusieurs
explications appuyant ce frein :
« Chaque année on avait une nouvelle initiative qui phagocytait la précédente donc
on a commencé mi-juillet 2013. Je vais donc vous parler du péché originel d’Hervé
[directeur de la R&D] : il a décidé de partir en agile qu’avec la R&D sans parler avec
les autres. Problème : quelles sont les responsabilités du Product Owner par rapport
à un chef de projet ? On a donc créé un passif qui existe encore aujourd’hui. Le
problème c’est qu’il faut bien faire démarrer le bateau à un moment ou à un autre,
mais encore aujourd’hui le contact avec le client n’y est pas » (selon un membre du
PMO central)
Dans une autre entité, le problème se révèle être le même, mais l’acteur précise que les
entités ont toutes leur propre mode d’organisation, ce qui se révèle être un frein en plus
pour la mise en œuvre du modèle ASAM :
« Chez SGB on a des chefs de projets centralisés chez la partie transverse qui vont
négocier avec le client, c’est-à-dire qu’ils sont professionnels là-dedans et ils savent
piloter un projet, calmer le client s’il le faut. Cette transformation n’a pas tout de suite
288
pris en compte cet aspect chef de projet puisque chaque customer unit à un peu sa
façon de gérer le projet. Pour certains ce sont directement ceux du dev qui sont
technique et qui vont manager le projet, pour d’autres ce sont ceux du marketing et
nous c’est entre les deux c’est un service transverse… donc dans ASAM ça ne pouvait
pas être pris en compte de partout étant donnée les divers types » (selon un coach
agile).
Les projets fonctionnent ainsi dans un mode bicéphale en raison des différentes
approches mises en œuvre (PROJ-IGRT-4.3). La méthode Scrum suit une contextualisation
plus forte au sein des acteurs en lien direct avec la conception. Néanmoins, les effets des
initiatives se révèlent être inverses auprès des chefs de projets. Ils appliquent
essentiellement des pratiques de pilotage séquentiel et ne s’intègrent pas dans le mode
de fonctionnement itératif des tribus :
« Le problème c’est que lorsqu’il n’y a pas de deadline chacun veut faire la sienne
[…] Au début les chefs de projets s’y opposaient, chacun voulait ses dates entre sprint
et jalons… Aujourd’hui on les a raisonnés sur le fait qu’il fallait qu’on collabore et
qu’on avait tout à y gagner, du coût ils se sont formés, ont suivi le training agile et ils
sont ok pour regarder les outils qui sont propres à la tribu pour comprendre la
déviation des deadlines, etc. Ensuite les PMO de mon équipe les aident à piloter sur la
base des indicateurs de la tribu » (selon un coach agile).
D’autres chefs de projet expriment de façon plus claire leurs réticences liées au
nouveau mode de fonctionnement :
« C’est des jalons qui m’intéressent moi pour observer l’évolution. Le client n’a pas
forcément besoin d’avoir ces détails-là parce que lui ce qui l’importe c’est la date de
delivery finale, mais moi j’aime bien avoir cette visibilité et en waterfall j’arrivais à
monitorer des jalons que j’ai du mal à avoir en agile. […] Comme on n’a pas fait
d’indicateurs efficaces aujourd’hui on est obligé de compenser manuellement en
étant présent un peu dans tous les rituels scrum, en en faisant ré-estimer
régulièrement les prévisions pour voir s’il y a des déviations sur les coûts […] Je suis
obligée d’être présente sur le terrain, de sentir le vent tourner moi-même. Et je pense
que ce n’est pas qu’imputable à la mixité agile/waterfall, mais en partie. »
« Les gens ne travaillent pas tous de la même façon, et honnêtement pour arriver
à ce que tout le monde travaille ensemble il y a encore du travail, en gros si tu es
waterfall t’utilises Microsoft Project (MSP) et si tu es agile, tu as Jira, mais nous
n’avons pas les datas et les équipes Scrum utilisent leur propre sizing » (selon un chef
de projet).
289
La création des nouveaux rôles proposés dans le cadre ASAM trouble les aspects liés
aux responsabilités dans les projets (PROJ-IGRT-5.3). Entre les Product Owner gérant leur
propre priorité dans les équipes et les tribe product owner qui priorise les projets pour
une tribu, les chefs de projets perdent une partie de leur rôle initial. Ils avaient
initialement pour habitude d’être en mesure de fournir les priorités en direct aux équipes
de développement sans intermédiaire :
« On m’a donné un super Product Owner pour mon projet qui est du coup un point
d’entrée privilégié avec la R&D, on travaille en trinôme avec le project manager, mais
je collabore aussi avec manager d’une solution c’est quelqu’un qui est aussi Product
Owner. Le tribe product owner est censé être très au courant de mes priorités, il est
responsable de son côté aussi de prioriser les projets dans les différentes Scrum team.
Mais ça demande une communication entre eux, entre ce PO-là et les autres PO. Et
moi ce que je trouve délicat c’est que ce PO-là, on les fait arbitrer, on leur donne une
responsabilité sur le planning de toutes les Scrum team, mais il ne voit pas forcement
toutes les implications de toutes les taches techniques, ils n’arrivent pas trop à faire
un rétro planning pour arriver à savoir quand est-ce qu’il faut commencer les choses
et ça c’est des choses que j’arrivais très bien à gérer en tant que project manager en
waterfall, mais en agile, j’ai beaucoup moins d’emprise sur les différents jalons d’une
tache » (selon un chef de projet).
Les cinq premiers ingrédients de cette séquence (tableau 47) caractérisent ainsi une
faible appropriation de la méthode Scrum auprès des chefs de projet (PROJ-IGRT-6.3). Ils
font preuve d’une certaine réticence en raison du fait qu’ils ne trouvent pas leur place
dans ce nouveau mode de fonctionnement :
« Donc en fait il y a un gros impact sur la partie planning et pour moi c’est nouveau
et je trouve ça un peu délicat en tant que manager de projet parce que sur un projet
waterfall basique j’étais vraiment responsable/ accountable de la partie planning et
les équipes avaient des comptes à me rendre sur leurs plans, en cas de décalages,
c’était à moi de vérifier qu’ils mettaient bien tout dans les plans. Et là, donc les équipes
scrum avec lesquelles je travaille ne font pas que mon projet, elles font plein de petits
projets, elles font de la maintenance, elles ont plein de choses à faire et donc c’est
assez compliqué d’influencer sur les plannings parce que les Product Owner n’ont pas
forcément en tête toutes mes contraintes. J’ai observé par exemple que les retards ou
les augmentations de coûts ne remontaient pas facilement parce que les
développeurs estiment que c’est au Product Owner qu’ils doivent le dire, le Product
Owner ne pense pas forcément à me le dire, j’ai un petit peu des problèmes pour avoir
des remontées des retards et des choses comme ça » (selon un chef de projet).
Malgré les nouvelles responsabilités qui émergent, tout le mode d’organisation mis en
place au sein de la R&D est considéré comme « virtuel ». Tout comme dans la séquence
précédente, l’implication du département des ressources humaines arrive tardivement
290
dans le temps, laissant ainsi émerger des problématiques en termes d’assignation des
individus dans les projets (R&D-US-IGRT-7.3) :
« Les équipes Scrum n’ont aucune existence dans l’organigramme, elles existent
que de manière virtuelle donc on se retrouve à avoir des acteurs impliqués dans
plusieurs projets sans avoir le même niveau de responsabilité » (selon un PMO).
Les freins liés à la mise en œuvre de Scrum dans les équipes projet ne dépendent
cependant pas que du ressort des équipes internes. Plusieurs acteurs ont évoqué que
certains clients n’étaient pas sensibles au mode de fonctionnement agile. Nous avons pu
identifier deux ingrédients clés illustrant ces freins. D’une part la contractualisation avec
les clients fige dès le départ un mode de fonctionnement fermé, i. e exigeant des livrables
à des temps déterminés (UA-IGRT-8.3). Puis, le manque de sensibilisation du client autour
des potentiels bénéfices liés à la mise en œuvre de Scrum n’incite pas les clients à se
rendre disponibles pour fluidifier la conception des projets (UA-IGRT-9.3).
« Beaucoup de nos projets travaillent en mode agile avec des sprints, etc., mais qui
de toute façon sont engagés sur un contrat fixe, excusez-moi je mélange le français et
l’anglais, ils sont engagés à livrer un scope [nombre de tâches très précises à
développer] signées avec un client. Quand on signe avec une airline sur un projet de 5
ans, moi j’ai travaillé sur un projet avec Japan Airline, Amadeus a engagé 700 men/
year de développement, on ne peut pas s’amuser a reprioriser sans arrêt, à refaire la
vie tous les matins, ce n’est pas possible. Donc, après une fois qu’on a ce scope la avec
des spécifications détaillées, signées, est ce qu’on peut travailler en agile, peut-être,
mais faut être hyper carré et bien maîtriser ce qu’on pousse, bien maîtriser, fin, voilà
on peut travailler avec les sprints, les méthodologies, les jira, etc. oui ce n’est pas un
problème, mais je trouve que c’est assez limite quand on n’est pas en agilité avec le
client de A à Z, je ne vois pas trop l’intérêt en fait » (selon un chef de projet).
« La réactivité et l’adaptation n’y a pas de soucis, les équipes elles sont réactives,
elles s’adaptent aux grandes fonctions des besoins, elles s’adaptent en fonction des
priorités aussi puisqu’on essaye de courir plusieurs lièvres en même temps. La plus
grosse problématique encore une fois, l’avantage c’est qu’on a les project manager,
donc les gens qui discutent avec les clients, ils sont avec nous localement ici dans les
bureaux donc ça, c’est un gros gros avantage. Ça permet vraiment de discuter assez
rapidement sur beaucoup de choses. Le gros désavantage c’est que le client n’est pas
prêt à travailler en mode itératif et incrémental, il ne sait pas faire et n’est pas plus
intéressé que ça » (selon un chef de projet).
« Comme nos équipes sont délocalisées donc on a des équipes ici à Sophia, on a des
équipes à Bangalore, à Singapour, à Orlando, et notre client est aussi distant. Certain
sont réticents, faire de l’agilité de bout en bout c’est très compliqué avec les clients
291
des pays du golf par exemple, car ils veulent juste respecter le scope et pourtant les
exigences évoluent dans le temps » (selon un chef de projet).
292
1.2.4 Séquence 4 : Vers le déploiement de SAFe
Comme nos données ne nous permettent pas de reconstituer finement les derniers
événements entre 2018 et 2020, nous proposons de détailler de manière succincte les
points clés de cette nouvelle séquence qui permettent tout de même de reconstituer
certains faits.
Pour favoriser l’alignement de toutes les parties prenantes aux projets, il a été décidé
de mettre en place le cadre méthodologique SAFe. Ce cadre a été choisi pour deux raisons :
d’une part certains éléments de SAFe ont été adoptés dans le modèle ASAM au cours de la
séquence 3, deuxièmement le cadre SAFe se distingue par le degré de précision quant aux
rituels à mettre en place pour mobiliser plus de monde autour de la méthode Scrum.
L’une des initiatives clés pour mettre en place SAFe porte sur la formation et la
certification (R&D-IGRT-1.4). En effet l’approche méthodologique propose un cadrage de
mise en œuvre très précis. Un certain nombre d’acteurs du PMO ont donc suivi une
formation SAFe Program Consultant (SAFe SPC). Il s’agit d’une formation certifiante
permettant d’acquérir les éléments de mise en œuvre du cadre méthodologique. La cible
n’est donc plus uniquement la R&D, mais surtout les différentes unités d’affaires et unités
supports (ressources humaines, finance) devant être plus impliquées.
Comme l’illustre la figure 64, la mise en œuvre du cadre SAFe est officielle et de
nombreuses équipes s’en emparent dans les différents hubs de R&D dans le monde. Il est
notamment évoqué dans l’extrait que SAFe est un standard de travail, accentuant ainsi la
communication pour favoriser un cadre de travail qui peut potentiellement être mis en
place par les différents clients d’Amadeus.
293
Compte tenu de la portée fonctionnelle et de la complexité de nos produits, qui
impliquent généralement de gros efforts de développement, nous avons adopté une
méthodologie agile pour englober les activités de plusieurs équipes, souvent
réparties sur différents sites. Dans de nombreux cas, nous avons également impliqué
les représentants des clients dans le cycle agile. C’est pourquoi, depuis 2018, nous
avons adopté la méthodologie SAFe® (Scale Agile Framework), qui est la norme du
secteur. SAFe® favorise la collaboration et l’alignement d’un très grand nombre
d’équipes agiles tout au long du cycle de production, de l’étape des exigences du
produit à la livraison. Comme il s’agit d’une norme, elle facilite la collaboration avec
les clients et les partenaires technologiques.
Une décision est rapidement prise et aboutit au lancement d’un nouveau programme
de transformation en 2018, dont l’objectif est d’étendre le mode de fonctionnement
initialement mis en place au sein de la R&D auprès de tous les acteurs impliqués dans les
projets. Le moteur de cette séquence se caractérise de nouveau comme téléologique.
ee1. https://amadeus.com/fr/actualites/blog/covid-19-airlines-r-d-updatea
2.https://www.breakingtravelnews.com/focus/article/breaking-travel-news-investigates-amadeus-responds-to-post-
coronavirus-worl/
3. https://www.amadeus-hospitality.com/insight/scaled-agile-shapes-future-hospitality/
294
Référence Type
Séquence 3 et 4 Période Description de l’ingrédient Moteur
Ingrédient d’ingrédient
Réorganisation des 2015 R&D- Lancement du programme Agility Téléologique
équipes de la R&D BIFURCATION
2
R&D-IGRT-1.3 Création d’un modèle d’organisation Initiative
interne Agile Scaled Amadeus (ASAM)
R&D-IGRT- __Création de nouveau rôles : Back Initiative
1.3.1 Product Owner et le Tribe Product Owner
- Tribe Leader
R&D-IGRT- __Déploiement du modèle Initiative
1.3.2 organisationnel en tribus pour toute la
R&D par le biais de coaching et
sensibilisation des managers
R&D-IGRT- __Mise en place de formation autour du Initiative
1.3.3 modèle ASAM
PROJ-IGRT-2.3 Les projets mobilisent une multitude Frein Dialectique
d’acteurs impliqués les dépendances ne
sont pas traitées par le nouveau modèle
d’organisation
UA-PROJ-IGRT- Le nouveau mode d’organisation cible Frein
3.3 uniquement la R&D et n’inclut pas toute
la chaîne de valeur (des développeurs,
chef de projet et utilisateur final)
PROJ-IGRT-4.3 Les chefs de projets et les équipes R&D Frein
n’appliquent pas les mêmes pratiques de
pilotage
R&D-IGRT-5.3 Responsabilités divergentes dans les Frein
nouveaux rôles (Product Owner - Scrum
Master - Tribe Leader)
UA-PROJ-IGRT- Engendre la réticence des chefs de Frein
6.3 projets en raison de l’héritage
méthodologique
295
1.3 Synthèse du cas Amadeus
Le cas Amadeus s’illustre donc par 4 séquences représentées dans le tableau 48. L’un
des faits saillants du cas porte notamment sur l’arrivée d’un nouveau directeur de la R&D.
Il est notamment à l’initiative de trois programmes de transformation qui se mettent en
place successivement au cours des séquences 2 à 4. La dynamique de généralisation est
principalement déclenchée par sa volonté, mais aussi en raison de la lourdeur des projets.
Bien que les programmes soient composés d’initiatives planifiées pour généraliser
Scrum. Il figure que chaque séquence laisse place à son lot de difficultés. La R&D est donc
amenée à corriger successivement la manière dont elle envisage de généraliser la
méthode Scrum, caractérisant ainsi une dynamique de généralisation planifiée composée
de plusieurs cycles successifs.
296
synchronisation d’équipes Scrum est mise en place (ASAM). Or celle-ci n’implique pas
assez les différents acteurs des unités d’affaires d’Amadeus. Dans la quatrième séquence,
le cadre SAFe est notamment mis en place pour intégrer tous les acteurs impliqués dans
un produit (de la R&D, aux manageurs de projet jusqu’au client final).
297
2. Analyse du cas Banque de France
2.1 Présentation du contexte
2.1.1 Présentation du métier de la Banque de France
L'institution a été créée sous Napoléon Bonaparte avec une mission principale :
l'impression des billets de banque. Au fil du temps, ses missions se sont largement
étoffées. Aujourd'hui, la Banque de France (BDF) emploie 11 000 agents et ses missions
portent sur trois points clés de l’économie : la stratégie monétaire, la stabilité financière
et les services envers l’état, les entreprises et les particuliers.
Pour les activités liées à la stratégie financière, la BDF est finement liée à la Banque
Centrale Européenne (BCE) puisqu’elle met en œuvre les décisions prises par cette
dernière. La BCE fixe le taux de refinancement et les taux directeurs des banques, et c'est
la Banque de France qui va servir de guichet aux banques françaises pour venir emprunter
des liquidités contre des garanties.
La BDF investit aussi dans les marchés financiers. Quand par exemple la BCE lance un
programme de 2 000 milliards d'euros d'achats d'actifs financiers sur les marchés, c'est la
Banque de France qui va opérer pour la Banque Centrale Européenne sur les marchés.
C'est elle qui va acheter une partie des titres dans le cadre de ce programme pour les
revendre ensuite. Cette activité est par ailleurs devenue un gros levier de financement
pour la BDF.
D'une manière générale, les activités de la salle des marchés de la Banque de France
génèrent des profits conséquents. En plus des opérations monétaires, les activités de salle
des marchés comprennent deux autres pôles. Le premier pôle est dédié à ce que l'on
appelle la clientèle institutionnelle. La Banque de France compte environ une soixantaine
de clients qui sont en fait des banques centrales de pays émergents. Les traders de la
Banque de France placent une partie des réserves de change de ses clients sur les
marchés. Puis, les traders peuvent aussi intervenir sur le marché des devises à la demande
d'une banque centrale ou bien acheter de l'or pour son compte.
298
Au total, l'encours des dépôts des grands clients à la Banque de France dépasse
100 milliards d’euros sur lesquels l'institution va prélever une commission. Cette activité
s'est par ailleurs considérablement développée depuis la crise de 2008. En effet, les
grandes institutions ont préféré confier leurs fonds à des banques qui n'allaient pas faire
défaut, autrement dit de grandes banques centrales. La Banque de France est devenue l'un
de leurs prestataires préférés.
L'autre pôle de la salle des marchés de la Banque de France gère les réserves de change
de la France, mais fait aussi de la gestion pour son propre compte. Les traders constituent
des portefeuilles et placent de l'argent sur les marchés pour générer des rendements.
C'est une manière d'assurer la bonne santé financière de l'institution. Chaque année, la
Banque de France peut reverser une cagnotte de plusieurs milliards d'euros à l'État
français puisque l’état est le principal actionnaire de la BDFff.
Au niveau national elle assure, à travers ses équipes, la supervision du secteur financier
pour le compte de l’autorité de contrôle prudentiel et de résolution des banques privées.
Elle contrôle donc les banques et des assurances afin de protéger les déposants et
contribue à lutter contre le blanchiment des capitaux. Au niveau des moyens de paiement,
la Banque veille au bon fonctionnement et à la sécurité des différents systèmes de
paiement et participe à la prévention des risques systémiques liés à l’inflation ou à la
dévaluation de la monnaie.
Pour les particuliers, elle sensibilise les ménages dans la bonne gestion financièregg.
Elle facilite l’accès du public à des services bancaires adaptés et mène une action renforcée
pour lutter contre les situations de surendettement. Enfin, elle assure pour l’état la gestion
de ses comptes et elle organise les séances d’émission des titres de dette de l’État français
sur le marché. La BDF assure de plus la gestion du stock de réserve d’or de la France
composé de 2436 tonnes.
La Banque de France est donc un acteur clé dans le système européen de banques
centrales ainsi que de l’Eurosystème (composé de la Banque Centrale Européenne avec
les 19 banques centrales des pays de la zone euro). Le siège de la Banque de France est à
ffLa Banque de France est une personne morale de droit public, elle est soumise à l’ordonnance n°2015-
899 du 23 juillet 2015 relative aux marchés publics.
gg Cette activité s’illustre par exemple via la création du site mes questions d’argent :
https://www.mesquestionsdargent.fr/
299
Paris, mais l’organisation comporte 13 directions régionales en France avec
95 succursales départementales.
La DSI de la Banque de France offre aux différentes unités opérationnelles des services
de conseil, de conduite de projets et d'exploitation informatique. Avec plus de
1500 personnes, 600 applications et 10 projets européens en cours, la DSI mobilise ses
ressources au service de la Banque de France et de l’Eurosystème. La Banque intervient
par exemple en 2020 dans la création d’une offre cloud pour les autres banques centrales
européennes.
La DSI est organisée en trois directions (figure 66) : la DIT (Direction de l’Informatique
et des Télécommunications), la DIGIT (Direction de l’Organisation des Systèmes
d’Information et du digital) et DIPRO (Direction des Projets). Composée de neuf centres
de services, la Direction de l’informatique et des télécommunications (DIT) propose
essentiellement des services liés aux infrastructures techniques des différents systèmes
en place.
300
La DIGIT est l’entité en charge de la transformation digitale de la BDF. Elle accompagne
aussi les différents métiers dans le design du système d’information. Composée d’une
centaine de personnes, l’entité accompagne les différents métiers dans la digitalisation
des processus et la valorisation des données. La DIGIT est aussi chargée d’initier une
démarche d’innovation au sein de la Banque. C’est dans ce cadre qu’un Lab innovation a
été lancé en 2017. Sa mission est de mettre en relation les différentes activités de la
banque, les différents métiers avec des acteurs innovants pour devenir un acteur clé des
fintechs.
La DIGIT est subdivisée en cinq unités de services parmi lesquels le pôle ORGA. Celui-
ci est notamment dédié à l’appui des acteurs métiers dans les projets. Cette équipe
accompagne les chefs de projets utilisateurs en les conseillant sur toutes les phases des
projets (lancement de projet ; pratiques à mettre en place ; pilotage de projet ; recueil des
besoins). Les membres du pôle ORGA peuvent aussi intervenir en tant que chef de projet
utilisateur par intérim. D’autres missions portent sur des aspects de conduite du
changement liés aux projets et ses membres accompagnent les acteurs métiers dans des
démarches de performances sur la refonte des processus et d’organisation d’activités. Le
Pôle Orga peut être considéré comme une entité d’assistance à la maîtrise d’ouvrage des
projets puisque ses membres ont une connaissance assez fine des différents métiers de la
banque (AMOA).
La troisième entité jouant un rôle important dans les projets de la Banque est la DIPRO.
Il s’agit de l’entité en charge de développer les projets, regroupant principalement les
acteurs développant les différents projets SI de la Banque (Maîtrise d’œuvre des projets).
La DIPRO est divisée en 8 centres de services parmi lesquels il est possible de retrouver
un pôle assurant un support opérationnel en assistance aux équipes projet de la direction
(CENSEP). Ce service, constitué d’une quarantaine de personnes est chargé de fournir un
support opérationnel aux équipes projet dans la maîtrise de la gestion et de la réalisation
des projets ou des maintenances applicatives.
301
Figure 66 : Organisation de la DSI Banque de France
Une des particularités des centres de services de la Banque réside dans le fait qu’ils
développent l’essentiel de toutes les applications mises en place. Ils font très peu appel à
des éditeurs de logiciel pour la mise en place de solution préconstruites. Les équipes de
développement sont ainsi regroupées dans 6 services alignés sur les différentes
directions métiers.
Le cadre méthodologique Arpège a notamment été mis à jour en 2015 en intégrant des
principes provenant de la méthode Scrum. Or certaines équipes projet de la Banque
appliquaient déjà la méthode Scrum bien avant l’officialisation de ce nouveau cadre
méthodologique interne. Des travaux ont donc été réalisés pour intégrer cette dernière
aux référentiels internes (Arpège-Agile) et des coachs ont été missionnés pour
accompagner les équipes dans la mise en œuvre de ce nouveau cadre.
Depuis 2018, une décision importante a été prise au plus haut niveau de la Banque. En
effet selon la directrice de la DIPRO, « le gouverneur a notamment demandé que tous les
nouveaux projets au sein de la Banque doivent systématiquement se lancer en mode agile, et
doivent justifier pourquoi ils ne le seraient pas ». Cette prise de position est
particulièrement forte pour les projets et les maintenances de la DSI, en raison de
l’héritage méthodologique et des nombreux acteurs externes intervenant dans le projet.
Tout comme le cas précédent, nous proposons au cours des prochaines sections de
détailler les différentes séquences de généralisation du cas afin d’identifier les ingrédients
clés ayant conduit à la décision émise par le Gouverneur.
303
Afin de professionnaliser la manière de développer les applications, un premier cadre
méthodologique a été formalisé dans le but d’harmoniser les pratiques des différentes
équipes. Le cadre méthodologique était fortement inspiré de la méthode Merise :
« Le premier cadre méthodologique était un système qui était issu de Merise, donc
avec de la méthodologie relationnelle, des objets de relations, des transactions et c'est
selon ce modèle-là que nous on a décliné dans nos projets. On était vraiment sur un
cycle en V méthodologique merise. Pour autant on a toujours le droit à la banque de
France de customiser une méthode, elle est là pour nous aider » (selon la responsable
du CENSEP).
« Quand je suis arrivé en 2010 à la banque, on m’a donné la possibilité de suivre une
formation en maîtrise d’ouvrage, j’ai eu six semaines de formation. C'était un grand
engagement de la banque de mettre en place ces formations, car c’était un pilote pour la
MOA, ça existait déjà pour la MOE, mais pas pour la MOA, d’ailleurs il y a toujours eu cette
séparation entre MOE et MOA à la banque » (selon un membre du pôle ORGA).
Pour renforcer les équipes accompagnant les chefs de projets utilisateurs de la Banque,
une vague de recrutement et de formation est lancée afin de mieux couvrir les besoins
d’accompagnement des acteurs métier. Cette séparation est notamment censée diviser le
fonctionnement des projets afin que les développeurs puissent pleinement se concentrer
sur leurs tâches. Les individus de la MOA sont principalement dédiés à la compréhension
des différents métiers de la banque.
Cette première séquence faible en ingrédients nous permet tout de même d’identifier
la manière dont les projets sont menés à cette époque. Comme en témoigne l’extrait d’une
assistante chef de projet : « depuis les années 2000, nous travaillons en mode traditionnel
et je me suis formé sur le tas pour accompagner les projets », nous comprenons une certaine
organisation flottante des projets.
Ces premiers éléments de discours caractérisent bien des variations dans la manière
d’envisager le pilotage des projets au cours de cette séquence. Certaines méthodes sont
expérimentées, d’autres sont conservées comme la mise en place de la méthode
304
Mélodique qui traduit un mécanisme de sélection. Cette première tentative de
formalisation est néanmoins remise en question par les chefs de projet :
« Quand j’y étais il y a 5 ou 6 ans, c’était vraiment la mise en place d’une offre
standardisée du pilotage et de conduite de projet à la banque qui se basait sur une
précédente méthode mélodique, mais qui avait été mal vécue par tout le monde »
(selon un membre du CENSEP).
Référence Description de
Séquence 1 Période Type d'ingrédient Moteur
ingrédient l'ingrédient
Émergence de CONTEXTE Les projets sont menés avec une approche Evolutionniste
2006
la méthode méthodologique fortement inspirée de Merise
Scrum dans les PROJ-IGRT-1.1 La méthode Scrum est Initiative émergente
équipes de introduite selon la
développement volonté de certains
acteurs dans les projets
dès 2006
DSI-IGRT-2.1 Création d’un premier Initiative planifiée
cadre méthodologique
basé sur Merise pour
les développeurs
CONTEXTE Séparation des équipes MOE et MOA
CONTEXTE Mise en œuvre éparse des différentes
méthodologies
DSI-IGRT-3.1 Mise en place de Initiative planifiée
2010 formation pour l'accueil
d'équipes AMOA
Tableau 50 : Séquence d’émergence de la méthode Scrum dans les équipes de
développement
305
2.2.2 Séquence 2 : La formalisation de Scrum comme nouvelle approche
L’arrivée d’un nouveau directeur des systèmes d’information va initier une nouvelle
dynamique dans cette nouvelle séquence (DSI-IGRT-1.2). La bifurcation n’est pas tant liée
directement à des entraves dans le fonctionnement, mais plutôt à une volonté d’accentuer
la professionnalisation des projets au sein de la Banque.
Dans cette optique et afin de concurrencer les autres banques centrales sur la maturité
des projets, le département informatique a décidé en 2010 de suivre le cadre CMMI pour
illustrer son engagement d'amélioration continue. Un nouveau cadre méthodologique
inspiré par les exigences du CMMI et du PMBoK est mis en place en 2010 (DSI-IGRT-2.2).
Ce nouveau cadre nommé Arpège vient remplacer le précédent et débouche aussi sur une
politique de certification des chefs de projet.
« C'était un choix des équipes MOE, en 2011 ceux qui poussaient l'agilité c'était
plus le CENTER et dans mon projet c’étaient les équipes qui géraient la partie
Business Objects à la banque et ils avaient l'habitude de travailler comme ça. Je pense
que ça s'est fait naturellement parce qu’ils avaient toujours travaillé comme ça »
(selon un membre du pôle ORGA – consultante interne aux métiers).
Cette mise en œuvre émergente se poursuit aussi dans plusieurs projets comme l’évoque
une consultante interne intervenant dans plusieurs projets :
306
Le fonctionnement en itérations véhiculé dans la méthode Scrum fait d’ailleurs
émerger des difficultés lors de la phase de réalisation entre les différentes équipes de la
DSI (PROJ-IGRT-6.2) :
« Même les environnements de dev n'étaient pas prêts. Donc au début on a fait une
paire d'itérations. Les développeurs travaillaient en local sur leurs postes nous s'était
en local aussi […] ça a été assez compliqué. Je crois qu'il a fallu attendre la fin de la
première release pour voir les environnements de dev et de recettes opérationnels »
(selon un chef de projet informatique).
Par ailleurs la mise en œuvre de Scrum dans le cas particulier du projet SASTA permet
aussi de constater certains bénéfices. Les rituels de la méthode Scrum permettaient de
libérer la parole des différents acteurs impliqués et le mode itératif véhiculé par la
méthode Scrum permis de développer plus que ce qui était envisagé :
« Comme c’était une refonte d'applications, on nous avait imposés pour des raisons
techniques. On ne voulait pas avoir une application qui était moins bien que la
précédente on voulait avoir au moins à iso fonctionnalités donc on avait un périmètre
minimum sur lequel on ne pouvait pas négocier. […]. Au final on a quand même allégé
certaines règles de gestion de projet parce que l'agilité justement ça sert à ça, car on
est capable de faire de belles usines à gaz aussi. En parlant avec les développeurs on
voit qu'il y a moyen de récupérer d'être plus efficace et de simplifier et du coup on a
eu plus que notre périmètre de départ » (selon une consultante interne).
En revenant dans un niveau d’analyse plus macro au sujet de l’organisation des projets
dans la Banque, il figure que les nombreux acteurs intervenant dans les projets sont
intégrés dans une organisation matricielle. Comme l’illustre la figure 67, les flèches entre
les cases bleues montrent la multitude d’échanges et d’intervenants dans les projets et les
différents rattachements hiérarchiques des entités impliquées dans le projet.
Un point souvent évoqué dans les entretiens concerne les méfiances qu’il peut y avoir
entre les consultants internes et les centres de services de développement. Ces difficultés
de fonctionnement se matérialisent notamment par un manque de transparence au cours
des projets (UA-IGRT-7.2) :
Cette méfiance s’exprime aussi entre les différents métiers et la DSI de façon générale.
Certains acteurs évoquent le manque d’un socle méthodologique commun entre les unités
métier et la DSI :
307
« La DSI n'accorde pas aux personnes qui l'entourent ce qu'il faut savoir, c'est qu'à
la banque il y a les métiers, et les métiers ont une très grande méfiance vis-à-vis de
l'OI » (selon un assistant-chef de projet interne).
Par ailleurs, dans les centres de services au sein de la DIPRO, le bureau des projetshh
interne (nommé CENSEP), se dotent d’un outil permettant d’auditer la maitrise des
projets. Le PMO prend ainsi plus d’ampleur dans le suivi des projets et devient un organe
de régulation et d’homogénéisation des processus de gestion de projet (DSI-IGRT-8.2).
Néanmoins les évaluations des projets créent une lourdeur dans le fonctionnement des
projets :
« Alors je pense qu’a un moment on a fait trop, et avant même que j’arrive, ça a été
vécu comme quelque chose qui s’imposait avec une vision qui était trop proche
d’imposer des méthodes et des outils plutôt que de promouvoir l’esprit. Et tant que
PMO nous devons faire respecter certains principes mais l’essentiel pour nous c’est
que le planning existe, mais on ne va pas toujours vérifier sa fiabilité. » (Selon un
membre du CENSEP)
« Je pense que même Arpège ça a été mal vécu parce que derrière, […] les gens
voient peut-être le CENSEP, et moi-même actuellement, participant à cette
308
problématique-là, ils voient ça comme une contrainte qui s’ajoute » (selon un
membre du CENSEP).
« Je ne parle même pas justement de ces audits qui étaient liés à ces éléments il y
a eu d'ailleurs un radar des projets. Le radar, ça a été une horreur, car c’était
simplement un outil d’audit pour faire émerger les problèmes » (selon un membre
du pôle ORGA).
Ces éléments de discours nous permettent de préciser que le contexte s’illustre par une
forte culture de maîtrise des projets. Cet aspect se matérialise par de nombreuses
instances de suivi des projets et une sensibilisation constante à la maturité des processus
de gestion de projet. Or cette culture influe sur des dérives de fonctionnement :
Afin d’améliorer cette communication, un réseau social est mis en place afin de créer
une communauté des chefs de projet (DSI-IGRT-9.2). Néanmoins, les groupes de chefs de
projet utilisateurs et chefs de projet informatique sont séparés montrant ainsi la scission
qu’il peut y avoir entre ces équipes.
« Ça fait 3 ans que nous CENSEP on essaye d'installer l'agilité. Sauf que certaines
équipes l'avaient installé bien avant nous, c'est-à-dire que nous on était à fond dans
arpège. La seule chose qu'on savait faire c'était de décliner de l'arpège. Alors qu'il y
avait des équipes qui depuis pas mal de temps avaient conduit leurs projets en agilité.
Donc il y avait tout le programme MIDEF qui a été construit comme ça […], idem pour
un besoin de collecte de statistiques prudentielles et monétaires européennes ils ont
conduit le projet en méthode agile au service de développement et études statistiques,
et ils ont refait la première application en big data, l'application muse, pareil en
agilité » (selon la responsable du CENSEP).
« Les premières expériences que moi j'ai pu voir à la banque, car j'ai 5 ans
d'expérience à la banque c'était en 2014 j'avais fait ma première enquête pour voir qui
faisait de l'agilité et j'avais par exemple récupéré 5 ou 6 projets qui en cachette
309
faisaient de l'agilité […] Les projets mettaient en œuvre quelques pratiques, mais il n'y
avait pas d'agilité complète, c'est à partir de là qu'on a pu concevoir en 2015 le
référentiel » (selon la directrice de la DIPRO).
Comme l’illustre le passage précédent, la mise en œuvre de Scrum n’est pas harmonisée
et mène dans certains cas à des projets utilisant différentes pratiques (DSI-IGRT-11.2).
C’est avec l’idée d’harmoniser un cadre de travail plus homogène et tenant compte de
l’héritage méthodologique que des coachs agiles sont recrutés au sein du PMO de la DSI
(DSI-IGRT-12.2).
« Lorsque je suis arrivé, c'était un peu le désert, on lisait sur le site dédié à la
méthode alors que peu de monde consulte, mais on lisait sur ce site que la méthode
pratiquée à la banque était Scrum, ce qui n'est pas praticable par exemple avec des
centres de services déportés donc chacun y allait de son initiative personnelle avec
plus ou moins de succès » (selon un coach agile).
« Les gens n'ont adopté que ce qui les intéressait et ont essayé de faire des récits
utilisateurs qui n'en étaient pas. "En tant que, je veux que", ok d'accord, mais pas de
critères d'acceptation. Pourquoi faire des meetings quotidiens ? Ça ne sert à rien on
va en faire un de temps en temps. Le management visuel on ne sait pas le faire, mais
bon on va coller des Post-its au mur. C'était de la prose faite par monsieur Jourdain,
mais sans le savoir. Ça n'était pas rationnel, en arrivant ça n'était pas rassurant, et
ça aurait pu mener des projets vraiment à l'échec » (selon un coach agile).
Dans les projets, ce point s’illustre notamment par la faible implication des utilisateurs
finaux (normalement privilégié dans les méthodes agiles). Ce point est bien mentionné
dans la figure 68. D’autre part, la conception se traduit par un cycle « semi-itératif » où les
développeurs délivrent les avancées du développement dans des itérations. Or comme ce
sont les assistants-chefs de projet qui effectuent les tests finaux des applications, ces
derniers ne sont pas en mesure de s’aligner dans certains projets :
« Alors en fait on a connu des hauts et des bas on a fait un peu de Scrum à un
moment donné. Ça n'avait pas très bien marché notamment. C'était très poussé de
côté de la hiérarchie de la DIPRO et la MOA a un peu subi ce mode de fonctionnement.
Ils se sont retrouvés bombardés de choses à tester toutes les trois semaines […] ils se
sont retrouvés avec des périmètres livrés très souvent, mais ils ne maitrisaient pas les
tests. Donc ils ont dit stop et préféraient des livraisons par lotissement » (selon un
chef de projet informatique).
Au cours du premier semestre 2015, une étude en interne est menée pour mesurer le
niveau de mise en œuvre de Scrum et des différentes méthodes agiles. Il figure dans les
constats (figure 68) que tous les projets mettent en place des pratiques agiles de façon
310
totalement divergente (DSI-IGRT-13.2). Il s’agit dans bien des cas de mises en œuvre
partielles des rituels autour de la méthode Scrum.
Pour combler ces différentes entraves, les coachs agiles ont rapidement initié des
travaux pour la constitution d’un cadre méthodologique. L’idée était d’intégrer les
principes de fonctionnement de la méthode Scrum (ainsi que d’autres pratiques clés
d’autres méthodes) adapté au cadre méthodologique initialement mis en place. Des
expérimentations sont ainsi faites au cours de l’année 2015 au sein d’un projet
expérimentant aussi des infrastructures cloud pour la première fois au sein de la Banque
(DSI-IGRT-13.2).
Dans un deuxième temps, afin d’aider les équipes sur une approche méthodologique à
mettre en place dans les nouveaux projets, le CENSEP met en place un diagnostic
systématique d'avant-projet pour orienter les individus dans la méthode la plus adaptée.
Ce premier contact permet d’une certaine manière de favoriser une mise en relation
précoce des membres d’un projet avec l’équipe de coachs agiles interne. L’idée étant,
311
d’apporter un appui tout au long des projets pour aider les équipes à être plus efficiente
(DSI-IGRT-16.2).
Compte tenu des nombreuses initiatives, freins et actants identifiés au cours de cette
séquence (tableau 51), nous qualifions la trajectoire de cette séquence d’évolutionniste.
En effet, les différents projets et la DSI font preuve de tâtonnement dans les méthodes à
mettre en œuvre. La lourdeur du cadre méthodologique Arpège et les entraves liées à la
structuration de l’organisation amplifient d’autant plus le fait que les projets essayent
d’appliquer des approches divergentes.
Référence Type
Séquence 2 Période Description de l'ingrédient Moteur
ingrédient d'ingrédient
Montée en DSI-IGRT-1.2 Nomination d'un nouveau Actant Évolutionniste
maturité des 2011 directeur des systèmes
projets et d'information
mise en DSI-IGRT-2.2 Remplacement et création du Initiative
œuvre de cadre méthodologique basé sur planifiée
Scrum Merise par une méthode inspiré
informelle des bonnes pratiques de gestion
de projet
DSI-IGRT-3.2 Évaluation CMMI est lancée pour Initiative
évaluer la maturité des projets planifiée
312
UA-IGRT-7.2 Organisation matricielle des Frein
projets avec l'implication
2013 d'acteurs dépendants de
nombreux services internes et
externes
DSI-IGRT-8.2 Le PMO interne devient un Frein
organe de régulation des projets
en interne pour faire appliquer les
bonnes pratiques
DSI-IGRT-9.2 Création d'un réseau social Initiative
interne avec une communauté de
gestion de projet
DSI-IGRT-10.2 Évaluation CMMI - niveau 2 Initiative
2014 planifiée
DSI-IGRT-11.2 La mise en œuvre de Scrum dans Frein
les projets n'est pas harmonisée
DSI-IGRT-12.2 Recrutement de coachs agiles Actant
internes pour la préparation d'un
nouveau cadre méthodologique
DSI-IGRT-13.2 Lancement d'une étude portant Initiative
sur le degré de contextualisation
interne de Scrum
PROJ-IGRT-14.2 Un nouveau cadre Initiative
méthodologique est en cours
d'expérimentation dans un
nouveau projet misant sur le
cloud
DSI-IGRT-15.2 Le Directeur de la DSI pousse vers Décision
la mise en œuvre des projets
agiles
DSI-IGRT-16.2 Mise en place d'un diagnostic Initiative
d'avant-projet pour orienter le planifiée
projet sur l'approche la plus
adaptée (Agile ou séquentielle)
UA-IGRT-17.2 Arrivée d'un nouveau Gouverneur Actant
2015 au sein de la banque
Tableau 51 : Synthèse de la séquence 2 du cas Banque de France
313
2.2.3 Séquence 3 : officialisation de la nouvelle méthode
Il est important de préciser que la méthode Arpège-Agile est basée essentiellement sur
le mode de fonctionnement de la méthode Scrum. Au niveau des projets, le cadre est
rapidement mis en œuvre dans ces projets critiques pour la banque. C’est le cas par
exemple du projet de création du site mes questions d’argent. Demandé par le ministère
de l’Économie avec un délai très court pour la création de celui-ci, un chef de projet
utilisateur précise :
« C'était un site très ambitieux, mais avec des contraintes très fortes qui
provenaient de l’externe, on ne pouvait pas bouger la date de mise en production. Et
là si on n'avait pas fait en agilité on ne sortait pas en temps et en heure. Et là on avait
la chef de projet qui n'avait jamais fait de projet informatique du tout qui était
purement métier et donc ils ont fait appel à notre pôle parce qu'elle était toute seule
dans l'équipe projet d'accord. J’ai donc été Product Owner proxi » (selon une
consultante interne).
314
Les bénéfices liés à la mise en œuvre de la nouvelle approche sont donc bien perçus, et
dans ce cadre les consultants internes du pôle ORGA jouent un rôle d’assistant Product
Owner. Les bénéfices constatés dans les projets nous ont été remontés à plusieurs autres
reprises dans des projets internes (DSI-IGRT-2.3). Nous avons pu identifier notamment
4 projets dont les acteurs mesuraient l’intérêt de collaborer avec le nouveau cadre
méthodologique.
Dans la réalité, la nomination de ce nouvel acteur n’a pas de grande ampleur au niveau
de l’organisation. En effet, il s’agit principalement d’un changement de nom de poste et
d’entité puisque la direction DIGIT existait déjà avant 2016 est avait quasiment les mêmes
fonctions. Elle détient en 2016 plus de moyens et de mandat pour lancer des initiatives
innovantes.
En 2017, la DSI est justement réévaluée dans le cadre de l’audit CMMI (toujours au
niveau 2). Il est notamment constaté lors de cette nouvelle évaluation que le cadre
méthodologique Arpège-Agile prend plus d’ampleur dans les projets (DSI-IGRT-4.3). Une
étude en interne est d’ailleurs menée afin d’avoir plus de matière de comparaison. Il est
apparu clairement que les projets appliquant le cadre Arpège agile étaient plus
performants. Par performance les acteurs internes à la Banque évoquent notamment que
315
les applications délivrées avaient moins d’incidents (moins de bugs) et une meilleure
satisfaction des utilisateurs finaux (DSI-IGRT-5.3).
Toujours au cours de l’année 2017, une nouvelle directrice des projets est nommée, et
les résultats de la précédente étude lui sont rapidement évoqués. À son tour, lors d’un
comité de direction de la Banque, la nouvelle directrice présenta les résultats au nouveau
gouverneur de la Banque.
« Dans les idées de simplification, j'ai parlé de l'agilité dans les projets informatiques
au Gouverneur. Et ça l'a intéressé, car il en avait entendu parler à la BNP, il a dit "mais
ça, ce n'est pas qu'une histoire d'informaticien, ça touche les métiers, nos MOA, et d'autres
choses et du coup je veux que vous m'expliquiez ce que ça apporte pour l'entreprise". C'est
ce que l'on a fait au mois de mai et là il a dit "bon coup, on va déployer ça, on y va, on va
vers ça, mais." il a contredit en disant que ça ne se fait pas du jour au lendemain qu'il y
avait différents niveaux de maturité et il nous a fait faire une feuille de route » (selon la
directrice des projets – DIPRO).
316
Pour favoriser la contextualisation interne de la méthode Arpège-Agile, des
ambassadeurs de la méthode sont nommés afin qu’ils puissent partager des retours
d’expériences dans différents projets (DSI-IGRT-11.3) :
« Il y avait une belle idée qui avait été lancée il y a deux ans déjà. On n'était pas
obligé de passer à 100% en mode agile ce n'était pas encore à grande échelle, mais
on voulait développer l'agilité dans les projets et le CENSEP avait décidé de mettre en
place des ambassadeurs pour promouvoir l'agilité et on se réunissait une fois par
mois pour échanger sur ce qu’il se passait dans les projets » (selon une consultante
interne).
317
pour la DSI puisqu’elle s’aligne sur cette initiative globale pour véhiculer de nouveaux
messages auprès des entités métiers en lien avec les projets.
La dernière initiative de cette séquence est plutôt émergente au sein d’un projet. Dans
le cadre de la modernisation des postes de travail et notamment au sein du projet ayant
pour but de conduire la mise à jour des postes de travail informatiques vers le système
d’exploitation Windows 10, une organisation inspirée du cadre méthodologique SAFe est
mise en place.
« Notre organisation ressemble à SAFe. Je n'ai pas voulu montrer ça, mais on a
plusieurs équipes réunies dans ce projet pour assurer tout ce qu’il faut, l’équipe est
coupée en périmètre. Donc on a une équipe expérience utilisateur, on a un découpage
infrastructure, et des acteurs pour la conduite du changement recette de corde un
chantier applicatif. Et puis après des outils connexes. Et aussi une partie importante
du projet qui va gérer les propositions on a découpé tout ça en chantier successif avec
un responsable de chantier qui porte la structure la coordination et la mise en œuvre
de toutes les actions […] pour la majorité des équipes de la team oui ce mode de
fonctionnement est complètement nouveau » (selon un Product Owner du projet).
Ensuite, l’héritage méthodologique et les nombreux comités de suivi des projets imposent
à des chefs de projet d’effectuer un double travail dans la formalisation des documents
projets (PROJ-IGRT-17.3) :
« Nous étions agile avec le métier, donc on essayait de créer un backlog, etc.,
mais comme notre projet a été évalué comme non agile par le CENSEP, il a fallu
maintenir à la fois un planning classique, un cahier des charges classiques avec un
backlog, il a fallu mixer tout ça, ce que je trouve finalement totalement
incohérent » (selon une assistante-chef de projet utilisateur).
Au niveau des entités métiers, les acteurs sont très peu sensibilisés au mode de
fonctionnement Scrum. Comme les chefs de projets utilisateurs ne sont pas dédiés à plein
temps dans les projets, il figure que ce manque de disponibilité est considéré comme
incompatible avec un mode de fonctionnement agile selon un assistant chef de projet (UA-
IGRT-18.3) :
318
« Je pense qu’il y a un frein énorme c'est que la plupart des maîtrises d'ouvrage, des
métiers, passent leur temps à conserver un emploi et c'est parce qu'ils sont chargés
que ça va être l'un des freins, ils n’ont pas le temps » (selon un coach agile).
Ce frein s’explique aussi en raison du fait que les acteurs métiers impliqués dans les
projets dépendent d’une autre structure fonctionnelle, donc d’un autre responsable
hiérarchique. À cet effet de nombreux acteurs projets évoquent la faible sensibilisation
des responsables d’entités métier (UA-IGRT-19.3).
D’autres unités freinent aussi le déploiement de la méthode Scrum, car nous l’avons
évoqué implicitement à plusieurs reprises. Nous avons systématiquement considéré la
méthode Arpège-Agile comme Scrum et vice versa. Toute la terminologie au sein du cadre
méthodologique reprend quasiment tous les aspects de la méthode Scrum. Néanmoins le
département des ressources humaines a imposé aux créateurs de la méthode d’utiliser
une terminologie française. Ce point est notamment expliqué en raison du fait que le poste
de chef de projet au sein de la banque est considéré comme un certain aboutissement. Ce
frein à notamment pour incidence de ne pas faire sentir aux différentes équipes un réel
changement de fonctionnement (DSI-IGRT-20.3).
Synthèse de la séquence
Deuxièmement, les évaluations CMMI et une étude interne font ressortir les effets
positifs de la nouvelle méthode. Sur cette base, la nouvelle directrice des projets présente
ces résultats au nouveau gouverneur qui décide à son tour de systématiser la nouvelle
méthode à tous les nouveaux projets et maintenances. L’objectif est fixé, il donne ainsi
mandat à la directrice des projets informatiques pour diriger cette transformation et faire
une proposition de plan de mise en œuvre.
319
Cette séquence révèle donc par ailleurs l’importance d’une succession de décisions
prises à différents niveaux de la Banque (tableau 52). Les différentes initiatives au début
de la séquence permettent de caractériser un moteur principalement téléologique. Malgré
l’officialisation de la méthode et l’adaptation de celle-ci au contexte de la BDF, de
nombreux problèmes structurels persistent et ne favorise pas la bonne mise en œuvre de
la méthode à l’image des conflits entre différentes entités en lien dans les projets. C’est
pourquoi nous qualifions la deuxième partie de cette séquence d’un moteur dialectique
en raison des entraves persistantes entre les différentes entités impliquées dans les
projets.
Référence Type
Séquence 3 Période Description de l'ingrédient Moteur
ingrédient d'ingrédient
Officialisation BIFURCATION Officialisation du nouveau cadre méthodologique téléologique
et 2016 inspiré de la méthode Scrum
déploiement DSI-IGRT-1.3 Mise en place de formations sur le Initiative
de la méthode nouveau cadre méthodologique
Scrum au sein
des nouveaux PROJ-IGRT- Un certain nombre de projets Initiative
projets 2.3 menés dans l'urgence et utilisant
Arpège agile se traduisent par des
succès
DSI-IGRT-3.3 Plan stratégique Ambition 2020 - Initiative
avec une stratégie fortement
orientée sur transformation digitale
de la banque
DSI-IGRT-4.3 Évaluation CMMI 2017 - niveau 2 Initiative
2017
DSI-IGRT-5.3 Étude des projets - les projets Initiative
menés avec l'approche agile interne
ont moins d'anomalies lors de la
livraison
320
DSI-IGRT- Un nouveau responsable du PMO Actant
12.3 est nommé
DSI-IGRT- Un chantier de réorganisation du Initiative
13.3 PMO débute è Mutualisation des planifiée
ressources et accentuations de
l'accompagnement proposé autour
de la méthode agile interne
US-IGRT-14.3 Lancement d'un grand chantier de Initiative
renouvellement du management au
sein de la Banque
PROJ-IGRT- Lancement d'un projet de Initiative
15.3 modernisation des postes de travail émergente
- prémices de SAFe et collaboration
en mode plateau
DSI-IGRT- Manque d'accompagnement dans Frein Dialectique
16.3 les projets - faible nombre de
coachs
PROJ-IGRT- Dédoublage des tâches entre le Frein
17.3 cadre méthodologique
UA-IGRT-18.3 IGRT - FREIN - les métiers ne sont Frein
pas à 100% dédiés aux projets pour
bien fonctionner en agile
UA-IGRT-19.3 Les managers des différentes unités Frein
d'affaires ne sont pas sensibilités à
l'agilité et connaissent peu les
prérequis
US-IGRT-20.3 Adoption partielle de la Frein
terminologie terminologie Scrum -
Frein RH car le Chef de projet est
considéré comme un aboutissement
- les perspectives de carrière à vie
sont fortes
DSI-IGRT- Présentation d'une roadmap de Actant
2018 21.3 généralisation de l'agilité en CODIR
par la directrice des projets
Tableau 52 : Synthèse de la séquence 3 du cas Banque de France
321
2.2.4 Séquence 4 : La mise en place d’un plan de généralisation
La dernière séquence du cas Banque de France est finement liée au dernier événement
de la séquence 3. C’est lors d’une réunion au mois de septembre 2018 qu’un plan de
généralisation détaillé est présenté. Celui-ci est d’ailleurs validé et prend effet
immédiatement (DSI-IGRT1.4). Cet événement matérialise ainsi un changement dans le
processus de généralisation puisque des objectifs sont posés et des dispositifs sont à
mettre en place. Les événements ayant conduit à la bifurcation ne sont pas
nécessairement les freins comme dans les précédentes séquences, mais se caractérisent
par la succession de décisions d’acteurs à différents niveaux hiérarchiques.
« Ce qui est intéressant c’est que ça va se faire normalement dans une démarche
qui n’est plus seulement de IT ou des SI, donc DSI et DIPRO, c’est dans un mode
d’entreprise. Et dans un mode d’entreprise ce qui est intéressant, ça devient un
paradigme qui s’impose à tout le monde, c’est là où le gouverneur va forcer à ce que
tout le monde y aille. »
La feuille de route présentée en figure 17 précise les cinq sujets clés portés par la
direction des projets. Nous ne détaillerons pas tous les aspects de celui-ci, mais nous
proposons néanmoins d’illustrer les éléments les plus importants dans le contexte de la
Banque. D’une part le sujet lié à l’organisation traitera des responsabilités dans les
nouveaux rôles véhiculés par la généralisation de la méthode Scrum. Nous verrons par
ailleurs que la tendance porte aussi sur la mise en œuvre du cadre SAFe.
322
Comme la communication et le fonctionnement en équipe avec les individus réunis
autour d’un même lieu sont préconisés par de nombreuses méthodes agiles, il est envisagé
une évolution des locaux. Notamment plus d’open-spaces pour favoriser des échanges et
des rassemblements d’équipes.
Le plan s’accompagne aussi d’un volet technique important. Ceci avait précédemment
été évoqué dans la vision du nouveau responsable du PMO. L’objectif est de créer des
architectures techniques permettant de livrer les projets par du déploiement continu.
Dans ce cadre, il est envisagé une mise en œuvre de nouveaux outils permettant
d’automatiser certaines tâches dans le processus de conception des applications. L’idée
est notamment de fluidifier les différentes étapes de conception en favorisant un mode de
iiLe Beyond Budgeting est une approche proposée par Jeremy Hope et Robin Fraser (2003) dont le but
est de casser la rigidité des budgets annuels. L’idée centrale est de structurer les budgets en fonction de
probabilités et de priorités. Après l'approbation du budget, l'état réel des finances est régulièrement
examiné et analysé, et si les recettes atteignent un certain niveau (ou probabilité), le niveau correspondant
des dépenses est approuvé.
323
fonctionnement itératif et incrémental permettant de faire évoluer les applications le plus
rapidement possible.
324
Au-delà des actions devant être menées par les responsables des centres de services,
le coaching est mis en avant pour accompagner les différentes équipes de la Banque.
L’idée est ensuite de favoriser du compagnonnage et de la transmission par pairs entre
individus. La figure 72 illustre aussi la volonté de la Banque d’accompagner les différents
acteurs projet vers des certification (PMI-ACP).
« Comme la politique et de mettre en œuvre l'agilité dans les projets, on fait appel
de manière un peu contrainte et forcée alors qu'avant seuls ceux qui étaient
volontairement partants pour faire de l'agilité pouvait faire appel à nous » (selon un
coach agile).
325
Au-delà des initiatives lancées autour du plan de généralisation, cette séquence se
traduit aussi par de nombreux freins n’ayant pas nécessairement encore été traités par
les actions des différents directeurs de la banque. Tout d’abord certains services de la DSI
sont en concurrence selon certains acteurs (DSI-IGRT-8.4) :
« Et c'est vrai que c'est le cas pour l'agilité par exemple certains veulent prendre
le lead dans la manière dont l'agilité est portée au sein de nombreuses formations
agiles. […] Ce n'est pas la peine d'aller à leurs formations et de perdre des jours alors
que dans mon service nous accompagnons les utilisateurs là-dessus » (selon un
consultant interne).
« La majorité des réflexions vont devoir porter sur les maintenances, ce qui peut
poser des difficultés puisque les gens vont plutôt travailler jusqu'à présent en mode
classique et là on leur demande de faire de l'agilité avec éventuellement des
fournisseurs dont les contrats sont classiques » (selon un coach agile interne).
326
Figure 74 : communication autour de la mise en œuvre de la méthode SAFe
D’autre part, de nombreux freins persistent au cours de cette séquence, révélant ainsi
que le plan de généralisation posé n’inclut pas encore de manière précise un état
organisationnel cible vers lequel tendre. C’est pourquoi nous proposons de qualifier la
seconde partie de la séquence d’un moteur dialectique.
327
Référence Type
Séquence 4 Période Description de l'ingrédient Moteur
ingrédient d'ingrédient
La mise en place 2018 DSI-IGRT- Présentation du plan de Décision Téléologique
d’un plan de 1.4 transformation et validation du
généralisation Gouverneur sur le lancement
de celui-ci
DSI-IGRT- Les nouveaux services du PMO Initiative
2.4 sont proposés en intégrant un
centre d'expertise d'agilité
DSI-IGRT- Le cadre méthodologique est Initiative
3.4 modifié peu à peu pour être
remplacé par une approche
inspirée de Scrum, SAFe et
Spotify
DSI-IGRT- Formation de 13 acteurs Initiative
4.4 internes sur SAFe SPC planifiée
DSI-IGRT- Le coaching et les formations se Initiative
5.4 systématisent dans les projets
et les applications en
maintenance
DSI-IGRT- Communication de la directrice Initiative
6.4 des projets dans les
événements de la communauté
de gestion de projet
DSI-IGRT- Lancement des vitrines des Initiative
7.4 projets sous le signe des projets
agiles
2019 DSI-IGRT- Concurrence entre services Frein
8.4 internes de la DSI
DSI-IGRT- Contractualisation au niveau Frein
9.4 des maintenances non
adaptées
DSI-IGRT- Multitude d'acteurs dans les Frein
10.4 projets et manque de
disponibilité des acteurs
métiers
DSI-IGRT- Le service de coaching se révèle Frein
11.4 être surchargé par le nombre
d'acteurs à accompagner
PROJ- Lancement d'un grand projet Initiative
IGRT-12.4 de cloud misant sur le cadre
SAFe
2020
DSI-IGRT- La DSI devient une direction Contexte
13.4 générale et n'est plus assimilée
à un sous service
328
2.3 Synthèse du cas Banque de France
Nous avons pu identifier au total 4 séquences dans le cas de la DSI de la Banque de
France (tableau 54). La méthode Scrum est dans ce cas pendant longtemps mise en place
de façon émergente dans les équipes de développement (séquence 1 et 2). C’est
notamment en raison du manque d’harmonisation des méthodes de travail dans les
projets que le directeur de la DSI 1 impulse son officialisation. Ce qui aboutit notamment
à la création d’une méthode hybride entre le cycle l’approche séquentielle initialement en
œuvre et la méthode Scrum.
329
Dans le cas de la Banque de France, les différentes approches mises en œuvre pour
compléter la méthode Scrum traduisent une pratique d’innovation managériale
contextuelle (tableau 55). En effet, toutes les méthodes sont adoptées « sur étagère » et
adaptées au contexte de l’organisation. Une pratique potentiellement innovante concerne
la volonté de la DSI de mettre une organisation des équipes permettant la livraison
continue des applications (continuous delivery). Ce qui nécessite en amont de mettre en
place de nouvelles technologies (comme le cloud computing) permettant de mettre en
oeuvre ce mode de fonctionnement. Il semblerait enfin que la généralisation de la
méthode Scrum contribuerait ainsi à favoriser la recherche d’innovations managériales
en ce qui concerne par exemple l’attribution des budgets pour les projets et la
contractualisation des acteurs externes sur des cycles plus courts.
330
3. Analyse du cas GRDF
3.1 Présentation du contexte
Gaz Réseau Distribution France, plus connue sous le nom de GRDF est le principal
distributeur de gaz naturel en France. Créée en 2008 à la suite de l’ouverture du marché
de l’électricité et du gaz naturel à la concurrence, l’entreprise est une filiale d’Engie, 3e
plus grand groupe mondial dans le secteur de l’énergie.
Dans le cadre de ses différentes missions, GRDF interagit notamment avec plusieurs
acteurs clés. D’une part les clients finaux pour les abonnements, les collectivités locales
pour l’acheminement et la distribution du gaz, les pouvoirs publics, les fournisseurs de
gaz naturel et la commission de régulation de l’énergie (CRE). Cette dernière est chargée
de veiller au fonctionnement du marché de l’énergie et d’arbitrer les différends entre les
utilisateurs et les divers exploitants du réseau.
L’entreprise est composée de plus de 12 000 collaborateurs répartis entre son siège à
Paris et les régions. L’entreprise compte 5 métiers clés principalement répartis en région.
Les conseillers du service client : accueillent et accompagnent les clients pour leur faciliter
l’accès au réseau. Les développeurs du réseau : assurent la promotion de l’énergie gaz
naturel et optimisent le développement du réseau pour le bénéfice des clients.
Les équipes sécurité industrielles assurent les dépannages d’urgence pour tous les
clients en France. Ils interviennent en appui des techniciens d’intervention clientèle qui
331
réalisent les interventions techniques afin de raccorder les clients au réseau de gaz. Ces
derniers mettent en service les installations de gaz et assurent le relevé des compteurs
pour le compte des fournisseurs. Enfin, les équipes territoriales accompagnent les
collectivités territoriales et les décideurs locaux dans la mise en place d’infrastructures
dédiées à l’acheminement.
Le second enjeu majeur est directement en lien avec la loi relative à la transition
énergétique pour la croissance vertejj de 2015. Cette directive fixe aux fournisseurs
d’énergie de favoriser les énergies renouvelables. Dans le cas de GRDF la loi fixe 10% de
gaz renouvelables, notamment le biométhane, dans les consommations à l’horizon 2030.
La Programmation Pluriannuelle de l’Energie qui découle de cette loi fixe une trajectoire
pour le mix énergétique. GRDF est dans cette optique confrontée à de nombreux enjeux
dans le pilotage de ses activités.
Au niveau des systèmes d’information, comme GRDF hérite d’une organisation liée à
la précédente fraction avec EDF. L’entreprise est confrontée à l’évolution de ses différents
systèmes d'information. La DSI est lancée dans des projets de renouvellement des SI
historiques pour prendre en compte la réorganisation du service commun partagé avec
Enedis. Le projet « SI transformant » correspond aux ajustements nécessaires à la mise en
concurrence des prestations et licences IT, aujourd’hui confiées à GDF SUEZ IT.
La DSI de GRDF est plutôt jeune et se révèle être composée d’un effectif d’interne
relativement faible (300 acteurs). L’expertise des collaborateurs de la DSI propose des
solutions informatiques et délivre des outils pour accompagner et soutenir les utilisateurs
dans leurs activités au travers des programmes stratégiques et d’initiatives transverses
entre les différents domaines. La DSI contribue à la transformation de l’entreprise en
investissant chaque année 20 millions d’euros dans les différents systèmes d’information.
Cette loi fixe les grands objectifs d’un nouveau modèle énergétique français, dans le cadre mondial et
jj
européen.
332
La DSI répond à ses enjeux tout en participant à la performance industrielle et à la
sécurité du réseau, au renforcement de la relation avec les clients et à la conquête de
nouveau, les collectivités locales et les professionnels de la filière gaz. La DSI de GRDF est
composée de 6 domaines clés et de 5 domaines transverses présentés en figure 20. Tous
les domaines s’alignent sur le même niveau hiérarchique et un état-major composé du
directeur des systèmes d’information, d’un responsable de la communication et de deux
adjoints au directeur orientent la stratégie SI du groupe.
Le domaine SI relations clientèles porte des systèmes liés aux clients de GRDF. Il
collabore étroitement avec la Direction Relations Clients ainsi qu’avec les nombreuses
directions régionales. Cette division assure le pilotage des projets et du maintien des
applications de gestion de la relation client. Ce domaine assure de plus l’hébergement d’un
pôle de récolte, traitement et analyse de données. Il s’agit d’une activité transverse à la
DSI et a pour objet la mise à disposition d’un socle de données aux différents acteurs de la
DSI.
Le domaine Support et Territoires est responsable des activités liées à la finance ; aux
ressources humaines ; aux achats ; et à la relation avec les clients. L’entité SI et Réseau est
responsable des activités liées à la cartographie du réseau de gaz des clients. Les membres
de cette division collaborent étroitement avec la Direction Technique Industrielle ainsi
que les directions régionales pour assurer le développement et le déploiement d’un
portefeuille de solutions cartographiques.
333
Le dernier domaine principal a pour mission de mettre à disposition cinq systèmes
dédiés à la récolte des données des comptes. Le domaine SI Programme opérateur de
comptage (POC) conduit des projets structurants pour l’entreprise.
La mise en œuvre de la méthode Scrum au sein de la DSI de GRDF suit une trajectoire
assez différente dans ce cas. Nous présenterons au cours des deux séquences du cas la
manière dont la création d’une cellule dédiée au développement de projets en mode agile
a été le moteur de la généralisation de Scrum en interne.
334
3.2 Analyse des séquences de généralisation
Si le cas s’illustre par deux séquences, un certain nombre d’ingrédients sont communs
aux cas précédemment évoqués, comme l’arrivée d’une nouvelle directrice des systèmes
d’information impulsant une nouvelle donne dans l’entité. Le nombre de séquences
identifié sont ici plus restreintes en raison du fait que la dynamique n’est pas entreprise
de la même manière dans ce cas.
Le contexte de la DSI en 2011 est assez particulier puisque l’entité nouvellement créée
hérite d’un mode d’organisation provenant de l’ancienne entreprise mère. Quatre années
après la création de GRDF, une nouvelle directrice des systèmes d’information est
nommée. Dès son arrivée, les constats autour de l’insatisfaction des services proposés par
la DSI sont forts :
« Assez rapidement même très rapidement en 2011 lorsque je suis arrivé je me suis
rendu compte que ce qu’on avait c'était assez inhumain, on demandait à des
utilisateurs des choses impossibles, on leur demandait d’avoir exprimé des besoins
pour quelque chose qui arriverait dans un an. Et dans la majorité des cas les équipes
de la DSI n’étaient pas capables de répondre rapidement à des besoins et des demandes
simples » (selon la directrice de la DSI).
« Nous, on avait déjà connu des projets avec des cycles en V où l’ont rédigeait un
cahier des charges, on voyait apparaitre le projet un an après et malheureusement ça
ne correspondait plus aux besoins » (selon le responsable de la transformation
digitale).
La principale difficulté rencontrée par les équipes de la DSI dans cette séquence réside
dans sa faible réactivité compte tenu des nombreuses sollicitations des métiers. Le mode
de fonctionnement évoqué par les différents acteurs internes repose sur une approche
méthodologique séquentielle (DSI-IGRT-2.1). Pour combler à ces problèmes, un
responsable de domaine propose d’expérimenter la mise en place d’une équipe agile (DSI-
IGRT-3.1). Il figure que c’est lors d’un séminaire de direction que la décision de lancer une
première équipe agile est prise :
« Deux trois mois après mon arrivée lors d'un comité de direction parmi les sujets
il y avait ce sujet-là et comment on arrive à répondre rapidement à des besoins et pas
un an après avoir exprimé le besoin. Lors d’un comité de direction en mai 2011, il y
avait quelqu'un qui doit toujours être à GRDF et avait déjà travaillé sur l'agilité. Il
335
nous a évoqué qu’une solution possible pouvait être l'agilité et nous a proposé de
monter une cellule agile et donc c'est comme ça que l'idée de la CARMA est née »
(selon la directrice de la DSI).
« À cette époque on ne sait pas où on va, mais on pensait qu’on allait y arriver, ce
qui est intéressant c’est qu’on avait une volonté de commencer petit pour essayer
quelque chose, expérimenter » (selon la directrice de la DSI).
Comme il s’agissait à l’époque d’une expérimentation, une des difficultés qu’il a fallu
combler résidait dans les modes de contractualisation avec les prestataires externes.
L’appel d’offres ayant été lancé pour intégrer de nouveaux acteurs externes à cette cellule
a donc été adapté pour tenir compte d’engagements plus flexibles (DSI-IGRT-7.1).
À la suite des réponses et entretiens liés à l’appel d’offres, la CARMA est créée au sein
de la DSI pour travailler sur le développement d’applications mobiles et web. Comme il
est évoqué précédemment, les choix dans le fonctionnement se portent dès les débuts sur
méthode Scrum (DSI-IGRT-8.1) :
« En termes de méthode, la cellule a été créée en 2012 et c'était une des premières
cellules agiles au sein de GRDF. C'est vraiment l'ADN de la cellule de faire de l'agile.
Donc on utilise essentiellement Scrum pour tout ce qui est build et kanban plutôt pour
des applications en run » (selon le responsable de la CARMA).
336
Le build correspond ici au nouveau projet à développer, et le run concerne les
applications en maintenance. Or, malgré les moyens mis en œuvre pour développer la
réactivité de la CARMA, les équipes métiers ne consacrent pas assez de temps aux
développeurs de la cellule. Scrum exigerait une trop forte présence des utilisateurs :
« On pensait au début que les métiers allaient être satisfaits, l’idée était d’être à
leur écoute pour développer plus vite on pensait qu’ils allaient être contents. Mais
finalement, il a vraiment fallu se battre avec les différentes directions, car certains
directeurs me disaient « mais tu comprends. On n’a pas assez de temps donc on ne
peut pas travailler en méthode agile parce que ça demande trop de temps. Donc il
faut qu'on choisisse », alors je disais ça va être simple on ne va pas faire le projet.
Donc ça va aller encore plus vite » (selon la directrice de la DSI).
Afin de faciliter les relations entre la CARMA et les métiers, un coach est intégré à la
cellule afin de faciliter les interactions entre les différentes parties prenantes métiers aux
projets développés par la CARMA (DSI-IGRT-9.1).
« La division SI et performance nous ont quand même bien aidé pour alléger les
procédures, à la base ils sont très procéduriers et du coup, quand la CARMA est
arrivée avec ces trucs un peu rapides, comment tu rentres dans un process ? Ils nous
ont simplifié le process. Et une fois que nous sommes passés en comité projet ils nous
laissent faire » (selon un Scrum Master de la CARMA).
La création de la CARMA n’est cependant pas un long fleuve tranquille au sein de la DSI.
Elle est considérée comme un électron libre par les différentes divisions et subit de
nombreuses réticences par les autres domaines de la DSI (DSI-IGRT-11.1).
« Un autre poids au démarrage on pensait qu’on allait utiliser la CARMA pour des
petits projets d'applications déconnectées du reste du décor. Les architectes étaient
337
très inquiets il y avait des fortes réticences internes à la DSI, le nombre de personnes
qui sont venus me dire que ce n’était ni fait ni à faire, il ne fallait absolument pas
continuer comme ça. À l'intérieur de la DSI si j'en ai eu un certain nombre » (selon la
directrice de la DSI).
« Les discours des acteurs de la DSI trouvaient que l’agile, c'était bien pour faire
des petits projets. Et puis, quand ça devient un peu plus gros, un peu important, un
peu stratégique, il fallait laisser faire les grandes personnes et faire du cycle en V. Il a
fallu beaucoup œuvrer pour trouver notre légitimité en commençant presque à côté
de la DSI et accepter de faire des petits projets qui n’étaient pas très intégrés ou pas
très stratégiques » (selon le responsable de la CARMA).
Malgré ces réticences, la CARMA est fortement soutenue par la directrice de la DSI, et
œuvre notamment à la communication autour sur la cellule auprès des différentes unités
d’affaires (DSI-IGRT-12.1) :
Malgré les efforts de communication, le temps consacré par les différents acteurs
métier aux projets de la CARMA est faible. Une des raisons qui explique ce point faible
réside notamment dans la distance entre les acteurs métiers et les membres de la CARMA
(UA-IGRT-13). Nous l’évoquions lors de la présentation de l’entreprise, la majorité des
acteurs métier sont répartis sur toute la France. Dans cette optique, un rôle de Product
Owner Proxy est créé (DSI-IGRT-14.1).
« C’est un rôle qui a été créé par le CARMA, car on se rend compte que les PO n'ont
pas de temps dédié au projet, il faut pouvoir les accompagner et ce sont souvent des
personnes qui ne connaissent pas l'informatique. L’idée est de les faire entrer dans la
méthode agile aussi. On peut être comparé à des facilitateurs, des médiateurs, mais
le terme utilisé est PO Proxy » (selon un Product Owner proxy).
Toujours dans le but de contrer les difficultés liées au manque d’implication des acteurs
métiers, des formations sont mises en place pour former les acteurs métier au rôle de
Product Owner. Ces formations se systématisent dès qu’un projet est censé être lancé
(DSI-IGRT-15.1) :
338
« Avant même d'avoir été potentiellement sensibilisée, on est immergée dans un
environnement de travail dans les rituels Scrum. À partir de ces rituels, plusieurs
choses ont été faites. Évidemment j'ai exprimé le fait que je venais du monde
opérationnel et que je basculais dans un projet pour la première fois et que je ne
connaissais pas tout. La CARMA m’a proposé de suivre une formation dispensée par
des acteurs externes sur le rôle de PO, sur les modalités de production, etc. ça allait
du Manifeste agile, des rituels scrum au tableau kanban » (selon un Product Owner
métier).
En 2014, la croissance de la CARMA se révèle être forte. Plus de dix équipes Scrum sont
en place représentant un total d’environ 50 acteurs et le sujet de la synchronisation de
tous ces acteurs se pose :
« Oui bah nous, c'est un peu le modèle Spotify qu'on a fait, en fait, alors nous, ce ne
sont pas des features teams de Spotify parce que nous, on travaille sur différents
produits logiciels. Mais c'est exactement le modèle Spotify qu'on a voulu faire » (selon
un Scrum Master de la CARMA).
339
Sur un plan d’analyse plus large que la CARMA, la Direction des Ressources Humaines
lance un programme de renouvellement du management (nommé PETRAM) et se nourrit
de l'expérience de la CARMA pour alimenter ses réflexions dans la diffusion d'une culture
digitale (US-IGRT-18.1).
« Comme on a développé une expertise sur Scrum et l'agilité même en général, avec
l'état d'esprit qui est derrière et comme les projets que l’on nous a confiés marchent
bien. Il y a maintenant un peu plus de deux ans, on nous a rajouté comme mission de
diffuser la culture agile, l'état d'esprit agile, l'agilité, chez GRDF, donc déjà à la DSI et
après au-delà. Et là, c'est un vaste chantier. Du coup, on n'avait pas un gros budget
pour le faire parce que notre cœur de métier est quand même de sortir des
applications et de faire correctement. Certaines entités métier ont commencé à venir
nous voir pour leur partager nos expériences. C’est le cas de l’initiative lancée par la
DRHT » (selon un développeur de la CARMA).
« Le DRH qui est très sensibilisé aux nouvelles méthodes de management, il s'est
dit "bon, on va déjà commencer par les managers parce qu'il y a du boulot, ils sont un
peu à l'ancienne nos managers". Et donc il a créé cette cellule transformation des
managers avec un programme de formation sur plusieurs mois pour leur apprendre
des nouvelles pratiques et pour leur passer quelques messages nouvelle génération.
Et donc c'est là où je leur ai présenté nos démarches et la DRH trouve que c'est hyper
complémentaire parce que justement, moi, j’accompagne tous les jours les
collaborateurs à s’approprier de nouvelles pratiques » (selon un Scrum Master de la
CARMA).
Dans cette optique, la CARMA propose des formations pour les différents acteurs
métiers en lien avec une initiative de groupe autour du changement de la posture
managériale. Puis la CARMA est aussi impliquée dans un programme de transformation
digitale mené par la direction de la communication du groupe pour développer des
applications, mais aussi partager ses pratiques de travail (US-IGRT-19.1).
Le dernier ingrédient de cette séquence réside dans les problèmes d’organisations liés
à la croissance de la CARMA. En 2015, l’entité atteint près de 100 personnes et les équipes
rencontrent un certain nombre de dysfonctionnements :
340
on arrivait donc à ces frictions, soit des blocages et surtout on s’est rendu compte que
les décisions n’étaient pas prises au bon niveau tout était concentré sur une ou deux
personnes » (selon le responsable de la CARMA).
Nous verrons dans la prochaine séquence que ces frictions ont conduit la CARMA à
développer un nouveau mode d’organisation.
Le rôle de la CARMA est d’autant plus intéressant dans cette première séquence
puisqu’elle contribue à diffuser des pratiques au-delà des frontières de la DSI. La
directrice de la DSI avait tout de même joué un rôle majeur en termes de communication,
mais c’est grâce aux retours positifs sur les applications développées que la CARMA s’est
construit sa notoriété au sein de GRDF.
Référence Type
Séquence 1 Période Description de l'ingrédient Moteur
ingrédient d'ingrédient
Remise en 2011 CONTEXTE Héritage du fonctionnement de l'ancienne DSI Dialectique
question du DSI-IGRT- Arrivée d'une nouvelle Actant
fonctionnement 1.1 directrice de la DSI
de la DSI et DSI-IGRT- De nombreux acteurs métiers Frein
lancement de la 2.1 témoignes de leurs faibles
CARMA satisfactions liées à la livraison
des projets
DSI-IGRT- Un responsable de domaine Actant
3.1 propose de mettre en place des
équipes agiles
DSI-IGRT- Séminaire d'équipe de direction Initiative
4.1
DSI-IGRT- Décision de lancer une Cellule Décision
5.1 d'Action Rapide en Méthode
agile
DSI-IGRT- Lancement d'un appel d'offres Initiative
6.1 pour le coaching
DSI-IGRT- Modification de la Initiative Évolutionniste
2012 7.1 contractualisation des achats
341
DSI-IGRT- Création de la CARMA Initiative
8.1 développant des projets avec
les approches Scrum et Kanban
DSI-IGRT- Lancement du coaching agile Initiative
9.1 planifiée
DSI-IGRT- Adaptation du comité de Initiative
10.1 lancement des projets pour la planifie
CARMA
DSI-IGRT- La CARMA fait face à de Frein
11.1 nombreuses réticences internes
DSI-IGRT- La directrice de la DSI soutient Actant
12.1 fortement ce dispositif en le
présentant aux différentes
unités d'affaires
UA-IGRT- Les acteurs métiers n'ont pas Frein
13.1 assez de temps à consacrer
pour les projets
PROJ- Création du rôle de Product Initiative
IGRT-14.1 Owner Proxi émergente
DSI-IGRT- Mise en place de formations Initiative
15.1 pour tous les Product Owner planifiée
DSI-IGRT- Mise en place de formation Initiative
16.1 pour les responsables de planifiée
domaine de la DSI
DSI-IGRT- La CARMA adopte le mode de Initiative
17.1 fonctionnement issu de Spotify émergente
US-IGRT- La Direction des ressources Initiative
18.1 humaines lance un programme
de renouvellement du
management (PETRAM) et se
nourrit de l'expérience CARMA
pour alimenter ses réflexions
dans la diffusion d'une culture
digitale
US-IGRT- Lancement d'un programme de Initiative
19.1 transformation digital mené par
la direction de la
communication du groupe avec
une forte implication de la
CARMA
DSI-IGRT- La croissance de la CARMA Frein
20.1 engendre des difficultés
2015 d’organisation
Tableau 56 : Synthèse de la première séquence du cas GRDF
342
3.2.2 Séquence 2 : la réorganisation de la CARMA
Dans cette deuxième séquence, la CARMA continue de croitre pour atteindre en 2015
près de 100 personnes en son sein. La bifurcation est principalement liée à une décision
commune des membres de la CARMA. Comme l’entité connaît de nombreuses équipes et
compte tenu des demandes toujours aussi nombreuses, ses membres lancent une
réflexion quant à une organisation plus efficace :
« On fait chaque année un Open Agile Adoption, c’est un rituel qui permet
d’impliquer la communauté dans l’amélioration de la CARMA, et les constats étaient
forts au niveau des dysfonctionnements, et un des sujets c’était justement de sortir de
ce mode d’organisation. Puis un des membres à proposer l’holacratie » (selon le
responsable de la CARMA).
« On fait de l'holacratie depuis deux ans et demi maintenant. […] c'est parce
qu'aussi, on est devenus très gros ; à partir d'une soixantaine de personnes, c'est là
où on s'est dit, "tiens, il faut qu'on trouve un nouveau mode d’organisation…", au
début, c'était un peu à l'arrache parce qu'on n'était pas très nombreux donc ça va. Au
bout, de cinquante, on a senti qu'il y avait besoin de faire quelque chose, de
s'organiser et il y avait un des coachs qui était là qui nous a dit "tiens, j'ai entendu
parler de l'holacratie"et maintenant, on a une grosse quinzaine de cercles qui sont
tous au sein de la CARMA » (selon un Scrum Master de la CARMA).
kk Le système Holacratie a été développé par Ternary Software, dont le fondateur Ternary, Brian
Robertson, a développé un livre par la suite précisant les pratiques d’organisation d’équipes en réseau. En
juin 2015, il a publié le livre "Holacracy" : The New Management System for a Rapidly Changing World, qui
détaille et explique ces pratiques.
343
« Et donc la CARMA comme elle a bien grandi sur les 100 personnes, on a environ
soixante-dix développeurs, on a six ou sept Scrum Master, trois UX Designers et des
intégrateurs. On a des architectes donc on est une mini DSI dans la DSI. On a même
des parties un peu RH pour le sourcing. On a des acteurs qui s'occupent des
infrastructures. Donc c’est une mini DSI dans la DSI. Et on est autonomes donc en fait,
on met tout en production, on gère nos serveurs et après on commande des serveurs
parfois ailleurs, mais on est très autonomes, ce qui nous permet de faire de la livraison
continue » (selon un développeur).
Si la méthode Scrum est toujours utilisée dans les cercles pour la conception,
l’holacratie permet de compléter les interactions initialement proposées dans la méthode
par de nouveaux rituels et de nouveaux rôles. La réunion de triage précédemment
évoquée est un rituel se tenant toutes les deux semaines pour synchroniser l’ensemble
« cercles ». Idem pour les réunions de gouvernance, celles-ci permettent de faire un état
du mode d’organisation, sont traitées notamment les tensions susceptibles de modifier
l'organisation des différends cercles. Notamment les rôles du cercle et les règles qui
s'appliquent à ces derniers.
« Les devs sont dans différents cercles qui adressent des produits pour un métier
donné et après, on a des cercles transverses qui sont plutôt des communautés de
pratique donc le cercle agilité, qualité, mobilité, etc. Alors, voilà, ça interagit comme
ça, on peut être dans plusieurs cercles et ça, pareil, il y a des gens qui viennent nous
voir pour parler de ce qu'on a fait pour l'holacratie et ça intéresse quelques équipes. »
(Selon un Scrum Master de la CARMA)
344
Une nouvelle difficulté rencontrée par les membres de la CARMA au cours de sa
croissance réside dans la rotation de ses équipes. Comme les développeurs sont
principalement des acteurs externes qui travaillent pour GRDF dans le cadre de
prestations de services, il n’est pas évident pour les acteurs métier de gérer l’intégration
de nouveaux développeurs :
« Nous avons toujours travaillé avec la même boîte depuis le début, pendant 6 ans
c'était la même boîte, du coup, c'était vraiment un partenariat, tout a été construit
avec eux. Et nous avons forcément été confrontés à gérer le turnover des
développeurs » (selon un Scrum Master de la CARMA)
Lorsqu’un collaborateur de GRDF veut proposer une idée, celle-ci est soumise dans une
plateforme interne. Les idées sont sélectionnées et sont ensuite développées par l’équipe
de la Fabrique en co-construction avec les porteurs d’idées. Ensuite, le développement de
ces prototypes est réalisé via la méthode Scrum et les porteurs d'idées deviennent
Product Owner de l’expérimentation. Pour accompagner ces acteurs dans la prise en main
du rôle ils sont notamment accompagnés par un Product Owner proxi de la Fabrique. La
fabrique contribue ainsi à diffuser le rôle de Product Owner au-delà des frontières de la
DSI. La Fabrique permet de contribuer par des mécanismes différents des projets
classiquement menés au sein de la DSI pour favoriser la mise en œuvre de la méthode
Scrum.
345
Toujours avec l’objectif de diffuser la culture agile initialement évoqué, les équipes de
la CARMA continuent de développer de nouvelles initiatives pour accompagner les
acteurs de la DSI et des différentes directions. Un Scrum Master de la CARMA est ainsi à
l’initiative de la cellule étincelle en septembre 2017 (DSI-IGRT-7.2). Cette cellule
composée de deux Scrum Master accompagne les collaborateurs de la DSI qui souhaitent
initier un changement en lien avec le programme d’entreprise.
Cette initiative s’inscrit en effet dans le programme d’entreprise Vert l’avenir lancé par
la direction générale en 2017. Ce programme de transformation à l’échelle du groupe
porte sur le renouvellement du métier de GRDF en lien avec la transition énergétique. Un
des objectifs du programme porte sur la responsabilisation des collaborateurs GRDF pour
construire la transition de l’organisation. C’est donc dans cette lignée que s’inscrit la
cellule étincelle au sein de la DSI.
346
Le dernier ingrédient de cette séquence n’est plus en lien direct avec les services de la
CARMA au sein de la DSI. En 2019, le responsable de domaine ayant proposé en 2012
l’idée de mettre en place une première équipe Scrum au sein de la DSI est à l’initiative de
la mise en place du cadre méthodologique SAFe dans le domaine Relation Client.
Référence Type
Séquence 2 Période Description de l'ingrédient Moteur
ingrédient d'ingrédient
Croissance de 2015 BIFURCATION Renouvellement de l'organisation de Initiative Évolutionniste
la Carma et la CARMA émergeant
présentation DSI-IGRT-2.2 La communication autour du Initiative
fonctionnement de la CARMA émergente
s’accentue via le réseau social interne
et des conférences thématiques
DSI-IGRT-3.2 La CARMA plus de 100 acteurs et ses Initiative
membres s'impliquent dans le émergente
nouveau programme stratégique du
groupe
DSI-IGRT-4.2 La CARMA est confrontée à des Frein
difficultés de rotation des équipes
DSI-IGRT-5.2 Création de la fabrique innovation Initiative
émergente
DSI-IGRT-6.2 Création d'une cellule Initiative
2018
d'accompagnement étincelle émergente
DSI-IGRT-7.2 La CARMA est sollicitée pour des Initiative
projets plus stratégiques comme le
projet GazPar
DSI-IGRT-8.2 Un domaine de la DSI se lance dans la Actant
mise en place de SAFe – l’initiative
2019
est soutenue par le porteur de la
CARMA
Tableau 57 : Synthèse de la deuxième séquence du cas GRDF
347
3.3 Synthèse du cas GRDF
Comparées aux cas précédents, les deux séquences identifiées au sein de la DSI de
GRDF traduisent une dynamique de généralisation émergente (tableau 58). En effet, ce
qui contribue à généraliser la méthode Scrum réside dans la croissance organique de la
CARMA. Bien qu’il y ait eu un fort soutien de la directrice de la DSI, c’est par le biais de la
CARMA et de ses retours d’expériences que d’autres entités s’inspirent de ses pratiques.
Par ailleurs, la personne ayant initié la CARMA s’est lancée en 2018 dans la mise en place
d’un Agile Release Train, traduisant ainsi une volonté de mettre en place de nombreuses
équipes Scrum synchronisées via le cadre SAFe.
348
DSI GRDF Zone Singularité des méthodes
d’innovation mises en œuvre
Zone A Séquence 1 : Les
Ensemble des - Introduction de la méthode Scrum différentes -
attributs de l’objet approches
étudié Séquence 2 : adoptées
- Complément de la méthode Scrum soutiennent
avec l’approche Kanban une pratique
Développement de la
- Mise en place du modèle d’innovation
Carmacratie, mode
d’organisation Spotify managériale
d’organisation inspiré de
- Mise en place de l’holacracy d’ordre
l’Holacratie.
- Essai de la méthode SAFe dans un contextuelle
domaine de la DSI en raison du
fait qu’elles
Zone P Toutes les approches mises en place sont toutes
État des pratiques par la CARMA se révèlent présentes
dans le domaine particulièrement novatrices pour la dans l’état
d’usage de référence DSI de GRDF. de l’art.
-
(nous considérons ici
le périmètre de
l’ensemble des DSI)
349
Synthèse du chapitre 7
Dans ce chapitre 7, nous avons présenté les résultats empiriques intra-cas issus de notre analyse
processuelle. Les 9 séquences d’ingrédients identifiés permettent de constater que la généralisation
d’une méthode agile n’est pas un processus linéaire. De plus chaque séquence est rythmée par de
nombreux ingrédients laissant place à différentes dynamiques de généralisation.
Le cas Amadeus est caractérisé par 4 séquences dans lesquelles se succèdent 3 programmes de
transformation. Un des points marquants du cas concerne la volonté forte du nouveau directeur de
la R&D d’instruire un changement. Avant son arrivée, la méthode Scrum est mise en œuvre dans
quelques équipes de la R&D et se généralise par des partages d’expériences entre les équipes. La
dynamique est ici émergente puisque ce sont les membres de la CARMA et par ses membres que la
généralisation s’effectue. Dans les 3 dernières séquences, la dynamique change radicalement
puisque des dispositifs sont mis en œuvre pour favoriser la généralisation vers plus d‘équipes. Nous
retrouvons ici le coaching et la formation comme dispositifs principaux pour conduire le
changement. Les 3 programmes de transformation lancés mettent ainsi bien en valeur une action
de généralisation planifiée.
Le cas Banque de France se traduit aussi par 4 séquences laissant place aussi à deux dynamiques
de généralisation. La méthode Scrum est mise en œuvre dans les équipes de façon émergente au
cours des deux premières séquences. La troisième séquence illustre notamment une succession de
décisions et d’initiatives qui conduisent le Gouverneur de la Banque à prendre la décision
d’instaurer à tous les projets la mise en œuvre systématique de la méthode Scrum. Cette décision
débouche ainsi vers une à une séquence où la dynamique de généralisation est planifiée.
Le cas GRDF se révèle différent en termes de séquencement, mais partage bien des ingrédients
avec les autres cas. La dynamique est principalement émergente au sein du cas puisque l’impulsion
de la directrice de la DSI en 2012 a permis de créer une entité ayant mis en œuvre la méthode Scrum.
C’est notamment par le biais des projets menés au sein de l’entité et de la forte implication de ses
membres que la méthode Scrum se généralise non seulement au sein de la DSI, mais aussi dans
différentes unités métier.
Les différentes séquences identifiées nous servent ainsi de support à l’analyse comparative des
cas, et donc à l’élaboration des résultats théoriques de la recherche. Nous proposons dans le
chapitre 8 de mettre en avant les régularités communes aux différents cas.
350
Partie 3 : Mise en perspective des résultats et
conclusion
351
Chapitre 8 : Retour analytique sur les
dynamiques de généralisation planifiées et
émergentes
352
Introduction
Pour donner suite au travail d’analyse approfondi des différents cas, nous proposons
dans ce dernier chapitre de tirer les apprentissages des quatre études de cas menées. La
première partie du chapitre propose une synthèse comparative. L’idée étant de mettre en
exergue les mécanismes et dynamiques communes aux différentes séquences des cas.
D’autre part, la première partie de ce chapitre alimentera notamment la théorisation de
nos résultats.
353
1. Synthèse comparative des cas
Les différents cas se révèlent être particulièrement riches d’apprentissages puisque 15
séquences ont pu être identifiées, représentant ainsi plus de 150 ingrédients au total. Le
tableau 60 dresse une vue synoptique des principaux moteurs de chaque séquence et
permet de mettre en valeur de premières similitudes. À ce stade des analyses,
l’instrument théorique utilisé pour clarifier les forces qui caractérisant le changement
autour de la généralisation d’une méthode agile se révèle limité pour tirer des généralités.
Nous proposons ainsi dans cette synthèse comparative d’illustrer les similitudes par le
biais de 10 leviers de comparaison et de compréhension en mettant en relation des
ingrédients communs des différentes séquences.
Les premières séquences de chacun des cas débutent soit par un moteur dialectique,
soit par un moteur évolutionniste. Commençons par les ingrédients communs aux cas qui
illustrent les moteurs dialectiques. Au sein de la DSI 1 de la Société Générale, un climat
d’insatisfaction régnait dans le fonctionnement des équipes. Le directeur de la DSI
l'évoquait à plusieurs reprises. Ce dernier constatait que les projets n’étaient pas assez
performants comparé à des entreprises plus matures (notamment les GAFA). La Société
Générale se lance par ailleurs dans une grande vague de transformation digitale,
soutenant les comparaisons à d’autres organisations.
Deuxièmement, les projets menés par la DSI 1 font l’objet de remises en question
systématique par les acteurs métiers. Les différents courtiers collaborant avec la DSI 1 de
la SG exigent une grande réactivité en raison du rythme particulier de leur métier. Aspect
354
qui se révèle difficile à résoudre en raison des différentes équipes impliquées dans les
projets. La DSI 1 est ainsi confrontée à une forte remise en question. La DSI 3 de la Société
Générale (celle notamment dédiée aux infrastructures) subit les mêmes difficultés. La
mise en place d’infrastructures techniques pour les autres DSI du groupe pouvait prendre
beaucoup de temps, ralentissant ainsi mécaniquement les projets menés par les autres
DSI. Le tableau 61 compile ainsi les points communs aux différents cas.
Les nombreuses entraves au bon fonctionnement des projets identifiés dans les
séquences sont souvent expliquées par la séparation des équipes. Les problèmes de
fonctionnement des projets pilotés par les départements techniques laissent place dans
les premières séquences à des crises dans le fonctionnement entre DSI et unités d’affaires
(synthétisés dans le tableau 61).
355
Ce premier caractère commun à tous les cas se raccroche théoriquement aux travaux
de David (1996). En effet, cette première séquence correspond au modèle de la conquête
précédemment évoqué dans la revue de littérature. Ce sont les développeurs et les acteurs
projets qui pilotent le processus de généralisation et c’est notamment eux qui mettent en
œuvre l’innovation. La dynamique émergente est qualifiée en quelque sorte, de
mécanismes « auto-pilotés » par les équipes.
L’héritage méthodologique concerne aussi les pratiques de pilotage des projets. Nous
illustrons particulièrement cet aspect dans les cas Amadeus et Banque de France où les
bonnes pratiques du PMBoK et de CMMI sont appliquées. Il est par ailleurs important de
préciser que ces méthodes sont reconnues et étiquetées en interne. Cet « étiquetage »
permet notamment de renforcer les points de contrôles des projets.
Dans la première séquence des cas, la méthode Scrum est mise en œuvre de façon « non
officielle ». Elle fait principalement l’objet d’expérimentations locales et la confrontation
avec les méthodes initialement en place dans les projets ne se révèle pas nécessairement
(du moins dans les débuts) être une source de dysfonctionnement. Ce point s’explique
notamment en raison du fait que la contextualisation dans les projets reste faible dans les
premières séquences des cas. Nous proposons dans la figure 76, une schématisation des
différentes approches méthodologiques. Les parties orangées désignent principalement
les expérimentations de la méthode Scrum dans les différents cas.
356
357
Figure 76 : Comparaison des trajectoires méthodologiques
L’introduction de la méthode Scrum est souvent expliquée par les différents individus
interrogés par une volonté d’expérimenter une nouvelle pratique. Nous avons
longuement analysé dans la revue de littérature la manière dont Scrum fait l’objet d’une
innovation managériale. En ce sens, le choix de la méthode Scrum se traduit ainsi dans les
cas par la mise en œuvre d’une innovation managériale « clé en main » (David, 1996).
Il figure de plus que la méthode Scrum est dans les cas Société Générale, Banque de
France et GRDF principalement introduite par des acteurs externes. Cet aspect peut être
expliqué de deux manières. D’une part, la méthode Scrum s’est diffusée d’organisation en
organisation dès sa création. Une certaine forme de mode managériale (Abrahamson &
Fairchild, 1999) peut expliquer les choix d’expérimenter l’approche par les développeurs.
Ce point renforce ainsi l’isomorphisme des organisations notamment évoqué par la
théorie néo-institutionnelle (DiMaggio & Powell, 1983).
Dans tous les cas, nous avons pu mettre en exergue l’importance des décisions prises
par les hauts responsables. Ce point a notamment été évoqué dans la phase exploratoire
par le discours des coachs agiles précisant l’importance du sponsorship des décideurs.
Dans ces trois cas, la dynamique de généralisation change par l’impulsion des décisions
prises par les hauts responsables (tableau 63). Elles conduisent à la mise en place de
moyens et dispositifs pour généraliser la méthode Scrum. La dynamique devient planifiée
dans les trois cas par le biais d’un programme de transformation ou d’un plan de
généralisation.
358
Les décisions identifiées dans les cas SG, Amadeus et BDF peuvent être expliquées par
le modèle politique de David (1996). L’impulsion provient de hauts responsables par la
formulation d’un message autour de l’innovation managériale. Puis les acteurs
accueillent l’innovation et inventent le contenu du nouveau mode de fonctionnement. Les
décisions des hauts responsables aboutissent notamment à la création de programmes de
transformation.
Dans le cas GRDF, l’impulsion de la directrice de la DSI est tout aussi importante
puisqu’elle accepte la proposition d’un de ses collaborateurs de créer une cellule interne
pour développer des projets avec la méthode Scrum. Elle décide très rapidement après
son arrivée d’initier ce changement. Nous avons vu dans le chapitre précédent que la
cellule créée s’est développée de façon autonome. La décision de la directrice de la DSI de
GRDF correspond plutôt au modèle gestionnaire de David (1996). L’impulsion donnée par
la directrice conduit les acteurs de la DSI à accueillir une innovation et explore les
connaissances pour inventer le contenu du nouveau mode de fonctionnement.
Nous avons pu identifier dans trois cas une action de généralisation planifiée qui se
matérialise par un programme de transformation (tableau 64). Ces programmes
permettent notamment de fixer des objectifs et une trajectoire de généralisation. Nous
reviendrons dans les points suivant les aspects récursifs des programmes. Nous avons pu
identifier par ailleurs plusieurs points communs aux différents programmes de
transformation lancés par la SG, la BDF et Amadeus.
D’une part, ils proposent tous un accompagnement par le biais de formations. Nous
avons pu voir dans le cas SG que des parcours de spécialisations ont été mis en place pour
accompagner les différents acteurs projets vers des certifications sur la méthode Scrum.
359
Les programmes lancés par Amadeus et par la Banque de France ont les mêmes ambitions.
Dans les trois cas, il est envisagé d’accompagner des acteurs sur la certification
Professionnal Scrum Master ou PMI-ACP.
Les formations ont aussi pour objectif de transmettre les différentes pratiques
complémentaires à la méthode Scrum. Comme les pratiques d’estimation des tâches et de
planification avec la méthode Scrum diffèrent des projets classiques, les formations
proposées dans tous les cas, dans des formats courts, des enseignements autour du
planning poker, de la gestion des tâches par tableau Kanban, etc.
Afin de coordonner les coachs intervenant auprès des équipes opérationnelles, il est
souvent envisagé la création d’une entité dédiée à l’accompagnement. Dans le cas de la
Société Générale, il s’agissait d’un centre agile. Pour Amadeus, les PMO se sont développés
en intégrant des coachs agiles. Dans le cas de Banque de France, la Fabrique Agile est
composée de deux coachs au-delà des autres consultants internes.
Le dernier volet identifié au niveau des programmes de transformation de tous les cas
porte sur la communication. À cet effet, les stratégies sont plutôt orientées sur des
échanges entre les pairs. Nous avons pu identifier dans les cas Amadeus et Banque de
360
France, la mise en place d’ambassadeurs pour promouvoir la nouvelle méthode auprès
des différents acteurs projet. Les communautés de pratiques sont aussi mises en place
pour favoriser des échanges entre pairs.
Dans le cas GRDF, une fois la décision prise par la directrice de la DSI concernant le
lancement de la CARMA, la croissance de cette dernière s’est déroulée de façon organique
et la généralisation de la méthode Scrum s’est faite par le biais de ses membres. Un des
points intéressants concerne notamment la volonté des acteurs de la CARMA de partager
leur mode de fonctionnement. De nombreuses initiatives ont émergé comme la création
d’une cellule d’accompagnement (cellule étincelle).
Dans les autres cas, de nombreuses initiatives émergentes ont été identifiées dans les
premières séquences. La méthode Scrum est dans un premier temps, mise en œuvre par
les acteurs opérationnels, notamment des développeurs, et c’est par le biais de ces acteurs
que la méthode se généralise. Les mécanismes de généralisation s’illustrent notamment
361
par des flux de partages et de feedback permettant de généraliser la méthode par un effet
de capillarité.
Ce genre de mécanismes sont beaucoup plus difficiles à capter par rapport aux
dispositifs intégrés dans les programmes de transformation. Néanmoins, nous avons
identifié ces mécanismes principalement dans les premières séquences de chaque cas. Au
sein de la Société Générale, ces mécanismes ont notamment permis de diffuser les
pratiques développées dans la DSI 1 auprès des autres DSI du groupe.
Les mécanismes identifiés dans les cas illustrent ainsi la dynamique de généralisation
émergente. Cette dernière peut se raccrocher aux théories proposées par certains auteurs
dans la littérature caractérisant la manière dont les équipes de développement gagnent
en maturité à mesure qu’elles gagnent de l’expérience via les méthodes agiles (Hoda &
Noble, 2017). Leur posture de précurseurs favorise les retours d’expériences.
Le tableau 65 et la figure75 mettent ainsi en exergue les séquences des cas où il a été
identifié des mécanismes d’expérimentations. Pour la Banque de France, cette période
était particulièrement longue puisque nous avons pu identifier des acteurs travaillant
avec la méthode Scrum dès 2006 et ce n’est qu’en 2016 que la méthode s’officialise. Il en
est de même pour le cas Amadeus et Société Générale. Dans les deux cas, des équipes de
développement avaient mis en œuvre la méthode dès 2009.
Les développeurs au sein des projets SI constituent ainsi le premier cercle d’acteurs
introduisant la méthode Scrum. Ils ne participent donc pas à l'invention d’une méthode,
mais effectuent plutôt un travail de veille active. Rogers (1995) qualifie ce genre d’acteur
« d’innovateur » puisqu’ils prennent le risque d’introduire une nouvelle méthode en
tentant de trouver un mode de fonctionnement stable. Ils participent ensuite à la
362
généralisation en partageant des retours d’expériences légitimant ainsi les premières
expérimentations. Ces mécanismes participent ainsi à la reconnaissance de la méthode
Scrum dans les différentes études de cas afin qu’elle puisse être ensuite validée par des
adopteurs précoces.
Comme la méthode Scrum est adaptée pour de petites équipes de développement, nous
avons pu voir plusieurs points communs dans les différentes études de cas au sujet de la
mise à l’échelle de la méthode pour de plus grands projets. L’extension est envisagée
systématiquement de deux manières. Comme le montre le tableau 66, le cadre
méthodologique SAFe est privilégié pour synchroniser plusieurs équipes travaillant sur
un même projet.
La mise en œuvre du cadre SAFe caractérise une volonté des différentes entreprises de
rationaliser le fonctionnement des équipes Scrum travaillant sur un même projet. Le
cadre méthodologique SAFe impose ainsi un alignement des différentes équipes Scrum
sur des cadences de deux semaines. Plusieurs caractéristiques du cadre méthodologique
reposent sur un principe de fonctionnement et d’organisation des équipes clair et non
ambigu. Le cadre propose par exemple 13 rôles nécessaires lorsqu’une organisation
souhaite pousser la logique de rationalisation à plusieurs équipes. Au-delà des rôles de la
méthode Scrum, lorsque plusieurs équipes doivent être synchronisées, la méthode
prescrit par exemple un rôle d’architecte, un manager de produit et un Release Train
Engineer (facilitateur). Les rôles des acteurs métiers sont de plus précisément définis
dans le cadre.
363
L’alliance de SAFe et de certaines pratiques de Spotify a pour objectif la mise en place
d’équipes alignées sur une chaîne de valeur métier. L’objectif est d’intégrer tous les
acteurs nécessaires au développement d’une application afin de maximiser la réponse à
des besoins utilisateurs continuellement évolutifs. L’objectif réside d’autre part dans la
réduction maximale des contraintes liées aux nombreux acteurs intervenant dans la
conception des applications.
Nous l’évoquions dans le premier point de cette section. Scrum est dans toutes les
entreprises considérées comme une innovation managériale puisque nous avons pu
remonter dans tous les cas aux sources des premières introductions. Néanmoins compte
tenu des analyses menées au sein des chapitres 1 et 2, nous pouvons systématiquement
considérer que la mise en œuvre de Scrum dans les différents cas traduit une politique
d’innovation managériale contextuelle au sens de Adam-Ledunois & David (2017).
Il figure que la dynamique pour étendre la méthode Scrum a un plus grand nombre de
projets se poursuit de la même manière par une dynamique d’innovation managériale
contextuelle. D’une part, les approches adoptées en complément engendrent de nouvelles
ruptures organisationnelles (nous détaillerons cet aspect dans le point 8 de cette section).
D’autre part, en intégrant de façon cyclique différentes approches (SAFe ou Spotify) pour
soutenir l’usage de la méthode Scrum dans les grands projets, nous constatons par le biais
de notre revue de littérature que les approches mobilisées sont toutes étiquetées par la
sphère académique. Tous ces éléments soutiennent des comportements mimétiques des
différentes organisations (Di Maggio & Powell, 1983).
364
7. Le coaching comme dispositif d’appropriation
Nous l’avons rapidement évoqué dans le point 4 de cette section, le coaching est le
dispositif privilégié dans tous les cas pour accompagner les différents acteurs impliqués
dans les projets dans l’appropriation de la méthode Scrum. Pour rappel, la théorie de
l’appropriation distingue trois perspectives interdépendantes dites : rationnelle, socio-
politique et psycho-cognitive. Mobilisées conjointement, ces trois perspectives
permettent d’appréhender finement la question de l’appropriation en considérant le
point de vue des concepteurs et des utilisateurs de l’outil.
Nous constatons que la méthode Scrum se présente comme une innovation « clé en
main ». Elle se traduit donc comme un modèle génératif au sens de Canet (2013) puisqu’il
s’agit d’une « recette » applicable à tout projet. Les coachs agiles interviennent dans tous
les cas sur plusieurs aspects de l’appropriation. D’une part, ils sont avant tout intégré
comme « experts » de la méthode auprès des acteurs opérationnels en facilitant
l’appropriation rationnelle de la méthode. Dans cette perspective, les coachs
accompagnent les équipes projet dans la facilitation des rituels autour de la méthode
Scrum pour assurer une utilisation efficace. L’accompagnement porte aussi sur la mise en
place de pratiques complémentaires à la méthode Scrum. Dans cette optique, les coachs
peuvent être amenées à faire évoluer la méthode.
Ensuite, nous avons pu voir que les coachs assurent un certain rôle dans la facilitation
des dynamiques de groupe dans les équipes. Ils doivent ainsi convaincre les différents
acteurs (de la DSI et des métiers) dans une collaboration fluide. En ce sens, les valeurs du
manifeste agile se révèlent être le moyen pour véhiculer une appropriation socio-cogitive
de la méthode Scrum. Les valeurs et principes du manifeste agile permettent de remettre
au centre des priorités la collaboration avec les utilisateurs, souvent localisés dans les
départements métiers des cas analysés.
Enfin, le coaching est privilégié pour accompagner les différents responsables de la DSI
et des unités d’affaires dans la compréhension des changements induits et dans la
construction d’une nouvelle posture. Cette dernière approche de coaching porte ainsi sur
la perspective socio-politique de l’appropriation de la méthode Scrum.
365
Perspective rationnelle Perspective Perspective socio-
cognitive politique
Catégorie Équipes projet du côté de la Acteurs des unités Responsables du
d’acteurs en DSI (Développeurs, testeurs, d’affaires impliqués côté de la DSI et des
question intégrateurs, etc.) dans les projets unités d’affaires
8. Une réorganisation cassant les frontières entre la DSI et les unités d’affaires
Les structures organisationnelles basées sur une séparation des équipes dans les DSI
présentent plusieurs défis, par exemple, les ressources appropriées pour une nouvelle
fonctionnalité ne sont pas toujours disponibles. Les membres effectuent leurs propres
tâches individuellement et ne travaillent pas réellement en tant qu'équipe. Ces défis
peuvent s’expliquer en raison du fait par exemple que certains acteurs proviennent de
centres de services externes (sous-traitants).
Les chefs de projets perdent ainsi plusieurs repères en ce qui concerne les pratiques
de pilotage puisque les logiques de planification et de mesure des avancées via la méthode
Scrum diffèrent des pratiques véhiculées classiquement dans les référentiels de gestion
de projet. La difficulté engendrée à ce sujet engendre directement une faible
appropriation de la méthode Scrum par les chefs de projets. Les cas Amadeus et Banque
de France ont été riches de constats à ce sujet. Plusieurs acteurs ont simplement manifesté
leurs rejets.
Comme l’illustre la figure 78 la mise en place d’un management par produit change
radicalement la manière dont une DSI organise la conception des SI. Lorsque la conception
des SI est envisagée par une dynamique projet, les équipes sont différenciées des acteurs
367
maintenant l’application développée. Puis, lorsqu’une application nécessite une
évolution, une nouvelle équipe projet est mise en place. La conception des SI dans une
dynamique produit comprend le développement, la maintenance et son évolution par la
même équipe dans une durée indéterminée.
Chez GRDF, l’organisation de la CARMA illustre assez bien la figure 78 puisque la cellule
est considérée en interne comme une « DSI dans la DSI ». Cette dernière est totalement
autonome en ce qui concerne le développement des applications avec les acteurs métiers.
Tout ce qui concerne la maintenance et l’évolution des applications développées est géré
par la CARMA.
Dans la continuité du précédent point, nous avons pu constater une certaine volonté
de fluidifier le processus de conception des SI afin de favoriser le déploiement continu des
applications. La méthode Scrum ne se révèle pas efficiente si l’ensemble des parties
prenantes liées au projet ne sont pas alignées sur le même fonctionnement. De nombreux
acteurs ont notamment évoqué les retards dans les projets en raison du temps nécessaire
pour préparer des environnements de développement (infrastructures).
Nous avons pu constater dans tous les cas une volonté d’installer un mode de
fonctionnement DevOps pour compléter l’usage de la méthode Scrum. L’idée est de casser
les silos entre les équipes dédiées aux infrastructures et les développeurs. Cependant, il
ne s’agit pas que d’une affaire de communication et d’interaction. Nous avons pu voir dans
tous les cas plusieurs expérimentations de technologies d’hébergement d’applications
utilisant le cloud computing.
368
La mise en place de ce genre de technologie change radicalement la manière de gérer
les infrastructures pour les équipes puisque les environnements sont déportés auprès de
fournisseurs de stockage cloud. Dans la majorité des cas étudiés, les entreprises
développent elles-mêmes leurs technologies cloud en raison de la sensibilité des données
à héberger. La mise en place d’hébergement cloud privé change radicalement la manière
dont les opérateurs d’infrastructures collaborent dans les projets :
Cet élément de discours illustre bien les changements de rôles des opérateurs
d’infrastructures. Ces derniers ne paramètrent plus physiquement les infrastructures, ils
sont chargés d’organiser le « branchement de ces applications » en développant des
interfaces de programmation (API). Autrement dit, ils sont censés savoir coder pour
mettre à disposition un environnement de travail pour les développeurs.
Ces dispositifs identifiés dans tous les cas questionnent ainsi la relation entre une
innovation managériale et les innovations technologiques. Pour Damanpour (2011), cette
question génère deux approches : l’approche « lead/lag » et l’approche « intégrée ».
L’approche « lead/lag » est fondée sur l’idée qu’un des types d’innovation précède et
favorise l’émergence de l’autre. Ainsi, Damanpour & Evan (1984) s’attachent à montrer
que la mise en œuvre d’une innovation managériale favorise et accélère l’innovation
technique. L’innovation « Lead » dans les cas étudiés représente la méthode Scrum
puisque nous avons pu identifier la genèse d’introduction de la méthode dans tous les cas.
Les trois innovations technologiques « lag » sont les technologies clouds, les outils
Un test de non-régression est un ensemble de tests d’un programme préalablement testé, après une
ll
modification, pour s’assurer que des défauts n’ont pas été introduits ou découverts dans des parties non
modifiées d’une application.
369
technologies d’automatisation des tests et les technologies de déploiement continu. Ce
triptyque est notamment résumé dans les cas lorsque les individus évoquent la mise en
place d’une approche DevOps. Nous avons pu ainsi identifier ce modèle cible à appliquer
aux projets dans tous les cas.
Le dernier élément clé de comparaisons des différents cas réside dans les pratiques qui
accompagnent la généralisation de la méthode Scrum. Comme la méthode se caractérise
par un substrat technique ouvert pour un usage principalement pour des équipes projet,
les départements supports en lien avec les projets sont impactés par le fonctionnement
de la méthode. Dans le cas de GRDF, il a notamment été envisagé très tôt une évolution du
mode de contractualisation avec les centres de services externes. L’objectif de cette
initiative portait essentiellement sur la mise en place d’un mode de contractualisation
adapté pour les équipes de la CARMA qui voit ses ressources constamment évoluer.
Dans le cas Amadeus, les bénéfices escomptés liés à la généralisation de Scrum dans la
séquence 2 ne sont pas atteints en raison du fait que certains clients maintiennent une
contractualisation des projets sur des périmètres limités. Or comme la méthode Scrum
est mise en place pour que les équipes R&D s’adaptent aux besoins changeants des clients.
Dans les dernières séquences, il est aussi envisagé un renouvellement des modes de
contractualisation avec les différentes compagnies travaillant avec Amadeus. Dans le cas
Banque de France, les réflexions dans les dernières séquences portent sur une nouvelle
manière d’attribuer les budgets dans les projets. Il était notamment question de mettre
en place des pratiques de budget flexibles afin d’éviter les projections sur plusieurs moins.
Au sein de la Société Générale, les acteurs métiers changent leurs pratiques de travail
notamment lorsqu’ils collaborent avec les acteurs des différentes DSI dans les projets. La
mise en place d’une formation sur le Design Thinking tend à mettre en place une nouvelle
approche d’analyse des besoins de la part des acteurs métier. Le Design thinking a donc
été privilégié pour doter les acteurs métiers d’outils adéquats pour collaborer avec une
équipe Scrum.
Ces faits constatés dans nos travaux rejoignent deux aspects dans la littérature sur
l’innovation managériale. D’une part, nous illustrons une nouvelle fois la manière dont la
méthode Scrum engendre des changements dans l’organisation et dans les processus
supports liés aux projets (Fariborz Damanpour, 1988). D’autre part, les innovations
managériales sont souvent pervasives et se confrontent à des défis internes en raison des
vastes changements qu’elles apportant à l’entreprise et aux fonctions administratives de
l'organisation. Nous avons pu ainsi illustrer la réaffectation des tâches et des
responsabilités qu’il peut y avoir auprès des différents acteurs liés aux projets (Fariborz
Damanpour & Evan, 1984; Teece, 1980)
370
2. Proposition d’un modèle de généralisation
Compte tenu des points de comparaisons précédents et de notre matériau empirique.
La généralisation de la méthode Scrum ne se traduit pas par un simple changement, ou
même une progression linéaire dans les organisations. Les coachs agiles caractérisaient
ce processus lui-même comme itératif, incrémental et adaptatif. Dans tous les cas, et
quelle que soit la dynamique (planifiée ou émergente) nous avons pu identifier trois
cycles de généralisation illustrés par la figure 79.
Le troisième cycle identifié concerne l’expansion de la méthode Scrum à tous les projets
en incluant les acteurs métier de façon plus intense. La généralisation s’illustre ici par le
biais de de nombreux dispositifs (en orange dans la troisième partie de la figure 79)
engageant de façon plus intense les acteurs métiers. L’expansion de la méthode Scrum
porte ainsi sur la mise en place d’équipes transversales représentant toute une chaîne de
valeur.
371
Ces trois cycles peuvent être détaillés autour d’un modèle processuel. En effet, nous
avons précédemment décrit les dynamiques de généralisation de la méthode Scrum et des
cycles y étant associés sans aborder la question du pilotage du processus de changement
que représente la généralisation. Pour compléter les trois cycles identifiés, nous
proposons un modèle processuel présentant plus précisément les différentes étapes liées
à la généralisation de la méthode Scrum.
Nous avons conduit à cet effet une approche de modélisation suivant les préconisations
de Gioia (Gioia et al., 2013). En effet, quelle que soit la démarche de la recherche,
compréhensive ou explicative, la modélisation passe par la description du phénomène.
Les chapitres 6 et 7 contribuent ainsi à alimenter la modélisation de nos résultats. Ces
chapitres permettent au lecteur d’avoir une description permettant de rendre
compréhensible la complexité du phénomène de généralisation d’une méthode agile. Sur
la base des 150 ingrédients et des 15 séquences analysées, nous avons réalisé une
concordance d’ingrédients reconstituant les différentes étapes de chaque cycle identifié
en figure 79. Nous proposons d’expliquer point par point les 6 étapes clés du modèle
proposé en figure 80.
1. La crise
D’une part, nous avons pu identifier à plusieurs reprises des entraves au bon
fonctionnement dans les projets SI menés par les DSI. Ces crises se sont souvent
manifestées par une insatisfaction des acteurs des unités d'affaires (souvent abordé dans
le cas SG, BDF et GRDF), des méfiances entre les différents membres de la DSI (notamment
au sein du BDF) ou même un mode d’organisation insatisfaisant (constaté par le directeur
R&D chez Amadeus). Les acteurs des projets SI peuvent sur la base d’une crise opter pour
la mise en œuvre d’une nouvelle méthode.
2. L’investigation - expérimentation
L’expérimentation porte sur la sélection d’une méthode et les essais dans les projets.
Les premières séquences de tous les cas s’illustrent notamment par de longues périodes
où la méthode est introduite et se transmet d’équipe en équipe. La méthode n’est pas
« établie » dans l’organisation et se traduit uniquement par des usages contextuels. Il est
en outre possible que le processus débute directement par une expérimentation puisque
372
la crise n’est pas nécessairement une raison conduisant une équipe à adopter une
nouvelle approche de conception. C’est en général l’insatisfaction d’un mode de
fonctionnement ancré dans les projets.
3. L’adaptation
Une fois la méthode introduite, celle-ci peut être mise en œuvre de façon fidèle ou bien
dans une logique extensive. Dans les différents projets identifiés, nous avons rarement
identifié une mise en œuvre fidèle de la méthode Scrum. En général, la méthode est
adaptée aux différents contextes vécus par les individus dans les projets. La création par
exemple du Product Owner Proxi au sein de la Banque de France et chez GRDF montre
une variante du rôle de Product Owner. Dans le cas Amadeus, il a aussi été mis en place
un Back Product Owner. L’adaptation porte aussi sur l’alliance de la méthode Kanban
systématique dans tous les cas.
4. L’évaluation :
L’évaluation est une étape qui illustrons principalement dans deux cas. Nous avons pu
mettre en valeur dans le cas Banque de France que les évaluations CMMI répétées ont
permis de mettre en exergue les bénéfices de la méthode Scrum. Les évaluations ont été
conduites à plusieurs reprises et ont notamment convaincu plusieurs responsables de la
DSI de l’intérêt de favoriser la méthode Scrum.
Dans le cas d’Amadeus, l’évaluation est menée en fin de première séquence. En effet
après avoir lancé un premier programme de transformation, une évaluation de la
maturité des équipes met en avant les nombreux dysfonctionnements dans les projets,
conduisant ainsi les acteurs de la R&D à entamer des réflexions sur un nouveau mode de
fonctionnement. L’évaluation est ici un moyen d’évaluer les bénéfices de la mise en œuvre
de la méthode au niveau d’un ensemble de projets afin d’avoir des moyens de
comparaison.
5. La décision :
La décision de généraliser une méthode peut être alimentée par une évaluation comme
il en a été le cas au sein de la Banque de France. Nous avons pu par ailleurs constater
systématiquement une décision d’un haut responsable hiérarchique ayant contribué à
accélérer le processus de généralisation. La décision dans le modèle que nous proposons
est donc censée être incarnée par un sponsor. La décision peut aussi être prise
directement par un sponsor. Par exemple, le directeur R&D d’Amadeus en 2012 est arrivé
avec la volonté de généraliser Scrum.
6. La généralisation
373
La dernière étape du modèle porte sur l’opérationnalisation de la généralisation. L’idée
est ici de caractériser les différentes actions, dispositifs, et flux d’échanges entre
praticiens permettant d’augmenter la contextualisation de la méthode Scrum dans une
organisation. L’étape de généralisation peut donc être planifiée, en ce sens les
programmes de transformation rassemblent les différents dispositifs à l’œuvre. Dans le
cas de GRDF, la généralisation est plutôt émergente avec des dispositifs créés par les
acteurs de la CARMA. La généralisation peut aussi être « participative » c’est-à-dire qu’elle
peut se caractériser par une dynamique planifiée et émergente à la fois. C’est notamment
le cas dans la séquence 2 du cas de la DSI 3 à la Société Générale.
374
Synthèse du chapitre 8
Dans ce chapitre 8, nous avons proposé une analyse comparative des résultats afin de les discuter
à la lumière des théories portant sur l’adoption et l’appropriation des outils de gestion ainsi que sur
les théories de l’adoption des innovations managériales. Nous concluons ce chapitre par un bref
rappel des résultats théoriques formulés à partir de la synthèse de nos analyses intra-cas et de leur
confrontation à la littérature existante. Ces résultats contribuent à répondre aux deux sous-
questions de recherche présentées dans la conclusion de la première partie.
Quels sont les changements organisationnels engendrés par la généralisation ? Nous avons pu
clarifier dans trois niveaux différents les changements induits par la généralisation de la méthode
Scrum. Au niveau micro (des individus), la méthode fait évoluer plusieurs rôles. Les responsabilités
des chefs de projets changent et les opérateurs d’infrastructures doivent s’initier au codage. Au
niveau meso (des équipes projet), les équipes passent d’un management par projet à un
management par produit. Enfin au niveau macro (à savoir l’organisation de la DSI ou d’un
département R&D), les frontières entre les équipes de la DSI et des métiers s’éclipsent au profit
d’équipes pluridisciplinaires dans les projets.
Nous avons proposé dans un second temps d’intégrer nos principaux résultats théoriques dans
un modèle visant à rendre compte des différents cycles de généralisation de la méthode Scrum. Plus
précisément, l’objectif de cette représentation est de permettre une meilleure compréhension des
différentes étapes clés identifiées dans les différents cas.
Ainsi, la représentation que nous proposons et le résultat de notre analyse approfondie de nos
quatre études contribuent à enrichir plusieurs volets théoriques et managériaux. Nous proposons
de les aborder en conclusion des travaux.
375
Conclusion générale des travaux
376
Notre projet de recherche visait la compréhension des dynamiques de généralisation
d’une méthode agile de gestion de projet dans des organisations complexes. En effet, si la
littérature reconnaît différentes manières d’adopter une méthode au sein d’une équipe,
et nous éclaire aussi sur l’adaptation pour les grands projets, elle n’en demeure pas moins
limitée quant à la question de l’adoption généralisée dans des organisations complexes.
Nos travaux avaient notamment pour ambition de répondre à la question de recherche :
comment se traduisent les dynamiques de généralisation d’une méthode agile de gestion
de projet ?
Nous avons souhaité caractériser 3 points clés de la généralisation que nous avons
exprimés sous forme de trois propositions de recherche. D’une part nous avons cherché
à examiner les dispositifs créés pour structurer la généralisation d’une méthode.
Deuxièmement, nous avons cherché à comprendre les impacts de la généralisation au
niveau des organisations, l’idée est d’illustrer précisément les éventuelles
restructurations initiées pour accompagner la généralisation d’un nouveau mode de
fonctionnement. Enfin notre troisième proposition portait sur l’analyse des facteurs
facilitants ou freinant la généralisation d’une méthode agile.
Dans cette perspective, notre recherche a reposé sur une démarche qualitative menée
en 2 temps. D’une part une phase exploratoire centrée sur une étude de cas pilote et des
entretiens exploratoire auprès d’agents clé du changement. La phase exploratoire s’est
ensuite concentrée sur la poursuite d’études de cas multiples. Les études de cas ont été
conduites au sein de quatre entreprises organisées par projets et évoluant dans des
secteurs d’activité différents (Société Générale, Amadeus, Banque de France, GRDF).
L’analyse de nos cas par le biais des instruments théoriques d’analyse processuelle
nous a permis d’apporter des éléments de réponse à notre problématique. L’analyse des
contextes, ingrédients, séquences et bifurcations nous a conduits in fine à proposer une
représentation du processus de généralisation précisant les différents cycles de
généralisation identifiés.
Nous proposons de conclure notre travail de thèse en 4 points. Nous présentons les
contributions conceptuelles et théoriques dans un premier temps et se suivront les
contributions managériales dans un second temps. Nous présenterons un recul critique
sur nos travaux en partie trois afin de terminer sur les futurs axes de recherche.
377
1. Contributions conceptuelles et théoriques
Plusieurs apports peuvent être dénombrés, néanmoins nous mettrons en évidence les
contributions essentielles. D’un point de vue conceptuel, l’état de l’art mené dans le
chapitre 1 et plus particulièrement dans le chapitre 2 constitue en soi un premier apport.
Afin de doter nos travaux d’un cadre théorique robuste pour l’analyse de notre
phénomène, nous avons proposé une démonstration permettant de considérer la
méthode Scrum comme un outil de gestion innovant. Il figure que cette approche pourrait
être répétée afin de mener une analyse critique du degré de nouveauté de toutes les
méthodes agiles. Nous nous sommes cependant principalement concentrés dans nos
travaux sur la méthode Scrum qui se révèle être un pilier de nombreuses autres méthodes.
Le chapitre deux nous a permis d’établir de plus un état de l’art complet des différentes
méthodes agiles afin de clarifier les liens avec le management par projet. Cette partie avait
notamment pour but de clarifier l’articulation entre la conception des SI et le management
de projet. Nous avons mis par ailleurs en exergue que les méthodes agiles ont une certaine
influence dans les référentiels de gestion de projet. Elles peuvent ainsi être considérées
comme des méthodes de gestion de projet innovantes.
• Une synthèse des trois rôles des coachs agiles au cours de la généralisation à
savoir : prêcheur de nouvelles valeurs, facilitateur des dynamiques de groupe
et catalyseur du changement.
• Nous avons d’autre part réalisé un focus particulier sur les différentes postures
de facilitation en proposant une taxonomie. Lorsque les coachs sont intégrés
dans les organisations, il figure que leur rôle d’expert méthodologique est
complété par des postures de facilitation pour favoriser l’appropriation d’une
méthode agile à un ensemble d’acteurs.
• Et enfin, nous avons identifié 10 groupes de facteurs accélérateurs et facteurs
freinant le processus de généralisation.
D’autre part, nos travaux éclairent une autre facette de la contextualisation externe.
Les organismes certificateurs jouent un rôle majeur dans la logique de diffusion et
d’adoption de la méthode Scrum auprès des entreprises. Ainsi, ces organismes
contribuent à harmoniser le fonctionnement d’entreprises appartenant au même champ
institutionnel.
379
2. Contributions managériales
Même si l’objectif de notre recherche portait avant tout sur la compréhension de la
généralisation d’une méthode agile sans nécessairement aboutir à la proposition d’outils
ou de discours normatif. Il nous semble important de notifier les contributions
managériales de nos travaux.
En premier lieu, nos travaux forment une réponse à l’appel du CIFREF puisqu’ils
fournissent une grille de compréhension robuste pour les entreprises qui souhaitent
initier la généralisation d’une méthode agile. Idem pour les entreprises étant en cours de
processus, ces dernières trouveront dans nos travaux un moyen de comparaison et de
réflexions quant à la création d’un programme de transformation agile. Les travaux
portant sur les coachs agiles permettent en plus de nourrir des réflexions quant à la
formation d’agents du changement. En effet, la taxonomie que nous proposons sert de
guide pour les acteurs accompagnant les équipes projet devant mettre en place une
méthode agile.
Comme nos travaux se sont déroulés dans le cadre d’une convention CIFRE, nous avons
à cet effet multiplié les échanges avec les partenaires de recherche en lien avec Daylight
tout au long des travaux. Nous avons pu ainsi animer trois rencontres de recherches et
deux réunions thématiques afin d’accompagner les partenaires dans leurs réflexions sur
les méthodes à mettre en œuvre dans leurs projets.
Dans une optique conseil-recherche, la méthodologie mise en place pour nos travaux
contribue à développer la capacité du cabinet sur plusieurs aspects. Elle permet tout
d’abord de doter les consultants d’une méthode de diagnostic des transformations agiles
permettant de manipuler plusieurs sources de données. Deuxièmement, nos travaux
permettent d’augmenter la capacité du cabinet à développer des démarches de
programmes de transformation. Dans cette optique, nous avons contribué à formaliser un
programme de transformation pour le compte de la DSI d’une autorité de régulation
française.
380
3. Recul critique et discussion de la qualité de
la recherche
Nous proposons dans cette section d’aborder la question de la validité et de la fiabilité
de notre recherche. Tout d’abord, la validité interne d’une recherche reflète la cohérence
et la pertinence internes des résultats de l’étude (Blanc et al., 2014). Elle peut ainsi être
expliquée au travers de trois aspects méthodologiques fondamentaux que sont la collecte,
l’analyse et la restitution des données. D’une part nous avons veillé dans tous les cas à
démultiplier les sources de données. De l’observation à la collecte documentaire en
passant par la réalisation d’entretiens, l’ensemble de notre matériel empirique nous
permet ainsi de trianguler les données, évacuant ainsi certains biais possibles lors de la
collecte de données.
Compte tenu de ces éléments, la fiabilité d’une recherche s’apprécie de plus par la
capacité du protocole de recherche à produire des résultats similaires dans le cadre de sa
réplication (Kirk & Miller, 1986). Il demeure difficile d’anticiper le résultat du phénomène
observé. Cependant, nous pensons préciser suffisamment d’éléments de notre démarche
de recherche pour permettre une appréciation de sa fiabilité par nos pairs. Nous
décrivons scrupuleusement les différents aspects de notre protocole méthodologique,
notamment notre design de recherche ainsi que les différents choix pour la collecte et
l’analyse des données.
381
Au-delà des contributions théoriques et managériales de notre travail, des limites
essentiellement d’ordre méthodologique sont à signaler quant à la validité externe des
résultats énoncés. En effet nous nous sommes restreints à un échantillonnage de quatre
cas. Même si nous avons recherché des spécificités pour obtenir de la variété entre nos
cas, en vue d’accroître la compréhension du phénomène et la validité des découvertes
opérées, nous ne pouvons prétendre que nos résultats soient applicables de façon large.
Le phénomène analysé se révèle particulièrement complexe tout en évoluant
quotidiennement.
Toutefois, la volonté initiale n’a pas été de tendre vers une généralisation statistique,
mais vers une généralisation analytique (Yin, 1994), dans le but d’enrichir les travaux les
plus récents sur la transformation agile. A cette limite, inhérente à toute étude de cas,
s’ajoutent des limites qui relèvent plus spécifiquement de notre démarche d’analyse.
Comme nous l’avons souligné dans notre chapitre 5, l’analyse des données demeure une
étape importante, mais critique des démarches qualitatives. En outre, même si nous avons
fait en sorte de limiter les effets de distorsion de la réalité, grâce notamment à l’étude de
plusieurs cas et à la considération des faits qui pouvaient nous paraître d’importance
moindre, nous avons bien conscience qu’avec le recul, les analyses conduisent à certains
biais.
382
4. Perspectives de recherches futures
Une deuxième voie de recherche porte sur une analyse des mécaniques profonde de la
mise en œuvre du cadre méthodologique SAFe et Spotify. Comme ces cadres véhiculent
de nouveaux rituels, il nous parait pertinent d’approfondir la manière dont ces méta
modèles d’organisations contribuent à structurer les projets SI dans le temps afin de
comprendre leur perpétuation.
Une troisième voie de recherche liée à nos travaux repose sur une étude exclusive des
acteurs métiers impliqués dans les projets. En effet, nous avons principalement eu le
regard d’acteurs de la DSI en raison du fait que la méthode Scrum provient notamment de
cette entité. Comprendre les contrefaits à la généralisation par le biais d’entretiens auprès
des acteurs métier se révèle être pertinent. Ils nourriraient ainsi les appels de l’Agile
Alliance demandant à la communauté de chercheur d’investiguer la manière dont les
métiers deviennent « agiles » (concept de business agility).
Pour finir, nous espérons que notre travail a contribué à une meilleure compréhension
de la généralisation d’une méthode agile. Malgré cela, le sujet présente encore des zones
d’ombre. En ce sens, nous ne pouvons qu’encourager les chercheurs à poursuivre leurs
efforts dans ce domaine d’étude encore largement inépuisé à ce jour.
383
Communications associées à la thèse
Berkani, A., Causse, D., Thomas, L., 2019. Triggers analysis of an agile transformation:
a case study of the transition from experimentation to generalization. International
conference on project management, Sousse, Tunisie.
https://www.sciencedirect.com/science/article/pii/S1877050919322525?via%3Dihub
Berkani, A., 2019. Agile transformation explained under the lens of management
innovation implementation. In the 1st workshop in agile transformation, Agile Alliance, XP
2019, Montréal, Canada
Berkani, A. & Causse, D., 2019. Explaining the agile transformation through
management innovation adoption. In the 19th conference of the European academy of
Management, Lisbonne, Portugal.
Berkani, A. & Causse, D., 2018. Investigating characteristics of the agile
transformation process: focus on agents transition. In the 23th conference of the
Association Information and Management, Montréal, Canada.
Berkani, A. & Tran, S. 2018. Le long chemin vers la généralisation des méthodes agiles.
The conversation. https://theconversation.com/le-long-chemin-vers-la-generalisation-
des-methodes-agiles-107295
Berkani, A. & Tran, S. 2019. Management : trois leviers pour déployer les méthodes
agiles à plus grande échelle. The conversation.
https://theconversation.com/management-trois-leviers-pour-deployer-les-methodes-
agiles-a-plus-grande-echelle-106803
Berkani, A., 2017. Role of centers dedicated to the diffusion of agile methods: a
complex organization case. In the 22th conference of the Association Information and
Management, Paris, France.
384
Liste des annexes
385
Annexe 1 : Guide d’entretien de la phase explicative
Parties N° Thèmes de discussion Questions Relances, investigation, implication Appui dans la réflexion
Partie 1:
Parties N°1 Postionnement de
Thèmes de discussion Pouvez-vous vous présenter Questions ? Relances, investigation, implication Appui dans la réflexion
Présentation
Partie 1: l'acteur projet / de
12 Postionnement Quel est votrevous
Pouvez-vous poste ? Rôle ??
présenter Quelle entité ? DSI - MOE / MOA
du l'acteur
Présentation Définition
23 l'acteur et /
projet Auprès
Quel estde quelle
votre entité
poste êtes-vous
? Rôle ? rattachés ? Quel est votre mode Traditionnel
Quelle entité/ ?matriciel
DSI - MOE/ projet
/ MOA?
du l'acteur compréhension
35 Définition et de Comment
Auprès dedécririez-vous la culture rattachés
quelle entité êtes-vous de votre entreprise
? Quel est ?votre mode Traditionnel / matriciel / projet ?
l'agilité
5 compréhension de Êtes-vous impliqués
Comment danslaunculture
décririez-vous projetde ? Lequel ? Quand à ?débuté votre Quel est l'objectif de celui-ci
votre entreprise
6 l'agilité projet ? impliqués dans un projet ? Lequel ? Quand à débuté votre Quel
Êtes-vous ? est l'objectif de celui-ci
6 projet ? ? 4 valeurs et 12 principes du
Qu'est-ce que pour vous l'agilité ? Connaissez-vous le manifeste
manifeste
4 valeurs etagile de
12 principes du
agile ? Comment
Qu'est-ce que pour vous
vous identifiez-vous par rapports àleces
l'agilité ? Connaissez-vous valeurs ?
manifeste
7 développement
manifeste agile dede logiciels
agile ? Comment vous identifiez-vous par rapports à ces valeurs ?
Partie 2 : 7 Contexte et développement de logiciels
Pourquoi et comment s'est pris la décision d'adopter une approche Quelles motivations, attentes
Initiation
Partie 2: - explications
Contexte et du choix
agile ? et comment s'est pris la décision d'adopter une approche Quelles
Pourquoi en termes de performance
motivations, attentes?
Décision de
Initiation - de l'agilité etdu
8 explications d'une
choix
agile ? en termes de performance ?
mettre ende
Décision approche
8 de l'agilitéen
et d'une Quels acteurs dans votre entreprise ont été impliqués dans cette Directeur des SystèMes
œuvre une
mettre en particulieren
9 approche prise de
Quels décision
acteurs dans? votre entreprise ont été impliqués dans cette d'Information
Directeur ? PMO ?
des SystèMes
approche
œuvre une 10
9 particulier A quelle
prise date cette
de décision ? décision a-t-elle été prise ? d'Information ? PMO ?
agile
approche 10 A quelle date cette décision a-t-elle été prise ? Comment travailliez-vous
Cette approche était-elle nouvelle dans votre entreprise ?
agile 11 auparaventtravailliez-vous
Comment ?
Cette approche était-elle nouvelle dans votre entreprise ?
12
11 A quel moment le processus de mise en œuvre a-t-il été lancé ? auparavent ?
12 A quel moment le processus de mise en œuvre a-t-il été lancé ? Réduction du TTM,
Quels ont été (sont) les effets de ces pratiques sur votre projet ? Amélioration
Réduction de la qualité,
du TTM,
Que vous
Quels ont ont-elles
été (sont)apportés
les effets? de ces pratiques sur votre projet ? meilleure adaptation
Amélioration aux
de la qualité,
13 Que vous ont-elles apportés ? changements
meilleure adaptation aux
14
13 Quels ont été les freins dans l'appropriation ? changements
15
14 Comment
Quels les avez-vous
ont été gérésl'appropriation
les freins dans ? ?
16
15 Quels ont été
Comment les leviersgérés
les avez-vous ? ?
17
16 Comment
Quels interprétez-vous
ont été les leviers ? la mise en œuvre de cette approche ?
Partie 3 : 17 Mise en œuvre et De quelle manière
Comment mettez-vous
interprétez-vous en en
la mise place l’agilité
œuvre dans approche
de cette votre projet
? ? Scrum / XP / Kanban ? SAFe /
Mise en application de l'agilité
Implémentati
Partie 3: dispositifs
18 Mise en œuvre et Quel
De type manière
quelle d'approche avez-vous en
mettez-vous misplace
en place ? dans votre projet ? Scrum
l’agilité LeSS / DaD
/ XP ?/ Kanban ? SAFe /
Mise en application de l'agilité
on et mise en
Implémentati d'accompagnement
18 dispositifs Quel type d'approche avez-vous mis en place ? LeSS / DaD ? Principe de fidelité - extensivité
Diriez-vous que vous restez fidèle à l'approche initiale ?
usage
on et mise en 19 d'accompagnement de l'approche
Principe de fidelité - extensivité
Diriez-vous que vous restez fidèle à l'approche initiale ?
usage 19 SI oui laquelle ou lesquelles ? de l'approche
y-a-t-il d'autres approches agiles mises en œuvre dans votre
(Agilité
SI à l'echelle
oui laquelle par
ou lesquelles ?
entreprise
y-a-t-il ? approches agiles mises en œuvre dans votre
d'autres
20 exemple)
(Agilité à l'echelle par
entreprise ?
20 Votre approche initiale était
exemple)
Quelle approche méthodologique mettiez-vous en œuvre dans les
basé sur
Votre un référentiel
approche initiale en
était
projets approche
Quelle avant l'agilité ?
méthodologique mettiez-vous en œuvre dans les
21 particulier
basé sur un?référentiel en
projets avant l'agilité ?
21 Comment avez-vous
particulier ? été au
courant deavez-vous
Comment l'introductionété au
Comment avez-vous été informés au sujet de l'agilité ?
l'agilité dans
courant votre entreprise
de l'introduction
Comment avez-vous été informés au sujet de l'agilité ?
22 ?
l'agilité dans votre entreprise
23
22 Par quels canaux ? (réunion, mail, événement…) ?
23 Comment
Par avez-vous
quels canaux vous étémail,
? (réunion, accompagnés
événement…) dans l'appropriation de Cet accompagnement a-t-il
24 l'agilité ? Coaching
Comment avez-vous? vous été accompagnés dans l'appropriation de Cet été accompagnement
bénéfique ? a-t-il
24 l'agilité ? Coaching ? Les formations
été bénéfique ?étaient
Avez-vous pu assister à des formations ?
25 centrées
Les sur quels
formations sujet ?
étaient
Avez-vous pu assister à des formations ? Existe-t-ilsur
unquels
dispositif
25 Qui est chargé en interne de vous accompagner ? centrées sujet ?
26 d'accompagnement
Existe-t-il un dispositif ?
27 Qui est chargé
Comment en interne
avez-vous de vous
eu accès à cesaccompagner
informations?? Formel / Informel ? ?
26 d'accompagnement
28
27 Qui consultez-vous
Comment avez-vousen eucas de problème
accès ?
à ces informations ? Formel / Informel ?
29
28 Êtes-vous
Qui évalués au
consultez-vous ensein
cas de vos projets?? Si oui par qui est
problème
30
29 Avez-vousévalués
Êtes-vous été évalués
au seinsurdela mise en œuvre
vos projets ? Si de
ouil'agilité
par qui dans
est votre
31
30 Avez-vous été eu des objectifs
évalués sur laliés
miseà laen
mise eu œuvre
œuvre ? dans votre
de l'agilité
Partie 4 : 31 Avez-vous eu des objectifs liés à la mise eu œuvre ? Existe-il toujours le rôle du
Routinisation
Partie 4: Chef de projet
Existe-il toujours ? Comment
le rôle duse
Avez-vous constaté des évolutions / changements suite à la mise en
au sein de
Routinisation caractérise
Chef de le partage
projet ? de se
Comment
œuvre de l'agilité
Avez-vous constaté? Quels sont les apports
des évolutions ?
/ changements suite à la mise en responsabilités dans votre
l'organisation
au sein de caractérise le partage de
Impacts induits par la œuvre de l'agilité ? Quels sont les apports ?
l'organisation 32 projet ?
responsabilités dans votre
mise en induits
Impacts œuvre depar la
33
32 l'approche Avez-vous constaté des frictions ? Des obstacles à la mise en œuvre projet ?
mise en œuvre de
34
33 Quels leviers
Avez-vous avez-vous
constaté identifié?dans
des frictions la mise enàœuvre
Des obstacles la mise? en œuvre
l'approche
34 Quels leviers avez-vous identifié dans la mise en œuvre ? Dans les interactions entre le
La mise en place de l'approche agile a-t-elle engendré des
projetles
Dans etinteractions
les autres parties
entre le
évolutions au niveau de votre organisation
La mise en place de l'approche agile a-t-elle engendré des?
35 prenantes.
projet et les autres parties
évolutions au niveau de votre organisation ?
35 Comment percevez-vous les autres projets d'un point de vue Comment fonctionnent ces
prenantes.
36 méthodologique
Comment ? Vous semblent-ils
percevez-vous alignés
les autres projets pour
d'un pouvoir
point bien
de vue équipes ? fonctionnent ces
Comment
36 méthodologique ? Vous semblent-ils alignés pour pouvoir bien équipes ? Les individus et leurs
interactions
Les individusplus que les
et leurs
processus etplus
interactions les outils
que les
votre organisation
386
Pensez-vous que la philosophie du manifeste agile s'imprègne dans Des logiciels
processus et opérationnels
les outils plus
Pensez-vous que la?philosophie du manifeste agile s'imprègne dans qu’une
Des documentation
logiciels opérationnels plus
votre organisation ? exhaustive
qu’une documentation
Diffusion interne -
La collaboration avec les clients
exhaustive
Généralisation
37 Diffusion interne - plus
La que la négociation
collaboration avec les clients
Généralisation Comment se traduisent les interactions avec vos supérieurs ?
37 Revenir sur la question 1,5 plus que la négociation
25 centrées sur quels sujet ?
Existe-t-il un dispositif
Qui est chargé en interne de vous accompagner ?
26 d'accompagnement ?
27 Comment avez-vous eu accès à ces informations ? Formel / Informel ?
28 Qui consultez-vous en cas de problème ?
29 Êtes-vous évalués au sein de vos projets ? Si oui par qui est
30 Avez-vous été évalués sur la mise en œuvre de l'agilité dans votre
31 Avez-vous eu des objectifs liés à la mise eu œuvre ?
Partie 4 : Existe-il toujours le rôle du
Routinisation Chef de projet ? Comment se
Avez-vous constaté des évolutions / changements suite à la mise en
au sein de caractérise le partage de
œuvre de l'agilité ? Quels sont les apports ?
l'organisation responsabilités dans votre
Impacts induits par la
32 projet ?
mise en œuvre de
33 Avez-vous constaté des frictions ? Des obstacles à la mise en œuvre
l'approche
34 Quels leviers avez-vous identifié dans la mise en œuvre ?
Dans les interactions entre le
La mise en place de l'approche agile a-t-elle engendré des
projet et les autres parties
évolutions au niveau de votre organisation ?
35 prenantes.
Comment percevez-vous les autres projets d'un point de vue Comment fonctionnent ces
36 méthodologique ? Vous semblent-ils alignés pour pouvoir bien équipes ?
Les individus et leurs
interactions plus que les
processus et les outils
Pensez-vous que la philosophie du manifeste agile s'imprègne dans Des logiciels opérationnels plus
votre organisation ? qu’une documentation
exhaustive
Diffusion interne -
La collaboration avec les clients
Généralisation
37 plus que la négociation
Comment se traduisent les interactions avec vos supérieurs ?
Revenir sur la question 1,5
L'agilité a-t-elle changé des éléments dans la culture ?
Quels ont été les dispositifs
Comment travaillez-vous avec les acteurs de l'équipe projet ? mis en œuvre pour favoriser
38 la diffusion ?
Quelle est la suite selon vous ? Quelles sont les prochaines étapes
39 dans la diffusion en interne ?
Partie 5 : Avis de l'acteur sur la Y-a-t-il d'autres points que nous n'avons pas abordés et qui vous
Synthèse 40 mise en œuvre de semblent importants ?
l'agilité Avez-vous d'autres éléments à apporter sur les facteurs qui ont
41 freiné ou aidé l'adoption et l'appropriation de l'agilité ?
Pensez-vous que l'approche agile mise en œuvre est finalement
42 bénéfique ?
387
Annexe 2 : Inventaire des entretiens
N° Entreprise Fonction Date de l'entretien
1 Responsable de CMP 20/01/2017
2 Assistant chef de projet 13/06/2018
3 SOCGE 2 coachs agiles 15/04/2017
4 Responsables des centres agiles 15/05/2017
5 Responsable du BSC 15/05/2017
6 PMO 14/04/2018
7 Coach Agile 23/05/2018
8 Project Manager 24/05/2018
9 Project Manager 24/05/2018
10 PMO 24/05/2018
AMADEUS
11 PMO 25/05/2018
12 Project Manager 25/05/2018
13 Agile Expert 29/05/2018
14 Central Project Office 05/10/2018
15 Manager, CSS-TSC-DPS-PMO-PSO 06/11/2018
16 Coach Agile 29/01/2018
17 Responsable du PMO 24/04/2018
18 Co responsable du PMO 03/05/2018
19 Coach Agile 27/03/2018
20 Coach Agile 17/04/2018
21 Coach Agile 24/07/2018
22 Responsable des projets IT 24/07/2018
23 Responsable adjoint des projets IT 24/07/2018
24 Responsable DIPRO - CENSEP/CENTER 25/10/2018
25 BDF Membre - DIGIT - Lab Inno 25/10/2018
26 Coach Agile 13/03/2018
27 Chef de projet MOE 22/03/2019
28 Coach agile 25/03/2019
29 Consultante interne MOA 02/04/2019
30 Consultant pole ACT 19/04/2019
31 Consultante interne MOA 19/04/2019
32 Consultante interne MOA 19/04/2019
33 Product Owner 06/05/2019
34 Chef de projet MOE 23/05/2019
35 Consultant externe 27/07/2018
36 Scrum Master 31/07/2018
37 Scrum Master 25/09/2018
38 Responsable de la transformation 27/09/2018
39 Product Owner 19/11/2018
40 GRDF Product Owner 09/10/2018
41 Responsable diffusion agilité groupe 14/08/2018
42 Développeur squad Fabrique 15/10/2018
43 Directrice des systèmes d'information 27/11/2018
44 Coach Agile 01/03/2019
45 Responsable de la CARMA 18/04/2019
388
Annexe 3 : Codage par la technique de la lecture flottante
389
Annexe 4 : Facteurs accélérateurs issus des entretiens exploratoires
Comparaison aux
Facteurs accélérateurs résultats de Dikert et
al., (2016)
Groupe 1 : Focus au niveau organisationnel
Coordonner une démarche de transformation qui intègre les différentes couches hiérarchiques et les différents
départements Facteur convergent
Définir et communiquer une vision claire de la transformation à l'ensemble des parties prenantes -
Impliquer les départements métiers dans la transformation au même niveau que les équipes techniques -
Lever la relation client fournisseur entre la DSI et les métiers - générer plus de confiance -
Donner du sens et de la cohérence à la transformation au sein des différentes couches de l'organisation -
Donner du temps aux acteurs métier dans les projets -
Donner du sens au changement organisationnel engendré par les approches agiles -
Le middle management est la couche nécessitant le plus d'accompagnement - (ce sont les premières personnes
à former) Facteur convergent
Organiser les équipes distantes en suivant une démarche commune d'implication dans la conduite de la
transformation par rapport aux équipes locales -
Groupe 2 Rôle du top management - middle management
Avoir un sponsor au sein de la DSI mais au-delà pour avoir un support hiérarchique
Définir un leader qui s'appuiera sur les valeurs de l'agilité à diffuser Facteur convergent
Les managers doivent agir comme relai dans le changement (facilitateur - servant leader) -
Le top management doit adopter un lâcher prise et favoriser l'auto organisation des équipes Facteur convergent
Groupe 3 : Culture à adopter
Mettre en place une culture d'apprenance -
S'appuyer sur un socle de valeurs fortes à l'entreprise et aux valeurs du manifeste -
Insuffler une culture d'acceptation de l'échec -
Insuffler la confiance entre les managers et les équipes -
Insuffler une culture d'amélioration continue -
Faire face aux processus rigides en laissant la place à des expérimentations -
Groupe 4 : Dispositifs à exploiter
Co-construction des pratiques entre les coachs et les équipes -
Sensibiliser, communiquer, favoriser les retours d'expérience dans les différentes couches de l'organisation -
Mettre en place une évaluation des équipes de manière qualitative (pour évaluer de manière efficace le niveau de
maturité) -
Importance de "l'évangélisme" au début du déploiement pour convaincre les équipes d'aller vers l'agilité -
Mettre les projets agiles pilotes dans les mêmes conditions que le reste des projets de l'organisation -
Favoriser la collaboration entre les équipes en les faisant rencontrer plus souvent (séminaire de lancement) -
Favoriser les points de consolidation et de synchronisation des différentes couches organisationnelles -
Créer des seuils et des rituels pour partager le sens des évolutions -
Mettre en place une équipe de coach coordonnée par une cellule d'appui Facteur convergent
Créer des communautés de pratiques permet d'appuyer la transformation dans la durée -
Profiter des ruptures rencontrées pour lancer les démarches de transformation -
Groupe 5 : Leviers du pilotage de la transformation
Les hauts responsables opèrent le pilotage de la transformation et donnent la vision -
La transformation doit se décliner par le biais d'agents dédiés Facteur convergent
Importance du rôle des leaders dans la communication autour de l'agilité Facteur convergent
Favoriser les initiatives et mettre en valeur les success stories pour favoriser une diffusion virale de l'agilité -
390
Annexe 5 : Facteurs ralentisseurs issus des entretiens exploratoires
Comparaison aux
Facteurs ralentisseurs résultats de Dikert
et al., (2016)
Groupe 1 : Freins d'ordre humains
Le conformisme des individus dans les différentes couches de l'organisation
L'accroche au pouvoir des managers Facteurs
Résistances au changement lié aux méthodes traditionnelles convergents
L'attente de solutions miracles par la mise en place d'une méthode agile
Groupe 2 : Freins liés aux différentes couches / départements de l'organisation
Le middle management ne suit pas la transformation -
L'organisation en silo - MOE MOA / AMOE et AMOA -
Accompagnement des métiers insuffisant -
Manque d'alignement et de synchronisation des projets agiles au niveau vertical (couches hiérarchiques) -
Manque de sensibilisation et d'implication des acteurs métiers Facteur convergent
Manque d'aménagement (temps) des acteurs métiers Facteur convergent
Manque d'accompagnement dans les différentes couches (opérationnels, middle management, top
management) Facteur convergent
La rigidité des processus existants -
Manque de relai de la vision au niveau des différentes couches de l'organisation -
Stature et système organisationnel figé (enracinement organisationnel) -
Groupe 3 : La gestion des différents paradigmes de gestion de projet
Gérer les différentes approches agiles à petite échelle et grande échelle (continuous delivery, scrum,
SAFe) Facteur convergent
Difficultés à marier les différentes démarches projet d'une grande organisation -
Groupe 4 : Mauvaises pratiques
L'agilité ne se met pas en place uniquement avec des méthodes mais, avant tout par des valeurs Facteur convergent
La transformation se focalisant uniquement sur des micros-silos Facteur convergent
La mise en place d'un cadre méthodologique trop prescriptif (Démarche du type SAFE) -
Le top management ne considère pas les bons enjeux de l'agilité -
Imposer le passage à l'agilité -
Le manque d'objectifs dans la transformation -
Rester dans un dispositif d'adoption -
Groupe 5 : Substrat technique de l'agilité
La transformation commence par la DSI mais touche pas assez les autres départements de l'organisation -
L'étiquette informatique de l'agilité freine les acteurs métiers -
Groupe 6 : Freins dans le déroulement de la transformation
Les grandes organisations sont longues à transformer -
La singularité des coachs agiles peut générer des visions différentes de l’agilité et entrainer des
dysfonctionnements -
Manque de financement de l'accompagnement -
Effondrement de certaines mesures dû au manque de vision et d'objectifs Facteur convergent
Frustration des coachs et de certaines équipes -
La multitude de parties prenantes réduisant la visibilité de la transformation -
391
Références bibliographiques
Abbott, A. (2001). Time matters: On theory and method. University of Chicago Press.
Abrahamson, E. (1991). Managerial Fads and Fashions: The Diffusion and Rejection of
Innovations. The Academy of Management Review, 16(3), 586.
Abrahamson, E., & Fairchild, G. (1999). Management fashion: Lifecycles, triggers, and
collective learning processes. Administrative Science Quarterly, 44(4), 708–740.
Abrahamsson, P., Conboy, K., & Wang, X. (2009). ‘Lots done, more to do’: the current state
of agile systems development research. European Journal of Information Systems,
18(4), 281–284.
Abrahamsson, P., Oza, N., & Siponen, M. T. (2003). Agile software development methods:
A comparative review. Agile Software Development: Current Research and Future
Directions, 31–59.
Adam-Ledunois, S., & Damart, S. (2017). Innovations managériales, attrapons-les toutes !
Revue Française de Gestion, 43(264), 117–142.
Adam-ledunois, S., Damart, S., Adam-ledunois, S., Damart, S., & Adam-ledunois, S. (2018).
Innovation managériale … ou pas ? Design d ’ une méthodologie d ’ analyse critique des
objets de management To cite this version : HAL Id : hal-01780623 Innovation
managériale … ou pas ? Design d ’ une méthodologie d ’ analyse critique des objets de
manag.
Ågerfalk, P. J., Fitzgerald, B., & Slaughter, S. A. (2009). Flexible and distributed information
systems development: State of the art and research challenges. Information Systems
Research, 20(3), 317–328.
Aggeri, F. (2011). Le développement durable comme champ d’innovation. Revue Française
de Gestion, 6, 87–106.
Aggeri, F., & Hatchuel, A. (1997). Les instruments de l’apprentissage. Du Mode d ‘existence
Des.
Aggeri, F., & Labatut, J. (2010). La gestion au prisme de ses instruments : Une analyse
généalogique des approches théoriques fondées sur les instruments de gestion.
Finance Contrôle Stratégie 3 (13), 5-37. (2010), 13(3).
Ahmed, A., Ahmad, S., Ehsan, N., Mirza, E., & Sarwar, S. Z. (2010). Agile software
development: Impact on productivity and quality. 5th IEEE International Conference
on Management of Innovation and Technology, ICMIT2010, 287–291.
Al-Ahmad, W., Al-Fagih, K., Khanfar, K., Alsamara, K., Abuleil, S., & Abu-Salem, H. (2009). A
Taxonomy of an IT Project Failure: Root Causes. International Management Review,
5(1), 93.
Al-Emran, A., & Pfahl, D. (2007). Operational planning, re-planning and risk analysis for
software releases. Lecture Notes in Computer Science (Including Subseries Lecture
Notes in Artificial Intelligence and Lecture Notes in Bioinformatics), 4589 LNCS, 315–
329.
Alqudah, M., & Razali, R. (2016a). A Review of Scaling Agile Methods in Large Software
Development. International Journal on Advanced Science, Engineering and
Information Technology, 6(6), 828.
Alqudah, M., & Razali, R. (2016b). A Review of Scaling Agile Methods in Large Software
Development. International Journal on Advanced Science, Engineering and
392
Information Technology, 6(6), 828.
Ambler, S. W., & Lines, M. (2014). Scaling Agile Software Development (DAD). In
Disciplined Agile Consortium, White Paper Series (Issue May).
Ansari, S. M., & Zajac, E. J. (2010). MADE TO FIT : HOW PRACTICES VARY AS THEY
DIFFUSE University of Cambridge University of Southern California. Academy of
Management Review, 35(1), 67–92.
Artin, D. P. M. (2007). Outils de gestion et pilotage dynamique de l ’ action collective. 10, 75–
110.
Avison, D., & Fitzgerald, G. (2003). Information systems development: methodologies,
techniques and tools. McGraw Hill.
Ayache, M., & Dumez, H. (2011). Le codage dans la recherche qualitative une nouvelle
perspective? Le Libellio d’Aegis, 7(2-Eté), 33–46.
Ayerbe, C., & Missonier, A. (2007). Validité interne et validité externe de l’étude de cas:
principes et mise en œuvre pour un renforcement mutuel. Finance Contrôle Stratégie,
10(2), 37–62.
Babuscio, J. (2009). How the FBI Learned to Catch Bad Guys One Iteration at a Time. 2009
Agile Conference, 96–100.
Bajec, M., Vavpotič, D., & Krisper, M. (2007). Practice-driven approach for creating project-
specific software development methods. Information and Software Technology, 49(4),
345–365.
Baldridge, J. V., & Burnham, R. A. (1975). Organizational innovation: Individual,
organizational, and environmental impacts. Administrative Science Quarterly, 165–
176.
Barroca, L., Dingsøyr, T., & Mikalsen, M. (2019). Agile Transformation : A Summary and
Research Agenda from the First International Workshop.
Bass, J. M. (2012). Influences on Agile Practice Tailoring in Enterprise Software
Development. 2012 Agile India, 1–9.
Baumard, P., & Ibert, J. (1999). Quelques approches avec quelles données?, Extrait de
THIETART, R. A. et Call. Méthodes de Recherche En Management, Dunod, Paris.
Benefield, G. (2008, August). Rolling out Agile in a Large Enterprise. Proceedings of the
41st Hawaii International Conference on System Sciences - 2008 Rolling.
Bennington, H. D. (1983). Production of Large Computer Systems. Annals of the History of
Computing, 5(4), 350–361. http://csse.usc.edu/TECHRPTS/1983/usccse83-
501/usccse83-501.pdf
Berente, N., & Lyytinen, K. (2007). What Is Being Iterated? Reflections on Iteration in
Information System Engineering Processes. In Conceptual Modelling in Information
Systems Engineering (pp. 261–278). Springer Berlin Heidelberg.
Berkani, A. (2017). Rôle des centres dédiés à la diffusion des méthodes agiles : le cas d’une
organisation complexe. 22ème Conférence de l’Association Information et
Management ,Paris, France.
Berry, M. (1983). Une technologie invisible - L’impact des instruments de gestion sur
l’évolution des systèmes humains. hal-00263141
Berry, M. (2008). Une technologie invisible - L ’ impact des instruments de gestion sur l ’
évolution des systèmes humains To cite this version : HAL Id : hal-00263141.
Besson, P., Besson, P., & Rowe, F. (2012). Perspectives sur le phénomène de la
transformation organisationnelle. Systèmes d’Information et Management (French
Journal of Management Information Systems), 16(1), 3–34.
BHASKAR, R. (1978). On the Possibility of Social Scientific Knowledge and the Limits of
Naturalism. Journal for the Theory of Social Behaviour, 8(1), 1–28.
393
Bick, S., Spohrer, K., Hoda, R., Scheerer, A., & Heinzl, A. (2018). Coordination Challenges in
Large-Scale Software Development: A Case Study of Planning Misalignment in Hybrid
Settings. IEEE Transactions on Software Engineering, 44(10), 932–950.
Bidart, C., Longo, M. E., & Mendez, A. (2013). Time and Process: An Operational
Framework for Processual Analysis. European Sociological Review, 29(4), 743–751.
Bider, I., & Jalali, A. (2016). Agile business process development: why, how and when—
applying Nonaka’s theory of knowledge transformation to business process
development. In Information Systems and e-Business Management (Vol. 14, Issue 4).
Birkinshaw, J., Hamel, G., & Mol, M. J. (2008). Management innovation. In Academy of
Management Review (Vol. 33, Issue 4, pp. 825–845).
Blanc, A., Drucker-Godard, C., & Ehlinger, S. (2014). Exploitation des données textuelles.
Bodén, J. (2016). Scaling Agile Development A case study at Saab business area Surveillance.
Boehm, B. (2002). Get ready for agile methods, with care. Computer, 35(1), 64–69.
Boehm, B., & Turner, R. (2004). Balancing agility and discipline: evaluating and integrating
agile and plan-driven methods. 718–719.
Boehm, B. W. (1988). A spiral model of software development and enhancement.
Computer, 21(5), 61–72.
Boehm, Barry. (1996). Anchoring the software process. IEEE Software, 13(4), 73–82.
Boehm, Barry, & Turner, R. (2003a). People factors in software management: lessons from
comparing agile and plan-driven methods. CrossTalk: The Journal of Defense Software
Engineering, 16(12), 4–8.
Boehm, Barry, & Turner, R. (2003b). Rebalancing Your Organization’s Agility and
Discipline (pp. 1–8).
Boehm, Barry, & Turner, R. (2005). Management challenges to implementing agile
processes in traditional development organizations. IEEE Software, 22(5), 30–39.
Booch, G. (1996). Managing object-oriented software development. Annals of Software
Engineering, 2, 237–258.
Booch, G. (2018). The History of Software Engineering. IEEE Software, 35(5), 108–114.
Brendan, J., Noble, J., & Craig, A. (2019). Agile Practices in Practice: Towards a Theory of
Agile Adoption and Process Evolution (P. Kruchten, S. Fraser, & F. Coallier (eds.); Vol.
355). Springer International Publishing.
Brennecke, A., & Keil-Slawik, R. (1996). History of Software Engineering.
Breu, K., & Hemingway, C. J. (2004). Making organisations virtual: The hidden cost of
distributed teams. Journal of Information Technology, 19(3), 191–202.
Butler, S. Z., Hollen, S. M., Cao, L., Cui, Y., Gupta, J. A., Gutiérrez, H. R., Heinz, T. F., Hong, S.
S., Huang, J., & Ismach, A. F. (2013). Progress, challenges, and opportunities in two-
dimensional materials beyond graphene. ACS Nano, 7(4), 2898–2926.
Campanelli, A. S., Camilo, R. D., & Parreiras, F. S. (2018). The impact of tailoring criteria on
agile practices adoption: A survey with novice agile practitioners in Brazil. Journal of
Systems and Software, 137, 366–379.
Campanelli, A. S., & Parreiras, F. S. (2015). Agile methods tailoring - A systematic literature
review. Journal of Systems and Software, 110.
Canet, E. (2012). L’innovation managériale de l’invention à la diffusion : Analyse du
processus d’établissement d’une innovation managériale à partir du cas de la méthode
5 steps.
Canet, E. (2013). La fabrique des outils de gestion : quels régimes de conception ? XXII
Conférence Internationale de Management Stratégique, 26. http://halshs.archives-
ouvertes.fr/docs/00/86/79/73/PDF/canete.pdf
Canet, E., & Tran, S. (2017). What Role Does the Technical Substrate Play in the
394
Appropriation of Management Innovation ? A Longitudinal Analysis of an Innovative
Method *. Management International, 21(4).
Cao, L., Mohan, K., Xu, P., & Ramesh, B. (2009a). A framework for adapting agile
development methodologies. European Journal of Information Systems, 18(4), 332–
343.
Cao, L., Mohan, K., Xu, P., & Ramesh, B. (2009b). A framework for adapting agile
development methodologies. European Journal of Information Systems, 18(4), 332–
343.
Catellin, S. (2004). L’ABDUCTION: UNE PRATIQUE DE LA DÉCOUVERTE SCIENTIFIQUE
ET LITTÉRAIRE. Hermès, La Revue, 39, 179–185.
Chakrabarty, S., Whitten, D., & Green, K. (2007). Understanding service quality and
relationship quality in is outsourcing: Client orientation and promotion, project
management effectiveness, and the task-technology-structure fit. Journal of
Computer Information Systems, 48(2), 1–15.
Chan, F. K. Y. (2009). Acceptance of agile methodologies: A critical review and conceptual
framework. Decision Support Systems, 46(4), 803–814.
Chandler, A. (1977). La Main visible des managers (H. U. Press (ed.)).
Chen, C. C., Law, C. C. H., & Yang, S. C. (2009). Managing ERP Implementation Failure A
Project. 56(1), 157–170.
Chia, R., & King, I. W. (1998). The organizational structuring of novelty. Organization, 5(4),
461–478.
Chiapello, È., & Gilbert, P. (2013). Sociologie des outils de gestion. In Sociologie des outils
de gestion.
Cho, J. (2008). Issues and Challenges of Agile Software Development With Scrum. Issues in
Information Systems, 9(2), 188–195.
Cockburn, A. (2006). Agile software development: the cooperative game. Pearson
Education.
Cohn, M., & Ford, D. (2003). Introducing an Agile Process to an Organization. Computer,
36(6), 74–78.
Collerette, P. (1997). L’étude de cas au service de la recherche. Recherche En Soins
Infirmiers, 50, 81–88.
Conboy, K. (2009). Agility from first principles: Reconstructing the concept of agility in
information systems development. Information Systems Research, 20(3), 329–354.
Conboy, K., & Carroll, N. (2019). Implementing Large-Scale Agile Frameworks: Challenges
and Recommendations. IEEE Software, 36(2), 44–50.
Conboy, K., & Fitzgerald, B. (2010). Method and developer characteristics for effective
agile method tailoring. ACM Transactions on Software Engineering and Methodology,
20(1), 1–30.
Conboy, K., & Morgan, L. (2011). Beyond the customer: Opening the agile systems
development process. Information and Software Technology, 53(5), 535–542.
Conforto, Edivandro C., Salum, F., Amaral, D. C., da Silva, S. L., & de Almeida, L. F. M. (2014).
Can Agile Project Management Be Adopted by Industries Other than Software
Development? Project Management Journal, 45(3), 21–34.
Conforto, Edivandro Carlos, & Amaral, D. C. (2010). Evaluating an agile method for
planning and controlling innovative projects. Project Management Journal, 41(2), 73–
80.
Conforto, Edivandro Carlos, Amaral, D. C., da Silva, S. L., Di Felippo, A., & Kamikawachi, D.
S. L. (2016). The agility construct on project management theory. International
Journal of Project Management, 34(4), 660–674.
395
Conforto, Edivandro Carlos, Rebentisch, E., & Amaral, D. C. (2014). The Building Blocks of
Agility as a Team ’ s Competence in Project Management.
https://dspace.mit.edu/bitstream/handle/1721.1/88105/PM-Agility-Global-
Survey-PMI-Executive-Report-v10.pdf?sequence=1
Cooper, R. G. (2016). Agile-stage-gate hybrids. Research Technology Management, 59(1),
21–29.
Coplien, J. O. (1994). Borland Software Craftsmanship : A New Look at Process , Quality and
Productivity. June.
Coram, M. (2005). The Impact of Agile Methods on Software Project Management.
Proceedings of the 12th IEEE International Conference and Workshops on the
Engineering of Computer-Based Systems (ECBS’05).
Cram, A. W., & Newell, S. (2016). Mindful revolution or mindless trend? Examining agile
development as a management fashion. European Journal of Information Systems,
25(2), 154–169.
Creswell, J. W., & Poth, C. N. (2017). Qualitative inquiry and research design: Choosing
among five approaches. Sage publications.
Cusumano, M. A., & Selby, R. W. (1996). How microsoft competes. In Research Technology
Management (Vol. 39, Issue 1, pp. 26–30). Industrial Research Institute Inc.
Daft, R. L. (1978). A Dual-Core Model of Organizational Innovation. Source: The Academy
of Management Journal, 21(2), 193–210.
Damanpour, F. (1991). ORGANIZATIONAL INNOVATION: A META-ANALYSIS OF EFFECTS
OF DETERMINANTS AND MODERATORS. Academy of Management Journal.
Damanpour, Fariborz. (1988). Innovation type, radicalness, and the adoption process.
Communication Research, 15(5), 545–567.
Damanpour, Fariborz. (2014). Footnotes to research on management innovation.
Organization Studies, 35(9), 1265–1285.
Damanpour, Fariborz. (2017). Organizational Innovation. In Oxford Research
Encyclopedia of Business and Management (Issue March).
Damanpour, Fariborz, & Aravind, D. (2012). Managerial Innovation: Conceptions,
Processes, and Antecedents. Management and Organization Review.
Damanpour, Fariborz, & Daniel Wischnevsky, J. (2006). Research on innovation in
organizations: Distinguishing innovation-generating from innovation-adopting
organizations. Journal of Engineering and Technology Management - JET-M.
Damanpour, Fariborz, & Evan, W. M. (1984). Organizational innovation and performance:
the problem of" organizational lag". Administrative Science Quarterly, 392–409.
Damanpour, Fariborz, & Schneider, M. (2006a). Phases of the adoption of innovation in
organizations: Effects of environment, organization and top managers. British Journal
of Management.
Damanpour, Fariborz, & Schneider, M. (2006b). Phases of the adoption of innovation in
organizations: Effects of environment, organization and top managers. British Journal
of Management.
Damanpour, Fariborz, Walker, R. M., & Avellaneda, C. N. (2009). Combinative effects of
innovation types and organizational Performance: A longitudinal study of service
organizations. Journal of Management Studies.
Damart, S. (2013). How Mary P. Follett’s ideas on management have emerged. Journal of
Management History, 19(4), 459–473.
Daneva, M., Van Der Veen, E., Amrit, C., Ghaisas, S., Sikkel, K., Kumar, R., Ajmeri, N.,
Ramteerthkar, U., & Wieringa, R. (2013). Agile requirements prioritization in large-
scale outsourced system projects: An empirical study. Journal of Systems and
396
Software, 86(5), 1333–1353.
David, A. (n.d.). Structure et dynamique des innovations managériales.
https://www.researchgate.net/publication/285767306
David, A. (1995). RATP: la métamorphose-Réalités et théorie du pilotage du changement.
David, A. (1996). Structure et dynamique des innovations managériales. Cinquième
Conférence de l’AIMS, 1, 1–29.
David, A. (2004). Etudes de cas et généralisation scientifique en sciences de gestion.
XIIIème Conférence de l’AIMS, 1–20.
De vaujany, F.-X. (2006a). Pour une théorie de l’appropriation des outils de gestion : vers
un dépassement de l’opposition conception-usage. Management & Avenir, 9(3), 109.
De Vaujany, F. X. (2005). De la conception à l’usage: vers un management de l’appropriation
des outils de gestion.
De Vaujany, F. X. (2003). Les figures de la gestion du changement sociotechnique.
Sociologie Du Travail, 45(4), 515–536.
Dechamp, G., Goy, H., Grimand, A., & De vaujany, F.-X. (2006). Management stratégique et
dynamiques d’appropriation des outils de gestion : proposition d’une grille de
lecture. Management & Avenir, 9(3), 181.
DeGrace, P., & Stahl, L. H. (1990). Wicked problems, righteous solutions (Vol. 2). Yourdon
Press Upper Saddle River, NJ, USA.
Demers, C. (2003). L’entretien. Conduire Un Projet de Recherche. Une Perspective
Qualitative, 173–210.
DeSanctis, G., & Poole, M. S. (1994). Capturing the complexity in advanced technology use:
Adaptive structuration theory. Organization Science, 5(2), 121–147.
Diegmann, P., Dreesen, T., Binzer, B., & Rosenkranz, C. (2018). Journey Towards Agility :
Three Decades of Research on Agile Information Systems Development. International
Conference on Information Systems, 1–17.
Dikert, K., Paasivaara, M., & Lassenius, C. (2016a). Challenges and success factors for large-
scale agile transformations: A systematic literature review. Journal of Systems and
Software, 119, 87–108.
Dikert, K., Paasivaara, M., & Lassenius, C. (2016b). Challenges and success factors for
large-scale agile transformations: A systematic literature review. Journal of Systems
and Software, 119, 87–108.
DiMaggio, P. J., & Powell, W. W. (1983). The Iron Cage Revisited: Institutional
Isomorphism and Collective Rationality in Organizational Fields. American
Sociological Review, 48(2), 147.
Dingsoeyr, T., Falessi, D., & Power, K. (2019). Agile Development at Scale: The Next
Frontier. IEEE Software, 36(2), 30–38.
Dingsøyr, T., Fægri, T. E., & Itkonen, J. (2014). What Is Large in Large-Scale? A Taxonomy
of Scale for Agile Software Development (pp. 273–276). Springer, Cham.
Dingsøyr, T., Moe, N. B., Fægri, T. E., & Seim, E. A. (2018). Exploring software development
at the very large-scale: a revelatory case study and research agenda for agile method
adaptation. Empirical Software Engineering.
Dingsøyr, T., Moe, N. B., & Seim, E. A. (2018). Coordinating Knowledge Work in Multiteam
Programs: Findings From a Large-Scale Agile Development Program. Project
Management Journal, 49(6), 64–77.
Dingsøyr, T., Moe, N. B., Tonelli, R., Counsell, S., Gencel, C., & Petersen, K. (2014). Agile
methods: Large-scale development, refactoring, testing, and estimation: XP 2014
International Workshops Rome, Italy, May 26-30, 2014 Revised Selected Papers.
Lecture Notes in Business Information Processing, 199.
397
Dingsøyr, T., Nerur, S., Balijepally, V., & Moe, N. B. (2012). A decade of agile methodologies:
Towards explaining agile software development. Journal of Systems and Software,
85(6), 1213–1221.
Drappa, A., & Ludewig, J. (2000). Simulation in software engineering training. Proceedings
of the 22nd International Conference on Software Engineering - ICSE ’00, 199–208.
Drury-Grogan, M. L. (2014). Performance on agile teams: Relating iteration objectives and
critical decisions to project management success factors. Information and Software
Technology, 56(5).
Drury, M., Conboy, K., & Power, K. (2012). Obstacles to decision making in Agile software
development teams. Journal of Systems and Software, 85(6), 1239–1254.
Dubouloz, S. (2014). L’innovation organisationnelle : antécédents et complémentarité : une
approche intégrative appliquée au Lean Management. https://tel.archives-
ouvertes.fr/tel-00944182
Dumez, H. (2011). Qu’est-ce que la recherche qualitative ? Le Libellio d’AEGIS, 7(4), 47–58.
Dumez, H., & Rigaud, E. (2008). Comment passer du matériau de recherche à l’analyse
théorique ? A propos de la notion de template. Le Libellio d’AEGIS, 4, 2.
Dwivedi, R. (2013). Configuration Issues and Efforts for Configuring Agile Approaches-
Situational based Method Engineering. International Journal of Computer
Applications, 61(17), 23–27.
Dyba, T., & Dingsoyr, T. (2009). What Do We Know about Agile Software Development?
IEEE Software, 26(5), 6–9.
Ebert, C. (2014). Software product management. IEEE Software, 31(3), 21–24.
Eckstein, J. (2014). Architecture in Large Scale Agile Development (pp. 21–29).
Eisenhardt, K. (2002). Building theories from case study research. 14(4), 532–550.
http://www.ncbi.nlm.nih.gov/entrez/query.fcgi?db=pubmed&cmd=Retrieve&dopt
=AbstractPlus&list_uids=9908641197695205027
Eisenhardt, K. M. (1989). Building Theories from Case Study Research. The Academy of
Management Review, 14(4), 532.
Erickson, J., Lyytinen, K., & Siau, K. (2005). Agile modeling, agile software development,
and extreme programming: The state of research. In Journal of Database Management
(Vol. 16, Issue 4, p. 88). IGI Publishing.
Evan, W. M. (1966). The organization-set: Toward a theory of interorganizational
relations. Approaches to Organizational Design, 173–191.
Fitzgerald, B. (1996). Formalized systems development methodologies: A critical
perspective. In Information Systems Journal (Vol. 6, Issue 1, pp. 3–23). Blackwell
Publishing Ltd.
Forsberg, K., & Mooz, H. (1996). The Relationship of System Engineering to the Project
Cycle. The 12th INTERNET World Congress on Project Management, 10(8).
Gandomani, T. J., Zulzalil, H., Abdul Ghani, A. A., Abu, A. B., & Parizi, R. M. (2015). The
impact of inadequate and dysfunctional training on agile transformation process: A
grounded theory study. Information and Software Technology, 57(1), 295–309.
Gandomani, T. J., Zulzalil, H., Ghani, A. A. A., Sultan, A. B. M., & Nafchi, M. Z. (2013).
Obstacles in moving to agile software development methods; At a Glance. Journal of
Computer Science, 9(5), 620–625.
Gandomani, T. J., Zulzalil, H., & Nafchi, M. Z. (2014). Agile transformation: What is it about?
2014 8th Malaysian Software Engineering Conference, MySEC 2014, 240–245.
Gareis, R. (1994). Management by Projects: Specific Strategies, Structures and Cultures of
Project-Oriented Company. Global Project Management Handbook, Edited by Cleland,
DI and Gareis.
398
Garel, G. (2003). Pour une histoire de la gestion de projet. Gérer et Comprendre, 74(1), 77–
89.
Garel, G. (2011). Le management de projet. 128.
Garel, G. (2013). A history of project management models: From pre-models to the
standard models. International Journal of Project Management, 31(5), 663–669.
Gauld, R. (2007). Public sector information system project failures: Lessons from a New
Zealand hospital organization. Government Information Quarterly, 24(1), 102–114.
Gill, A. Q., Henderson-Sellers, B., & Niazi, M. (2018). Scaling for agility: A reference model
for hybrid traditional-agile software development methodologies. Information
Systems Frontiers, 20(2), 315–341.
Gioia, D. A., Corley, K. G., & Hamilton, A. L. (2013). Seeking qualitative rigor in inductive
research: Notes on the Gioia methodology. Organizational Research Methods, 16(1),
15–31.
Girin, J. (1983). Les situations de gestion. CRG Ecole Polytechnique: Non Publié.
Girin, J. (1989). L’opportunisme méthodique dans les recherches sur la gestion des
organisations. Communication à La Journée d’étude La Recherche Action En Action et
En Question, AFCET, Collège de Systémique, Ecole Centrale de Paris.
Giroux, N. (2003). L’étude de cas. Conduire Un Projet de Recherche: Une Perspective
Qualitative, 41.
Giuliani, P., Robert, M., & Roy, F. Le. (2018). Reinvention of management innovation for
successful implementation. International Journal of Entrepreneurship and Small
Business, 34(3), 343.
Glass, R. L. (1994). The Software-Research Crisis. IEEE Software, 11(6), 42–47.
Goldratt, E. M. (1990). Theory of constraints. North River Croton-on-Hudson.
Gopalakrishnan, S., & Damanpour, F. (1997). A review of innovation research in
economics, sociology and technology management. Omega, 25(1), 15–28.
Grimand, A. (2016). La prolifération des outils de gestion : quel espace pour les acteurs
entre contrainte et habilitation ? Recherches En Sciences de Gestion, 112(1), 173.
Gupta, R. K., Venkatachalapathy, M., & Jeberla, F. K. (2019). Challenges in Adopting
Continuous Delivery and DevOps in a Globally Distributed Product Team: A Case
Study of a Healthcare Organization. Proceedings - 2019 ACM/IEEE 14th International
Conference on Global Software Engineering, ICGSE 2019, 30–34.
Gustavsson, T. (2017). Assigned roles for inter-team coordination in large-scale agile
development: A literature review. ACM International Conference Proceeding Series,
Part F1299, 1–5.
Gwanhoo Lee and Weidong Xia. (2010). Toward Agile: An Integrated Analysis of
Quantitative and Qualitative Field Data on Software Development Agility Availability:
In stock. Management Informations System Quarterly, 34(1), 87–114.
http://misq.org/toward-agile-an-integrated-analysis-of-quantitative-and-
qualitative-field-data.html?SID=ki4d5pqlp5t33ji94bbdjt51a4
Hajjdiab, H., & Taleb, A. S. (2011). Agile adoption experience: A case study in the U.A.E.
ICSESS 2011 - Proceedings: 2011 IEEE 2nd International Conference on Software
Engineering and Service Science, 31–34.
Hamel, G. (n.d.). The Why, What, and How of Management Innovation.
https://hbr.org/2006/02/the-why-what-and-how-of-management-
innovation[18/07/201818:11:46]ORGANIZATIONALCULTURE
Hatchuel, A. (1996). Coopération et conception collective. Variété et crises des rapports
de prescription. Coopération et Conception, 101–122.
Hatchuel, A., & Molet, H. (1986). Rational modelling in understanding and aiding human
399
decision-making: About two case studies. European Journal of Operational Research,
24(1), 178–186.
Hatchuel, A., & Weill, B. (1992). L’expert et le système : gestion des savoirs et
métamorphose des acteurs dans l’entreprise industrielle suivi de quatre histoires de
systèmes-experts. In Economica.
Hatchuel Armand, W. B. (1994). L’expert et le système, suivi de quatre histoires de
systèmes-experts. Revue Française de Sociologie, 35(1), 137–139.
Hemon, A., Monnier-Senicourt, L., & Rowe, F. (2018). Job Satisfaction Factors and Risks
Perception : An embedded case study of DevOps and Agile Teams. Thirty Ninth
International Conference on Information Systems, San Francisco 2018, 1–17.
Hemon, Aymeric, & Rowe, F. (2019). From Agile to DevOps : Smart Skills and
Collaborations.
Hernes, T. (2014). A process theory of organization. OUP Oxford.
Highsmith, J. (2002). Agile Software Development. In Computer Science Education (Vol. 12,
Issue 3).
Highsmith, J., & Cockburn, A. (2001). Agile software development: The business of
innovation. Computer, 34(9), 120–127.
Hlady-Rispal, M. (2000). L’étude de cas: une stratégie de recherche en gestion. Revue
Française de Gestion, 127, 61–70.
Hobbs, B., & Petit, Y. (2016). Agile Methods on Large Projects in Large Organizations. In
EURAM Conference.
Hobbs, B., & Petit, Y. (2017). Agile Methods on Large Projects in Large Organizations.
Project Management Journal, 48(3), 3–19.
Hoda, R. (2011). Self-Organizing Agile Teams : A Grounded Theory. In Learning.
http://hdl.handle.net/10063/1617
Hoda, R., Kruchten, P., Noble, J., & Marshall, S. (2010). Agility in context. ACM SIGPLAN
Notices.
Hoda, R., & Murugesan, L. K. (2016a). Multi-level agile project management challenges: A
self-organizing team perspective. Journal of Systems and Software.
Hoda, R., & Noble, J. (2017). Becoming agile: a grounded theory of agile transitions in
practice. Proceedings of the 39th International Conference on Software Engineering,
141–151.
Hughes, D. L., Dwivedi, Y. K., Rana, N. P., & Simintiras, A. C. (2016). Information systems
project failure–analysis of causal links using interpretive structural modelling.
Production Planning & Control, 27(16), 1313–1333.
Hummel, M. (2014). State-of-the-art: A systematic literature review on agile information
systems development. Proceedings of the Annual Hawaii International Conference on
System Sciences, 4712–4721.
Hummel, M., Rosenkranz, C., & Holten, R. (2013). The role of communication in agile
systems development: An analysis of the state of the art. Business and Information
Systems Engineering, 5(5), 343–355.
Humphrey, W. S. (2002). Three process perspectives: Organizations, teams, and people.
In Annals of Software Engineering (Vol. 14, Issues 1–4, pp. 39–72).
Hussenot, A., & Missonier, S. (2016). Encompassing Stability and Novelty in Organization
Studies: An Events-based Approach. Organization Studies, 37(4), 523–546.
Iacovelli, A., & Souveyet, C. (2008). Framework for Agile Methods Classification. MoDISE-
EUS, 91–102.
Iivari, J. (1987). A hierarchical spiral model for the software process. ACM SIGSOFT
Software Engineering Notes, 12(1), 35–37.
400
Iivari, Juhani, & Iivari, N. (2011). The relationship between organizational culture and the
deployment of agile methods. Information and Software Technology, 53(5), 509–520.
Inayat, I., Salim, S. S., Marczak, S., Daneva, M., & Shamshirband, S. (2015a). A systematic
literature review on agile requirements engineering practices and challenges. In
Computers in Human Behavior (Vol. 51).
Inayat, I., Salim, S. S., Marczak, S., Daneva, M., & Shamshirband, S. (2015b). A systematic
literature review on agile requirements engineering practices and challenges. In
Computers in Human Behavior.
Jalali, S., & Wohlin, C. (2010). Agile practices in global software engineering - A systematic
map. Proceedings - 5th International Conference on Global Software Engineering,
ICGSE 2010, 45–54.
Javdani Gandomani, T., & Ziaei, M. (2014). Agility Assessment Model to Measure Agility
Degree of Agile Software Companies. Indian Journal of Science and Technology, 7(7),
955–959.
Javdani Gandomani, T., & Ziaei Nafchi, M. (2015). An empirically-developed framework
for Agile transition and adoption: A Grounded Theory approach. Journal of Systems
and Software, 107, 204–219.
Journé, B. (2012). L’observation. Méthodologies de La Recherche. Réussir Son Mémoire Ou
Sa Thèse En Sciences de Gestion. Montreuil: Pearson Education.
Judd, T. W. (2000). A History of Modern Computing. History: Reviews of New Books, 28(3),
101–101.
Kahkonen, T. (2004). Agile Methods for Large Organizations - Building Communities of
Practice. 2–11.
Kalenda, M., Hyna, P., & Rossi, B. (2018). Scaling agile in large organizations: Practices,
challenges, and success factors. Journal of Software: Evolution and Process, 30(10), 1–
24.
Karlstrom, D., & Runeson, P. (2005). Combining Agile Methods with Stage-Gate Project
Management. IEEE Software, 22(3), 43–49.
Kettunen, P., & Laanti, M. (2008). Combining agile software projects and large-scale
organizational agility. Software Process Improvement and Practice.
Keupp, M. M., Palmié, M., & Gassmann, O. (2011). Achieving subsidiary integration in
international innovation by managerial “tools.” Management International Review,
51(2), 213–239.
Khalil, C., Fernandez, V., & Houy, T. (2013). Can Agile Collaboration Practices Enhance
Knowledge Creation Between Cross-Functional Teams? Advances in Intelligent
Systems and Computing, 205 AISC(January).
Kiely, G., Kiely, J., & Nolan, C. (2017). Scaling Agile Methods to Process Improvement
Projects: A Global Virtual Team Case Study. AMCIS 2017 Proceedings.
http://aisel.aisnet.org/amcis2017/ITProjMgmt/Presentations/13
Kimberly, J. R., & Evanisko, M. J. (1981a). Organizational innovation: The influence of
individual, organizational, and contextual factors on hospital adoption of
technological and administrative innovations. Academy of Management Journal,
24(4), 689–713.
Kimberly, J. R., & Evanisko, M. J. (1981b). Organizational Innovation: The Influence of
Individual, Organizational, and Contextual Factors on Hospital Adoption of
Technological and Administrative Innovations. Academy of Management Journal,
24(4), 689–713.
Kirk, J., Miller, M. L., & Miller, M. L. (1986). Reliability and validity in qualitative research
(Vol. 1). Sage.
401
Klein, K. J., & Sorra, J. S. (1996). The challenge of innovation implementation. Academy of
Management Review, 21(4), 1055–1080.
Kniberg, H. (2012). Spotify - Scaling Agile. 1–14.
https://dl.dropboxusercontent.com/u/1018963/Articles/SpotifyScaling.pdf
Koenig, G. (2006). Théories mode d’emploi. Revue Française de Gestion, 1, 9–27.
Kruchten, P. (2004). Scaling down large projects to meet the agile “sweet spot.” Rational
Edge, August, 1–14.
http://www.ibm.com/developerworks/rational/library/content/RationalEdge/au
g04/TheRationalEdge_August2004.pdf
Laanti, M. (2008). Implementing program model with agile principles in a large software
development organization. Proceedings - International Computer Software and
Applications Conference, 1383–1391.
Laanti, M., Salo, O., & Abrahamsson, P. (2011). Agile methods rapidly replacing traditional
methods at Nokia: A survey of opinions on agile transformation. Information and
Software Technology, 53(3), 276–290.
Lacity, M. C., Willcocks, L. P., Lacity, M. C., & Willcocks, L. P. (2009). Outsourcing Research:
Towards More Informed Practice. In Information Systems and Outsourcing. Palgrave
Macmillan UK.
Langley, A. (1999). Strategies for Theorizing from Process DataLangley, A. (1999).
Strategies for Theorizing from Process Data. The Academy of Management Review,
24(4), 691. doi:10.2307/259349. The Academy of Management Review, 24(4), 691–
710.
Langley, A., & Royer, I. (2006). Perspectives on doing case study research in organizations.
M@ N@ Gement, 9(3), 81–94.
Langley, A., Smallman, C., Tsoukas, H., & Van De Ven, A. H. (2013). Process studies of
change in organization and management: Unveiling temporality, activity, and flow.
Academy of Management Journal, 56(1), 1–13.
Larman, C. (2004). Agile and iterative development: a manager’s guide. Addison-Wesley
Professional.
Larman, C., & Basili, V. R. (2003). Iterative and incremental developments. a brief history.
Computer, 36(6), 47–56.
Le Masson, P., & Weil, B. (2008). La domestication de la conception par les entreprises
industrielles: l’invention des bureaux d’étude. Les Nouveaux Régimes de La
Conception. Langages, Théories, Métiers, Vuibert, Colloques de Cerisy, 51–66.
Le Roy, F., Robert, M., & Guiliani, P. (2013). L’innovation managériale. Généalogie, défis et
perspectives. Revue Française de Gestion.
Lee, S., & Yong, H. S. (2010). Distributed agile: Project management in a global
environment. Empirical Software Engineering, 15(2), 204–217.
Leffingwell, D. (2007). Scaling Software Agility: Best Practices for Large Enterprises-.
Lei, H., Ganjeizadeh, F., Jayachandran, P. K., & Ozcan, P. (2017). A statistical analysis of the
effects of Scrum and Kanban on software development projects. Robotics and
Computer-Integrated Manufacturing, 43, 59–67.
Lenfle, S. (2014). ScienceDirect Toward a genealogy of project management : Sidewinder
and the management of exploratory projects. JPMA.
Lindvall, M., Basili, V., Boehm, B., Costa, P., Dangle, K., Shull, F., Tesoriero, R., Williams, L.,
& Zelkowitz, M. (2002). Empirical Findings in Agile Methods. 197–207.
Lorino, P. (2002). Vers une théorie pragmatique et sémiotique des outils appliquée aux
instruments de gestion. Essec Research Center, DR‑02015.
http://pfleurance.hautetfort.com/list/seminaire-7-l-intelligence-strategique-en-
402
gestion/4140115640.pdf
Luo, W., & Strong, D. M. (2004). A framework for evaluating ERP implementation choices.
IEEE Transactions on Engineering Management, 51(3), 322–333.
Lyytinen, K., & Rose, G. M. (2006). Information system development agility as
organizational learning. European Journal of Information Systems, 15(2), 183–199.
Maggio, P. J. Di, & Powell, W. W. (2018). Le néo-institutionnalisme dans l ’ analyse des
organisations. 10, 113–154.
Mahanti, A. (2007). Challenges in Enterprise Adoption of Agile Methods - A Survey. Journal
of Computing and Information Technology, 14(3), 197–206.
Mann, C., & Maurer, F. (2005). A case study on the impact of scrum on overtime and
customer satisfaction. Proceedings - AGILE Confernce 2005, 2005, 70–79.
Martineau, R. (2017). De quoi les outils de gestion sont-ils faits ? La structure « listique »
des artefacts de gestion. M@n@gement, 20(3), 239.
Mathiassen, L., & Pries-Heje, J. (2006). Business agility and diffusion of information
technology. European Journal of Information Systems, 15(2), 116–119.
McAvoy, J., & Butler, T. (2009). The role of project management in ineffective decision
making within agile software development projects. European Journal of Information
Systems, 18(4), 372–383.
Mckeen, J. D., Guimaraes, T., & Wetherbe, J. C. (1994). Four Contingency Factors Between
User User Satisfaction : An. 18(4), 427–451.
McMahon, P. E. (2005). Extending agile methods: A distributed project and organizational
improvement perspective. CrossTalk, 5, 16–19. www.stsc.hill.af.mil
McMillan, E. (2002). Considering organisation structure and design from a complexity
paradigm perspective. Tackling Industrial Complexity: The Ideas That Make a
Difference.University of Cambridge: Institute of Manufacturing, 1994.
Mendez, A. (2010). Processus. Concepts et méthode pour l’analyse temporelle en sciences
sociales. Academia-Bruylant.
Midler, C. (1998). L’auto qui n’existait pas. Management des projets et transformation de
l’entreprise. In Stratégie Management. https://www.dunod.com/entreprise-
economie/auto-qui-n-existait-pas-management-projets-et-transformation-
entreprise
Midler, C. (2008). Évolution des modèles d ’ organisation et régulations économiques de la
conception To cite this version : HAL Id : hal-00263245.
Midler, C. (2012). L’Auto qui n’existait pas: Management des projets et transformation de
l’entreprise. Dunod.
Mikalsen, M., Moe, N. B., Stray, V., & Nyrud, H. (2018). Agile Digital Transformation : A Case
Study of Interdependencies. Thirty Ninth International Conference on Information
Systems, 1–9.
Miles, M. B., & Huberman, A. M. (2003). Analyse des données qualitatives. De Boeck
Supérieur.
Mintzberg, A., & Ahlstrand, B. (1999). Lampel (1998) Strategy Safari. Harlow: Prentice
Hall.
Mintzberg, H. (1980). Structure in 5’s: A Synthesis of the Research on Organization Design.
Management Science, 26(3), 322–341.
Moe, N. B., Olsson, H. H., & Dingsøyr, T. (2016). Trends in Large-Scale Agile Development:
A Summary of the 4th Workshop at XP2016. Proceedings of the Scientific Workshop
Proceedings of XP2016 on - XP ’16 Workshops.
Mol, M. J., & Birkinshaw, J. (2009). The sources of management innovation: When firms
introduce new management practices. Journal of Business Research, 62(12), 1269–
403
1280.
Mol, Michael J., & Birkinshaw, J. (2009). The sources of management innovation: When
firms introduce new management practices. Journal of Business Research, 62(12),
1269–1280.
Moore, E., & Spens, J. (2008). Scaling agile: Finding your agile tribe. Proceedings - Agile
2008 Conference, 121–124.
Moyon, E. (2011). Le changement du business model de l’entreprise: une étude des majors
de l’industrie phonographique (1998-2008). Lille 1.
Musca, G. (2006). Une stratégie de recherche processuelle : l’étude longitudinale de cas
enchâssés. M@n@gementgement, 9(3), 153–176.
Naur, P., & Randell, B. (1968). Software Engineering: Report of a conference sponsored by
the NATO. In Science Committee, Garmisch, Germany, 7-11 Oct. 1968, Brussels,
Scientific Affairs Division, NATO (1969).
Navarre, C. (1993). Pilotage stratégique de la firme et gestion des projets: de Ford et Taylor
à AGILE et IMS.
Nerur, S., & Balijepally, V. G. (2007). Theoretical reflections on agile development
methodologies. Communications of the ACM, 50(3), 79–83.
Nerur, S., Mahapatra, R., & Mangalaraj, G. (2005a). Challenges of migrating to agile
methodologies. Communications of the ACM, 48(5), 72–78.
Nerur, S., Mahapatra, R., & Mangalaraj, G. (2005b). Challenges of migrating to agile
methodologies. Communications of the ACM, 48(5), 72–78.
Nerur, S., & Moe, N. B. (2012). A decade of agile methodologies: Towards explaining agile
software development. In Journal of Systems and Software (Vol. 85, Issue 6, pp. 1213–
1221).
Notkin, D., Cheng, B. H. C., Pohl, K., IEEE Computer Society., & Institute of Electrical and
Electronics Engineers. (2013). Agility at scale: economic governance, measured
improvement, and disciplined delivery. Proceedings of the 2013 International
Conference on Software Engineering, 873–881.
Oiry, E., Bidart, C., Brochier, D., Garnier, J., Gilson, A., Longo, M.-E., Mendez, A., Mercier, D.,
Pascal, A., Perocheau, G., & Tchobanian, R. (2010). Propositions pour un cadre
théorique unifié et une méthodologie d’analyse des trajectoires des projets dans les
organisations. Management & Avenir, 36(6), 84.
Olszewska, M., Heidenberg, J., Weijola, M., Mikkonen, K., & Porres, I. (2016). Quantitatively
measuring a large-scale agile transformation. Journal of Systems and Software.
Orlikowski, W. J. (2000). Managing use not technology: a view from the trenches.
Mastering Information Management. London: Prentice-Hall.
Paasivaara, M. (2017). Adopting SAFe to scale agile in a globally distributed organization.
Proceedings - 2017 IEEE 12th International Conference on Global Software
Engineering, ICGSE 2017, 36–40.
Paasivaara, M., Behm, B., Lassenius, C., & Hallikainen, M. (2014). Towards rapid releases
in large-scale XaaS development at Ericsson: A case study. Proceedings - 2014 IEEE
9th International Conference on Global Software Engineering, ICGSE 2014, 16–25.
Paasivaara, M., Behm, B., Lassenius, C., & Hallikainen, M. (2018). Large-scale agile
transformation at Ericsson: a case study. Empirical Software Engineering, 1–47.
Paasivaara, M., Durasiewicz, S., & Lassenius, C. (2008). Distributed agile development:
Using Scrum in a large project. Proceedings - 2008 3rd IEEE International Conference
Global Software Engineering, ICGSE 2008, 87–95.
Paasivaara, M., Heikkila, V. T., & Lassenius, C. (2012). Experiences in Scaling the Product
Owner Role in Large-Scale Globally Distributed Scrum. 2009 16th Annual IEEE
404
International Conference and Workshop on the Engineering of Computer Based
Systems, 174–178.
Paasivaara, M., & Lassenius, C. (2006). Could global software development benefit from
agile methods? Proceedings - 2006 IEEE International Conference on Global Software
Engineering, ICGSE 2006, 109–113.
Paasivaara, M., & Lassenius, C. (2014). Communities of practice in a large distributed agile
software development organization - Case Ericsson. Information and Software
Technology.
Paasivaara, M., & Lassenius, C. (2016a). Scaling scrum in a large globally distributed
organization: A case study. Proceedings - 11th IEEE International Conference on Global
Software Engineering, ICGSE 2016, 74–83.
Paasivaara, M., & Lassenius, C. (2016b). Challenges and success factors for large-scale
agile transformations - A research proposal and a pilot study. ACM International
Conference Proceeding Series, 24-May-201, 1–5.
Paasivaara, M., Lassenius, C., Heikkilä, V. T., Dikert, K., & Engblom, C. (2013). Integrating
global sites into the lean and agile transformation at Ericsson. Proceedings - IEEE 8th
International Conference on Global Software Engineering, ICGSE 2013.
Paasivaara, M., Väättänen, O., Hallikainen, M., & Lassenius, C. (2014). Supporting a large-
scale lean and agile transformation by defining common values. Lecture Notes in
Business Information Processing, 199, 73–82.
Palmer, S., & Felsing, J. (2002). A Practical Guide to Feature-Driven Development.
Paluch, S., Antons, D., Brettel, M., Hopp, C., Salge, T.-O., Piller, F., & Wentzel, D. (2019).
Stage-gate and agile development in the digital age: Promises, perils, and boundary
conditions. Journal of Business Research, xxxx, 0–1.
Paraponaris, C., & Gilda, S. (2006). DIFFUSION DES CONNAISSANCES ET OUTILS DE
GESTION Lavoisier | « Revue française de gestion » 2006/7 n. Revue Française de
Gestion, 166, 69–92.
Peter, S. (1990). The fifth discipline. The Art & Practice of Learning Organization.
Doupleday Currence, New York.
Pettigrew, A. M. (1985). Contextualist research and the study of organizational change
processes. Research Methods in Information Systems, 1, 53–78.
Pettigrew, A. M. (1995). Longitudinal field research on change. Longitudinal Field Research
Methods. Thousand Oaks, CA: SAGE Publications, 91–125.
Pettigrew, A. M. (2001). Studying Organizational Change and Development : Challenges
for Future Research Author ( s ): Andrew M . Pettigrew , Richard W . Woodman and
Kim S . Cameron Published by : Academy of Management Stable URL :
http://www.jstor.org/stable/3069411 REFERENCES L. Academy of Management
Journal, 44(4), 697–713.
Pikkarainen, M., Salo, O., Kuusela, R., & Abrahamsson, P. (2012). Strengths and barriers
behind the successful agile deployment-insights from the three software intensive
companies in Finland. Empirical Software Engineering, 17(6), 675–702.
Pinto, J. K., & Mantel, S. J. (1990). The Causes of Project Failure. IEEE Transactions on
Engineering Management, 37(4), 269–276.
Poole, M. S., & Van de Ven, A. H. (2004). Central issues in the study of change and
innovation. Handbook of Organizational Change and Innovation, 3, 31.
Popper, K. (1995). Karl Popper: philosophy and problems (Vol. 39). Cambridge University
Press.
Port, D., & Bui, T. (2009a). Simulating mixed agile and plan-based requirements
prioritization strategies: Proof-of-concept and practical implications. European
405
Journal of Information Systems, 18(4), 317–331.
Port, D., & Bui, T. (2009b). Simulating mixed agile and plan-based requirements
prioritization strategies: Proof-of-concept and practical implications. European
Journal of Information Systems, 18(4), 317–331.
Powell, W. W., & DiMaggio, P. J. (2012). The new institutionalism in organizational analysis.
University of Chicago press.
Quinn, J. B. (1980). Strategies for change: Logical incrementalism. Irwin Professional
Publishing.
Qumer, A., & Henderson-Sellers, B. (2008a). A framework to support the evaluation,
adoption and improvement of agile methods in practice. Journal of Systems and
Software, 81(11), 1899–1919.
Qumer, A., & Henderson-Sellers, B. (2008b). A framework to support the evaluation,
adoption and improvement of agile methods in practice. Journal of Systems and
Software, 81(11), 1899–1919.
Rasnacis, A., & Berzisa, S. (2017). Method for Adaptation and Implementation of Agile
Project Management Methodology. Procedia Computer Science, 104, 43–50.
Recker, J., Holten, R., Hummel, M., & Rosenkranz, C. (2017). How Agile Practices Impact
Customer Responsiveness and Development Success: A Field Study. Project
Management Journal, 48(2), 99–121.
Reifer, D. J., Maurer, F., & Erdogmus, H. (2003). Scaling agile methods. IEEE Software,
20(4), 12–14.
Reix, R., Fallery, B., Kalika, M., & Rowe, F. (2016). Systèmes d’Information et Management
des Organisations-7ème édition.
Rico, D. F., Sayani, H. H., & Field, R. F. (2008). History of Computers, Electronic Commerce
and Agile Methods. Advances in Computers, 73, 1–55.
Rigby, D. K., Sutherland, J., & Takeuchi, H. (2016). The Secret History of Agile Innovation.
Harvard Business Review, 7. https://hbr.org/2016/04/the-secret-history-of-agile-
innovation
Riveill, M. (2000). Programmation par composants. Ed. Techniques Ingénieur.
Robey, D., & Farrow, D. (1982). User Involvement in Information System Development - a
Conflict Model and Empirical Test. Management Science, 28(1), 73–85.
Rogers, E. M. (1995). Diffusion of Innovations: modifications of a model for
telecommunications. In Die diffusion von innovationen in der telekommunikation (pp.
25–38). Springer.
Rogers, E. M. (2003). The innovation-decision process. Diffusion of Innovations, 5, 168–
218.
Rohunen, A., Rodriguez, P., Kuvaja, P., Krzanik, L., & Markkula, J. (2010). Approaches to
agile adoption in large settings: A comparison of the results from a literature analysis
and an industrial inventory. Lecture Notes in Computer Science (Including Subseries
Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics), 6156
LNCS, 77–91.
Rolland, K. H., Fitzgerald, B., Dingsoyr, T., & Stol, K.-J. (2016). Problematizing Agile in the
Large : Alternative Assumptions for Large - Scale Agile Development. ICIS -
International Conference on Information Systems, Ambler 2014, 1–21.
Rouquet, A. (2009). Contextualisation interne et externe des outils de gestion : un
enrichissement des travaux d’Albert David. Association Internationale de
Management Stratégique.
Royce, W. (1970). Managing the Development of Large Software Systems. In: The
Proceedings of the WESCON. San Francisco. IEEE CS, August.
406
Ruparelia, N. B. (2010). Software development lifecycle models. ACM SIGSOFT Software
Engineering Notes, 35(3), 8.
Schwaber, K. (1997). Scrum development process. In Business object design and
implementation. Springer, April 1987, 117–134.
Schwaber, K., & Beedle, M. (2002). Agile software development with Scrum (Vol. 1).
Prentice Hall Upper Saddle River.
Segrestin, B. (2004). Les partenariats d’exploration: des pratiques inédites en quête
d’outils et de statuts. Centre de Gestion Scientifique, Ecole Des Mines de Paris.
Serrador, P., & Pinto, J. K. (2015). Does Agile work? - A quantitative analysis of agile project
success. International Journal of Project Management, 33(5), 1040–1051.
Shastri, Y., Hoda, R., & Amor, R. (2017). Understanding the Roles of the Manager in Agile
Project Management.
Sidky, A., Arthur, J., & Bohner, S. (2007). A disciplined approach to adopting agile
practices: the agile adoption framework. Innovations in Systems and Software
Engineering, 3(3), 203–216.
Smeds, J., Nybom, K., & Porres, I. (2015). DevOps: A Definition and Perceived Adoption
Impediments. Lecture Notes in Business Information Processing, 212, 166–177.
Sommerville, I. (1996). Software Process Models. Article in ACM Computing Surveys.
Soundararajan, S., & Arthur, J. D. (2009). A soft-structured agile framework for larger scale
systems development. Proceedings of the International Symposium and Workshop on
Engineering of Computer Based Systems, 187–195.
Špundak, M. (2014). Mixed Agile/Traditional Project Management Methodology – Reality
or Illusion? Procedia - Social and Behavioral Sciences, 119, 939–948.
Ståhl, D., & Bosch, J. (2014). Modeling continuous integration practice differences in
industry software development. Journal of Systems and Software, 87(1), 48–59.
Stake, R. E. (1995). The art of case study research. Sage.
Stettina, C. J., & Hörz, J. (2015). Agile portfolio management: An empirical perspective on
the practice in use. International Journal of Project Management, 33(1), 140–152.
Sutherland, J. (2001a). Agile Can Scale: Inventing and Reinventing SCRUM in Five
Companies. Cutter IT Journal, 14(12), 5–11.
Sutherland, J. (2001b). Inventing and Reinventing SCRUM in Five Companies. Cutter IT
Journal, 14(21 September), 5–11.
Svahnberg, M., Gorschek, T., Feldt, R., Torkar, R., Saleem, S. Bin, & Shafique, M. U. (2010).
A systematic review on strategic release planning models. In Information and
Software Technology (Vol. 52, Issue 3, pp. 237–248).
Sweis, R. J., Abuhussein, R., Jandali, D., Mashaleh, M., & Al-Debei, M. (2018). Factors
affecting ERP projects from a project management perspective: A literature review.
International Journal of Business Information Systems, 29(3), 281–296.
Takeuchi, H., & Nonaka, I. (1986). The New New Product Development Game. Harvard
Business Review, 64(1), 137–146.
Teece, D. J. (1980). The diffusion of an administrative innovation. Management Science,
26(5), 464–470.
The Standish Group. (2016). Standish CHAOS Summary Report 2016. 1–9.
Thietart, R.-A. (2014). Méthodes de recherche en management. Paris, Dunod.
Tichy, N. M. (1983). Managing strategic change: Technical, political, and cultural dynamics
(Vol. 3). John Wiley & Sons.
Tornatzky, L. G., Fleischer, M., & Chakrabarti, A. K. (1990). Processes of technological
innovation. Lexington books.
Tran, S., (2014). Quelle contribution des technologies collaboratives à la configuration des
407
organisations ? Systèmes d’Information et Management (French Journal of
Management Information Systems), 19(2).
Tripp, J. F., & Armstrong, D. J. (2014). Exploring the relationship between organizational
adoption motives and the tailoring of agile methods. Proceedings of the Annual Hawaii
International Conference on System Sciences, 4799–4806.
Tsoukas, H. (1989). The Validity Idiographic Explanations. The Academy of Management
Review, 14(4), 551–561.
Vaccaro, I. G., Jansen, J. J. P., Van Den Bosch, F. A. J., & Volberda, H. W. (2012). Management
innovation and leadership: The moderating role of organizational size. Journal of
Management Studies, 49(1), 28–51.
Van De Ven, A. H. (1986). Central Problems in the Management of Innovation. Source:
Management Science, 32(5), 590–607.
Van de Ven, A. H., Angle, H. L., & Poole, M. S. (2000). Research on the management of
innovation: The Minnesota studies. Oxford University Press on Demand.
Van de Ven, A. H., & Poole, M. S. (1995). Explaining development and change in
organizations. Academy of Management Review, 20(3), 510–540.
Van Waardenburg, G., & Van Vliet, H. (2013). When agile meets the enterprise. Information
and Software Technology, 55(12), 2154–2171.
Verner, J. M., & Abdullah, L. M. (2012). Exploratory case study research: Outsourced
project failure. Information and Software Technology, 54(8), 866–886.
Versionone. (2016). The 11th annual State of Agile Report. In Journal of the ICRU.
VersionOne 12th Annual State of Agile Report. (2018). t
Vijayasarathy, L. R., & Turk, D. (2008). Agile software development: A survey of early
adopters. Journal of Information Technology Management, XIX(2), 1–8.
http://www.aom-iaom.org/jitm_pdfs/jitm_08/article3.pdf
Vijayasarathy, L., & Turk, D. (2012). Drivers of agile software development use: Dialectic
interplay between benefits and hindrances. Information and Software Technology,
54(2), 137–148.
Vodde, B., & Larman, C. (2014). LeSS framework. The LeSS Company BV.
Vohra, P., & Singh, A. (2013). A Contrast and Comparison of Modern Software Process
Models. International Journal of Computer Applications®, 0975(8887), 23.
Wang, X., Conboy, K., & Cawley, O. (2012). “Leagile” software development: An experience
report analysis of the application of lean approaches in agile software development.
Journal of Systems and Software, 85(6), 1287–1299.
Wateridge, J. (1995). IT projects : a basis for success. 169–172.
Weick, K. E., Weick, K. E., Quinn, R. E., & Quinn, R. E. (1999). Organizational change and
development. Annual Review of Psychology, 50, 361–386.
Wischnevsky, J. D., & Damanpour, F. (2006). Organizational Transformation and
Performance: An Examination of Three Perspectives. Source: Journal of Managerial
Issues, 18(1), 104–128.
Wolfe, R. A. (1994). Organizational innovation: Review, critique and suggested research
directions. Journal of Management Studies, 31(3), 405–431.
Xia, W., & Lee, G. (2005). Complexity of information systems development projects:
Conceptualization and measurement development. Journal of Management
Information Systems, 22(1), 45–83.
Yin, R. K. (2014). Design and methods. Case Study Research, 5.
Yin, R. K. (1994). Discovering the future of the case study. Method in evaluation research.
Evaluation practice, 15(3), 283-290.
Zbaracki, M. J. (1998). The rhetoric and reality of total quality management.
408
Administrative Science Quarterly, 602–636.
409
Liste des figures
410
Figure 33 : Matrice chronologique des séquences d’ingrédients .......................................183
Figure 34 : Template illustrant le passage d’une séquence à l’autre par une bifurcation
...........................................................................................................................................................................183
Figure 35 : Séparation des équipes dans la DSI ........................................................................199
Figure 36 : Modélisation de la bifurcation 1...............................................................................204
Figure 37 : Présentation des frictions entre les équipes de développement et les
équipes infrastructures de la DSI 1................................................................................................207
Figure 38 : Deuxième bifurcation dans la trajectoire de généralisation de Scrum. ....210
Figure 39 : Objectifs du programme de transformation agile at scale .............................217
Figure 40 : Modèle d’agilité à l’échelle développé au sein de la DSI 1..............................218
Figure 41 : Processus d’identification des features teams dans la DSI 1 ........................222
Figure 42 : Indicateurs de satisfaction mis en place pour le programme de
transformation .......................................................................................................................................222
Figure 43 : Jonction entre les équipes de développement (feature teams) et les
opérateurs d’infrastructures (Ops ou platform teams dans la figure). ............................230
Figure 44 : Mise en place des trains SAFe dans les équipes européennes de la DSI 3
...........................................................................................................................................................................232
Figure 45 : Extrait des interrogations du syndicat national de la banque Société
Générale....................................................................................................................................................234
Figure 46 : Communiqué du syndicat national de la banque...............................................236
Figure 47 : Rôle et offres de services du centre agile de la DSI 4 .......................................237
Figure 48 : Objet du cadre méthodologique de gestion de projet ......................................239
Figure 49 : Liste des formations demandées dans le cadre d’un appel d’offres de la CMP
...........................................................................................................................................................................240
Figure 50 : Ateliers de mise à jour du cadre méthodologique de management de projet
intégrant l’agilité à l’échelle ..............................................................................................................242
Figure 51 : Liste des rôles nécessitant une reconnaissance des RH .................................243
Figure 52 : Première version du programme de formation organisé par la CMP .......244
Figure 53 : Catalogue des formations portant sur les méthodes agiles en 2018 .........245
Figure 54 : Modélisation des flux de généralisation du cas Société Générale ...............251
Figure 55 : Modèle économique d’Amadeus ..............................................................................269
Figure 56 : Activités couvertes par les services Airport IT...................................................271
Figure 57 : Structuration du département R&D .......................................................................273
Figure 58 : Première bifurcation de la trajectoire engendrée par l’arrivée du nouveau
directeur de la R&D ..............................................................................................................................277
Figure 59 : Présentation de la structure du programme de transformation agile ......278
Figure 60 : Bifurcation liée au lancement du programme Agility ......................................284
Figure 61 : Modes d’organisation en tribu ..................................................................................285
Figure 62 : Modélisation simplifiée des interactions entre une tribu et les chefs de
projets .......................................................................................................................................................287
Figure 63 : Bifurcation liée au lancement du programme End to End .............................292
Figure 64 : Extrait du rapport annuel 2019 ...............................................................................294
Figure 65 : Vue synoptique des directions de la Banque de France..................................300
411
Figure 66 : Organisation de la DSI Banque de France ............................................................302
Figure 67 : Schématisation des différents départements intervenant dans les projets
...........................................................................................................................................................................308
Figure 68 : Extraits des résultats de l’étude menée en interne...........................................311
Figure 69 : Bifurcation liée au lancement du cadre méthodologique Arpège-Agile ...314
Figure 70 : Extrait d’un discours de lancement du Lab innovation ..................................315
Figure 71 : Bifurcation engendrée aux différentes décisions de la séquence 3............322
Figure 72 : feuille de route du plan de généralisation ............................................................323
Figure 73 : Accompagnement proposé par les coachs de la Fabrique .............................324
Figure 74 : communication autour de la mise en œuvre de la méthode SAFe ..............327
Figure 75 : présentation des domaines de la DSI de GRDF...................................................333
Figure 76 : Comparaison des trajectoires méthodologiques ...............................................357
Figure 77 : Schématisation du changement organisationnel au sein de la DSI ............367
Figure 78 : Périmètre du management de produit ..................................................................368
Figure 79 : Cycles successifs de généralisation .........................................................................371
Figure 80 : Modélisation du processus de généralisation d’une méthode agile de gestion
de projet ...................................................................................................................................................374
412
Liste des tableaux
413
Tableau 32 : Présentation des unités d’affaires en lien avec les DSI de la SG ...............192
Tableau 33 : Totaux des effectifs internes et externes dans les DSI de la SG ................193
Tableau 34 : Synthèse de la première séquence du cas de la DSI 1 SG ............................202
Tableau 35 : Séquence portant sur la généralisation de Scrum .........................................209
Tableau 36 : Séquence sur la mise en place d’une Fast IT ....................................................215
Tableau 37 : Synthèse des ingrédients de la séquence 4 .......................................................226
Tableau 38 : Reproduction du modèle de la DSI 1 vers la DSI 3 .........................................233
Tableau 39 : synthèse des principaux rôles de la CMP identifiés ......................................240
Tableau 40 : Synthèse des rôles de la CMP dans la généralisation de Scrum................246
Tableau 41 : Synthèse des séquences identifiées dans le cas Société Générale ...........248
Tableau 42 : Analyse critique des différentes méthodes complétant Scrum ................251
Tableau 43 : Taxonomie des rôles de facilitation des coachs agiles .................................255
Tableau 44 : Évolution historique du positionnement d’Amadeus ...................................270
Tableau 45 : Ingrédients illustrant l’émergence de Scrum dans les projets ..................276
Tableau 46 : Ingrédients illustrant l’émergence de Scrum dans les projets ..................283
Tableau 47 : Synthèse des séquences 3 et 4 du cas Amadeus .............................................295
Tableau 48 : Synthèse du cas Amadeus........................................................................................296
Tableau 49 : Synthèses des différentes approches adoptées au cours des séquences du
cas Amadeus ...........................................................................................................................................297
Tableau 50 : Séquence d’émergence de la méthode Scrum dans les équipes de
développement ......................................................................................................................................305
Tableau 51 : Synthèse de la séquence 2 du cas Banque de France....................................313
Tableau 52 : Synthèse de la séquence 3 du cas Banque de France ....................................321
Tableau 53 : Synthèse de la séquence 4 du cas Banque de France ....................................328
Tableau 54 : Synthèse des séquences du cas Banque de France ........................................329
Tableau 55 : Synthèse des différentes méthodes adoptées dans le cas B .......................330
Tableau 56 : Synthèse de la première séquence du cas GRDF ............................................342
Tableau 57 : Synthèse de la deuxième séquence du cas GRDF ...........................................347
Tableau 58 : Synthèse des séquences du cas GRDF .................................................................348
Tableau 59 : Synthèses des différentes approches adoptées au cours des séquences du
cas GRDF ...................................................................................................................................................349
Tableau 60 : Synthèse des différents moteurs ..........................................................................354
Tableau 61 : Illustration des crises des DSI et de la R&D d’Amadeus ..............................355
Tableau 62 : Comparaison de l’héritage méthodologique des cas.....................................356
Tableau 63 : Comparaison des décisions prises par les hauts directeurs ......................358
Tableau 64 : Compilation des programmes de transformation des cas ..........................359
Tableau 65 : Comparaison des séquences portant sur l’expérimentation de la méthode
Scrum .........................................................................................................................................................362
Tableau 66 : Complément méthodologique à la méthode Scrum ......................................364
Tableau 67 : Grille de lecture des dynamiques d’appropriation de la méthode Scrum
...........................................................................................................................................................................366
414
415
RÉSUMÉ
Cette thèse a pour objectif d’expliquer la manière dont les grandes organisations
généralisent les méthodes agiles à l’ensemble de leurs projets SI. Compte tenu des
potentiels bénéfices à la clé, la tendance n’est plus d’expérimenter ce mode de
fonctionnement mais plutôt de le généraliser à tous les projets. Or, la généralisation
requiert des efforts importants en raison du fait que les méthodes agiles génèrent plusieurs
changements au niveau des rôles, des processus et de la culture. Dans cette optique, nous
nous sommes appuyées sur un design de recherche qualitatif reposant sur une analyse
processuelle de quatre études de cas complexes. Nous parvenons ainsi à identifier les
ingrédients favorisant des dynamiques de généralisation planifiées et émergentes.
MOTS CLÉS
ABSTRACT
This thesis aims to explain how large organizations generalize agile methods to all their
IS projects. Given the potential benefits, the trend is no longer to experiment this way of
working but rather to generalize it to all projects. However, generalization requires
significant effort because agile methods generate several changes in roles, processes and
culture. With this in mind, we relied on a qualitative research design based on a process
analysis of four complex case studies. We were able to identify the ingredients for planned
and emerging generalization dynamics.
KEYWORDS
416