Embed Size (px)
Citation preview
INVESTISSEMENT AGILE
DES PROJETS RIGIDESA L’AGILITE DE L’INVESTISSEMENT
La ligne directrice pour comprendre et agir
Table des matières 3
Résumé décideurs 5
Enjeu et plan 7
1. Comprendre d’où on vient 9
2. Comprendre où on va 13
3. Comprendre la ligne directrice 19
4. Sécuriser l’avancement 35
Le Portefeuille d’EtudesLes solutions sur les sujets de fond à l’attention des décideurs, managers et cadres
Recherche appliquée indépendante MOe et MOa en informatique d’entreprise
Yphise Nous voulons réussir le défi de l’informatique agile
Transformationdu travail
Investissementagile
Transformationdevops
Transformationdigitale
Gouvernanceinformatique
« Je suis fascinée par la puissance de ce quin’a pas de forme : le vent, l’eau et la pensée »
Anita Conti
Anita Conti est à la fois aventurière, océnanographe et femme de lettres du XXème siècle.
Toute organisation est confrontée à des enjeux de changement qu’elle a du mal à réaliser, tant
freinent le quotidien, les habitudes, les situations établies, l’usure du temps et les craintes.
Pour réussir l’action, il faut d’abord une pensée qui établit une vision et réfléchit les moyens de sa
concrétisation.
Anita Conti nous rappelle à juste titre à quel point une pensée puissante peut faire bouger les choses.
Elle nous suggère aussi que sans cette pensée, l’effort sera vain ; que comme le vent et la mer
peuvent aussi ravager, la pensée mal construite détruit.
Une pensée forte et construite, qui sait articuler en intelligence fins et moyens, est une condition
indispensable à la réussite de l'action en entreprise.
A l’inverse, une pensée stéréotypée n’est pas étrangère à nombre de difficultés.
Construire cette pensée nécessite du recul et du temps, largement inaccessibles au décideur,
manager ou cadre dans l’exigence de l’opérationnel. Le Portefeuille d’Etudes vous accompagne en
réalisant pour vous ce travail.
Ce que nous essayons de faire à chaque étude tient en quatre points.
− La réflexion de fond dont les managers et cadres ont besoin, sans avoir le temps de la mener.
− Les messages et solutions les plus simples, sans être plus simples que la complexité du réel.
− L’action opérationnelle en entreprise, sans débat théorique ou conceptuel inutile.
− Une dynamique de collaboration entre MOe et MOa, et entre les métiers d’une MOe.
www.yphise.com > le Portefeuille d’EtudesDirecteur : Xavier Flez
60 rue de la Folie Regnault - 75011 Paris - [email protected]
Décembre 2019
Table des matières
Classement principal sur www.yphise.com
Investissementagile
Résumé décideurs 5
Enjeu et plan 7
1. Comprendre d’où on vient
1.1 Le fonctionnement 10
1.2 Les rôles 11
1.3 Une remarque sur la validité 12
2. Comprendre où on va
2.1 Le fonctionnement 14
2.2 Une logique d’adaptation 15
2.3 Les rôles 16
2.4 Ligne directrice 17
3. Comprendre la ligne directrice
3.1 Le business case 20
3.2 L’action agile 22
3.3 La transformation devops 24
3.4 Le mode projet 27
3.5 La gestion des services 30
3.6 Le cadrage de l’action 32
3.7 Le pilotage de la compétitivité 34
4. Sécuriser l’avancement
4.1 Le risque majeur 36
4.2 Une montée en puissance 37
4.3 La confusion des modes d’action 38
4.4 La logique d’adaptation 40
Chaque étude est rédigée pour être accessible à tout cadre, manager ou décideur en informatique, maitrise
d’œuvre (MOe) ou d’ouvrage (MOa), indépendamment de sa spécialité ou de sa responsabilité du moment.
Cette ouverture est une clé du développement professionnel de chacun et de la réussite collective.
Synopsis thématique
Principaux sujets abordés et niveau.
Business case Compréhension de fond dans l’agilité de l’investissement.
aMOa opérationnel Id.
aMOa stratégique Id.
Propriétaire de produit Id.
Mode produit Id.
Mode projet Id.
Management des centres de
compétences
Id.
Nous recommandons de ressortir cette étude sur www.yphise.com en cas d’utilisation
plusieurs mois après sa date de parution : elle peut avoir fait l’objet de corrections ou
de petites modifications, notamment liées à des évolutions du Portefeuille.
Version 1.3
5 © Yphise
Résumé décideurs
On vient d’une situation où l’investissement sur les systèmes d’information était affaire
de projets sélectionnés par un processus de mise au plan. On est aujourd’hui en pleine
transformation : on parle de business case, de mode produit, de remise en question des
projets ou encore d’aMOa stratégique ; le tout dans un cadre global visant l’agilité de
l’investissement.
Il est effectivement essentiel d’y voir clair afin de pouvoir ensuite descendre de manière
sûre dans la déclinaison opérationnelle qui convient à sa situation ; c’est pourquoi nous
vous proposons une ligne directrice.
Cette ligne directrice articule six rôles : aMOa stratégique, responsable de business
case, aMOa opérationnel, propriétaire de produit, chef de mode projet et service
manager. Chacun a une place précise dans la construction de l’agilité de l’investissement
sur les systèmes d’information.
La grande idée derrière tout cela est le passage d’un fonctionnement de l’investissement
centré sur une logique d’implémentation, à un fonctionnement conçu pour une logique
d’adaptation.
La logique d’implémentation fonctionne bien lorsqu’on sait détailler la solution dont on a
besoin et qu’il y a peu d’incertitudes dans la réalisation : le point de vue hyper dominant
pour assurer la maitrise est de planification, du « haut vers le bas ».
Mais aujourd’hui on demande à l’investissement sur les systèmes d’information bien
autre chose : on part d’un enjeu ou d’un objectif ; il faut alors avancer sur la création de
valeur, à la bonne vitesse, mais avec de nombreuses incertitudes ou inconnues qui font
qu’il faut agir progressivement et réagir à temps. Il faut en particulier faire très attention
à la bonne acceptation et appropriation des changements par les utilisateurs (user
experience). On est sur une logique d’adaptation, c’est-à-dire sur un enjeu d’agilité de
l’investissement.
Le grand piège est alors de basculer sur un fonctionnement simpliste qui consiste à
réaliser de temps en temps un paquet (ou lot) de changements à partir d’un flux continu
de demandes. On fait alors disparaitre un pan entier du professionnalisme de
construction et de pilotage des projets, avec en remplacement une notion déformée de
propriétaire de produit.
Ce piège est difficile à éviter car il donne dans un premier temps l’impression d’être agile,
jusqu’au moment où on s’aperçoit qu’on tourne en rond, sans avancer correctement là où
il faut, avec des conséquences de plus en plus sérieuses sur le fonctionnement et la
compétitivité de l’entreprise. C’est le constat de ce piège qui a amené cette étude et son
message clé : l’agilité de l’investissement est affaire d’excellence opérationnelle des rôles
de cette ligne directrice.
Une ligne directrice est toujours un peu indigeste : il s’agit de donner une vue d’ensemble
6 © Yphise
qui amène de fait à manipuler un nombre relativement important de notions tout en
restant à haut niveau. Mais c’est indispensable pour descendre dans l’opérationnel de
manière sûre.
Nous avons ainsi essayé de dire dans cette étude l’essentiel afin de garder le caractère
synthétique. Mais cet effort a évidemment comme contrepartie de parfois schématiser : il
faut considérer cette étude comme un point d’entrée qui se concrétise par différentes
études du Portefeuille qui vont dans l’opérationnel des savoir-faire.
Nous vous invitons donc à entrer dans la ligne directrice de l’agilité de l’investissement,
afin de faciliter la réflexion nécessaire à la réussite de cette transformation.
Bonne lecture.
Yphise
Décembre 2019
7 © Yphise
Enjeu et plan
Enjeu
Comment réussir l’agilité de l’investissement sur les systèmes d’information.
Résultat
L’enjeu d’agilité transforme en profondeur la manière d’investir sur les systèmes
d’information. Il repose sur six rôles : responsable de business case, aMOa opérationnel,
propriétaire de produit, chef de mode projet, service manager et aMOa stratégique.
La réussite nécessite d’y voir clair pour descendre de manière sûre dans la déclinaison
opérationnelle qui convient à son entreprise : il faut une ligne directrice.
Cette ligne directrice est d’abord présentée de façon très synthétique (2. Comprendre
où on va) ; un bref rappel d’où on vient aide sa compréhension (1. Comprendre d’où
on vient).
Elle est ensuite détaillée au niveau utile : c’est le cœur de l’étude (3. Comprendre la
ligne directrice).
Ce socle permet une prise de recul afin de sécuriser l’action (4. Sécuriser
l’avancement).
L’ensemble est présenté de sorte à faire immédiatement ressortir l’essentiel. Nous avons
à cet effet beaucoup travaillé la simplicité et la rapidité d’accès aux résultats par
l’utilisation systématique de schémas (18 schémas) et un texte à lire réduit ; un résumé
synthétique (encadré rouge) permet un accès immédiat aux points importants (16
encadrés rouges).
Cette étude constitue ainsi un point d’entrée de haut niveau ; il se décline en différentes
études du Portefeuille détaillant CHAQUE savoir-faire : elles sont référencées en note au
bon endroit.
Cette étude est rédigée à l’attention des décideurs et managers : atteindre l’agilité de
l’investissement nécessite une compréhension de fond partagée concernant la bonne
manière de procéder et les pièges à éviter. Elle établit ainsi un guide pour dynamiser et
contrôler cette transformation.
Cette étude s’adresse également à chaque professionnel, côté maitrise d’œuvre ou
d’ouvrage. Il est en effet important pour chacun de bien comprendre où on va afin de se
situer, agir de façon pertinente et motivante, et réussir son développement professionnel.
Cette étude concerne en particulier les professionnels des méthodes de l’informatique qui
doivent accompagner et animer le développement des compétences clés qui concrétisent
l’agilité de l’investissement.
8 © Yphise
9 © Yphise
1. Comprendre d’où on vient
1.1 Le fonctionnement
1.2 Les rôles
1.3 Une remarque sur la validité
CDC
Prj
Cahier des charges de la solution
Projet réalisant la solution
Plan de projets
D’où on vient
+ maintenance corrective et évolutive
10 © Yphise
1. Comprendre d’où on vient
1.1 Le fonctionnement
CDC
Prj
Cahier des charges de la solution
Projet réalisant la solution
Plan de projets
D’où on vient - Le fonctionnement
L’investissement informatique est réalisé par un plan (ou portefeuille) de projets. Chaque projet
est défini par un cahier des charges décrivant la solution à réaliser.
+ maintenance corrective et évolutive
On vient d’un fonctionnement de l’investissement sur les systèmes d’information selon ce
schéma : des projets, chacun étant défini par la solution à réaliser ; avec une
macroplanification de ce portefeuille ou plan de projets au regard des ressources.
11 © Yphise
1. Comprendre d’où on vient
1.2 Les rôles
D’où on vient - Les rôles
Un rôle est central : le chef de projet (1). Avec un gros travail de planification, coordination et
surveillance des interventions nécessaires des différents centres de compétences (2).
Progressivement est monté en importance l’aMOa, responsable en amont de l’analyse du besoin et
de l’établissement du cahier des charges (3) et en aval de la recette (UAT User acceptance
test) (4).
L’ensemble étant piloté par un processus de recueil des demandes, sélection, macroplanification et
surveillance des projets ; souvent sous le contrôle d’une entité dédiée (PMO Project management
office) (5).
Italique = un processus ou une entité de l’organisation
Piloter projetRéaliser projet
Planifier le résultat Planifier l’organisationPréparer projet
S C R Ve Va D
Responsabilité de l’aMOa
Intervention de l’aMOa
S Spécifier - C Concevoir
R Réaliser - Ve Vérifier (tester)
Va Valider (recetter) - D Déployer
3
4
1
2
5
aMOa
Chef de projet
Gestion du plan de projets
Centres de compétences
3 4
Ce fonctionnement se traduit par les dispositifs brièvement résumés ci-dessus : ceci est
établi depuis longtemps.
Le point clé à noter est que ces dispositifs traduisent un point de vue hyper dominant :
une logique de planification ; du « haut vers le bas » :
− la sélection et la macroplanification des projets au regard des ressources,
− la définition précise de la solution à réaliser par le projet en amont de son lancement,
− la conduite de chaque projet par une planification opérationnelle des interventions.
Dit autrement, on est sur un mode bureaucratique (ou administré).
12 © Yphise
1. Comprendre d’où on vient
1.3 Une remarque sur la validité
En informatique, la charge de développement croit de manière exponentielle avec la complexité de
la réalisation. Une bonne planification de la charge repose donc sur la bonne appréciation de la
complexité ; ce qui est un défi souvent irréaliste.
En particulier, la complexité s’apprécie au regard de la compétence disponible ; la complexité
perçue peut en outre varier largement selon l’évaluateur.
Charge
faible
très forte
usuelle
forte
Complexité
de réalisation
usuelle fortefaible très forte
Il nous parait utile de rappeler ici que le mode bureaucratique est optimal lorsque
l’incertitude de réalisation est faible : on sait ce qu’il faut faire et comment faire pour y
arriver selon un budget et un délai définis. L’efficience repose alors sur la définition des
modes opératoires, la planification des ressources, et la surveillance du respect des
modes opératoires et de la planification.
A l’inverse, l’efficacité de ce mode s’écroule lorsque l’incertitude de réalisation augmente.
C’est ce que vivent quotidiennement les chefs de projet devant faire intervenir différents
centres de compétences. Ceux-ci ont du mal à tenir leurs délais parce qu’il leur est
souvent difficile d’apprécier précisément la complexité de ce qu’ils doivent réaliser et
qu’un petit écart de complexité peut avoir de grandes conséquences sur la charge.
On a alors l’effet boule de neige habituel sachant que ces centres de compétences sont en
général à ressources très contraintes : un délai non tenu par un centre de compétences
sur UNE réalisation pour UN projet se propage en s’amplifiant à TOUT le projet et à TOUS
les projets.
13 © Yphise
2. Comprendre où on va
2.1 Le fonctionnement
2.2 Une logique d’adaptation
2.3 Les rôles
2.4 Ligne directrice
ActionEB
temps
BC vn
Action ActionEB
BC v1
Piloter la compétitivité
Contrôle de maitriseEB
Action
Expression de besoinBC Business case
Action agile : mode produit ou mode projet selon la circonstance
Réaliser un investissement
Où on va
14 © Yphise
2. Comprendre où on va
2.1 Le fonctionnement
ActionEB
temps
BC vn
Action ActionEB
BC v1
Piloter la compétitivité
Contrôle de maitriseEB
Action
Expression de besoinBC Business case
Action agile : mode produit ou mode projet selon la circonstance
Réaliser un investissement
1
3 2
4
5Où on va - Le fonctionnement
L’investissement informatique casse, dans la mesure du possible, les gros projets en actions plus
petites correctement positionnées dans le temps (1).
Ce bon positionnement dans le temps vise à avancer au rythme permettant la meilleure création
de valeur compte tenu des incertitudes ; en particulier en évitant de fragiliser l’acceptation et
l’appropriation des changements par les utilisateurs.
Chaque action est conduite de manière agile ; ce qui signifie la conduite systématique des projets
en MODE projet (2) et la distinction lorsque pertinent d’un mode produit (3).
Le bon pilotage du business case amène à développer en temps utile l’expression de besoin
permettant de cadrer la ou les prochaines actions (4).
La construction et le cadrage des investissements se fait par une réflexion construite et continue
d’alignement du système d’information (5).
Nous avons rappelé d’où on vient ; voici où on va.
On va vers un fonctionnement selon ce schéma :
− la construction et le pilotage de business cases,
− au regard d’une réflexion identifiant les opportunités ou nécessités d’investir,
− avec une réalisation agile positionnant l’action utile au bon moment,
− cette action pouvant être en mode produit ou en mode projet selon la circonstance.
15 © Yphise
2. Comprendre où on va
2.2 Une logique d’adaptation
service
Hyper
agilité Agilité Intégrité
métier système
implémentation adaptation
Le fonctionnement d’où on vient (old way) était centré sur une logique d’implémentation ; le
nouveau fonctionnement (new way) est centré sur une logique d’adaptation.
Le mode bureaucratique est efficient sur une logique d’implémentation. Une logique d’adaptation
nécessite de mettre de l’agilité partout.
L’évolution des systèmes d’information vers la recherche de compétitivité par des services à
l’utilisateur (transformation digitale) amène l’impératif de réussite d’une logique d’adaptation.
− Logique d’implémentation : on a un besoin, on l’analyse, on établit la solution, on conduit le
projet qui réalise cette solution.
− Logique d’adaptation : on a un enjeu ou un objectif ; il faut avancer sur la création de
valeur, à la bonne vitesse, mais avec de nombreuses incertitudes ou inconnues qui font qu’il
faut agir progressivement et réagir à temps. Il faut en particulier faire très attention à la
bonne acceptation et appropriation des changements par les utilisateurs (user experience).
Avant de détailler ce fonctionnement, il est utile de revenir sur ce qui l’amène.
On peut aborder cette transformation sous différents angles ; celui qui permet de donner
de la puissance à la réflexion se résume en deux mots : implémentation et adaptation1.
Le fonctionnement d’où on vient est centré sur une logique d’implémentation : on sait
détailler le fonctionnement cible d’un processus ; on conduit le ou les projets qui
l’implémentent.
Le nouveau fonctionnement est conçu pour une logique d’adaptation : on a un objectif de
valeur sur lequel il faut avancer à la bonne vitesse, sans précipitation susceptible de le
fragiliser dangereusement ; on est en situation incertaine, il faut savoir s’adapter
précisément aux événements, en particulier aux réactions des utilisateurs (internes ou
externes à l’entreprise).
L’adaptation est affaire d’agilité, c’est-à-dire de souplesse et d’intelligence dans le
temps : il faut une action fluide et à temps (just in time) qui soit cadrée par un objectif et
évaluée avec la fréquence utile pour sécuriser l’avancement.
1 Etude « Le défi de l’informatique agile ».
16 © Yphise
2. Comprendre où on va
2.3 Les rôles
Où on va - Les rôles
La réalisation d’un investissement est un business case qui positionne dans le temps l’action utile
au bon moment (l’action juste). Il faut donc un responsable opérationnel de ce business case (1).
L’agilité de l’action amène à introduire un mode produit lorsque c’est pertinent ; ce qui amène le
rôle de propriétaire de produit (2). Lorsque l’action reste un projet, il faut conduire le projet en
MODE projet (3).
Cette agilité de l’action a pour enjeu déterminant la capacité des centres de compétences à
s’organiser, industrialiser ou déléguer pour tenir des délais, éventuellement très serrés ; il s’agit
concrètement d’arriver à maturité du rôle de service manager (4).
Le développement en temps utile d’une expression de besoin modifie le rôle d’aMOa (qualifié ici
d’opérationnel par distinction avec l’aMOa dite stratégique) (5).
Enfin, la construction et le cadrage des investissements amènent un rôle spécifique, souvent
appelé d’aMOa stratégique (6).
!Ce schéma distingue des rôles (un rôle = une mission + des savoir-faire). Il ne signifie
pas qu’il faut autant d’intervenants que de rôles : une personne peut porter plusieurs
rôles, successivement ou non, selon ce qui est raisonnable en la circonstance.
ActionEB
temps
BC vn
Action ActionEB
BC v1
Piloter la compétitivité
Action Action agile : mode produit ou mode projet selon la circonstance
Réaliser un investissement
15
6
2 34
1
2 3
4
5
6
Propriétaire de produit
aMOa stratégique
Service manager
aMOa opérationnel
Chef de mode projet
Resp business case
Le nouveau fonctionnement amène un développement précis de missions et savoir-faire,
c’est-à-dire de rôles.
17 © Yphise
2. Comprendre où on va
2.4 Ligne directrice
aMOa
Chef de projet
Gestion du plan de projets
Centres de compétences
D’où on vient
Propriétaire de produit
aMOa stratégique
Service manager
aMOa opérationnel
Chef de mode projet
Resp business case
Où on va
Le rappel d’où on vient montre bien l’ampleur du sujet : il s’agit d’une transformation.
La ligne directrice de cette transformation est le développement harmonieux des six
rôles.
Détaillons cette ligne directrice.
18 © Yphise
19 © Yphise
3. Comprendre la ligne directrice
3.1 Le business case
3.2 L’action agile
3.3 La transformation devops
3.4 Le mode projet
3.5 La gestion des services
3.6 Le cadrage de l’action
3.7 Le pilotage de la compétitivité
aMOa
Chef de projet
Gestion du plan de projets
Centres de compétences
D’où on vient
Propriétaire de produit
aMOa stratégique
Service manager
aMOa opérationnel
Chef de mode projet
Resp business case
Où on va
20 © Yphise
3. Comprendre la ligne directrice
3.1 Le business case
ActionEB
temps
BC vn
Action ActionEB
BC v1
Cadrage
- les gains
- le scénario
- le financier
Pilotage
- les contrôles
- les actions
Business case vn
Responsable de business case
Le business case = un bon investissement = des gains et la capacité à les réaliser.
− Les gains = une construction des gains en privilégiant le quantitatif (plus de recettes ou
moins de charges) ; en recherchant les gains dits d’opportunité, sachant qu’au départ on
part souvent de contraintes.
− La capacité à réaliser les gains = le scénario répartissant les actions utiles dans le temps
permettant la maitrise de l’investissement = le changement juste.
Le socle est le rôle de responsable de business case avec deux savoir-faire fondamentaux :
construire des gains d’opportunité ; élaborer et piloter le scénario de la maitrise, c’est-à-dire du
changement juste.
Le changement juste = le changement utile au moment opportun = le changement
utile aux utilisateurs et qui permet des gains, sans fragiliser l’investissement par des
risques de réalisation informatique, d’appropriation par les utilisateurs ou
d’inadaptation aux événements.
L’idée fondamentale pour sécuriser un investissement en situation incertaine est
d’avancer progressivement. On cherche le bon positionnement dans le temps des
changements utiles : le changement utile aux utilisateurs2 et qui permet des gains, sans
fragiliser l’investissement par des risques de réalisation informatique, d’appropriation par
les utilisateurs ou d’inadaptation aux événements.
La clé est donc le changement juste : nécessaire et suffisant, et au bon moment. Cette
réflexion amène parfois à retarder un changement parce que le contexte amène un
2 Qui fait de la valeur à l’utilisateur ; on parle aussi de user experience.
21 © Yphise
besoin de stabilité ; elle peut à l’inverse conduire à identifier et réaliser très vite un
changement en raison d’événements créant une opportunité ou une nécessité3.
Dans ce contexte, le pilotage se fait au regard d’une valeur, c’est-à-dire d’une cible en
terme de gains. La clé de la maitrise est de construire des business cases apportant des
gains quantitatifs significatifs.
Ceci nécessite un savoir-faire précis. Le point d’entrée d’un investissement informatique
est en effet souvent une contrainte : vieillissement d’une infrastructure, dégradation
d’une application, alignement sur la concurrence, réglementaire, etc. La construction d’un
bon investissement consiste alors à transformer cette contrainte en opportunité : on
cherche un cadrage ou un point de vue permettant des gains d’opportunité.
Nous insistons sur cette capacité à construire des gains d’opportunité : c’est LA condition
pour ne pas tomber dans le sous investissement en transformation digitale. Un
investisseur se caractérise par sa capacité à trouver des gains d’opportunité pour
construire de bons investissements en partant de contraintes ou d’une situation
médiocre. Il s’agit d’être un bon investisseur sur les systèmes d’information4.
Le socle du nouveau fonctionnement est donc le rôle de responsable de business case
considérant correctement le temps5 ; avec deux savoir-faire fondamentaux :
− construire des gains d’opportunité ;
− élaborer et piloter le scénario de la maitrise, c’est-à-dire du changement juste6.
3 La puissance des technologies informatiques fait qu’on peut rater complètement un investissement par un
mauvais dosage des changements amenés au regard de la capacité d’acceptation ou d’appropriation. Il est fini
le temps où il fallait avancer au maximum en UN projet en y mettant tout ce qui était faisable. Il faut au
contraire un discernement pour agir de manière circonstanciée.
4 Ou, si l’on préfère, un bon entrepreneur.
5 Historiquement la notion de business case est apparue associée à la notion de programme ; un programme
étant un ensemble de projets à séquencer dans le temps (notamment Val IT 2006). Cette notion de business
case en tant que réalisation d’un programme répartissant une charge en une séquence de projets, reste
valide ; mais on est aujourd’hui sur autre chose : un pilotage agile de gains, c’est-à-dire qui cherche le bon
changement au bon moment en situation incertaine, un changement pouvant être limité ou très limité (on parle
de continuous delivery). Dit autrement, la responsabilité de business case est à différencier de celle de gestion
de programme : ce ne sont pas les mêmes savoir-faire.
6 Etude « Responsable de business case ».
22 © Yphise
3. Comprendre la ligne directrice
3.2 L’action agile
Mode produit
Le mode produit
Une application (ou une partie du système d’information) vue comme un produit (ou un
élément d’une prestation) de l’entreprise.
On a un besoin fréquent d’améliorations, dont la complexité et la profondeur sont limitées : on
est dans une logique d’adaptation de ce produit, sous l’autorité d’un propriétaire de produit ;
sans recette détaillée par les utilisateurs pouvant s’opposer à la livraison.
Mode projet
!
Le mode projet
L’évolution pouvant être complexe et profonde d’un système d’information, avec des enjeux
difficiles d’intégrité, de sécurité, de reprise, d’exploitabilité ou de flexibilité.
On est sur la nécessité d’une analyse et d’un travail de la part de compétences diversifiées,
ayant des intérêts différents, nécessitant beaucoup de collaborations et la capacité à trouver
des compromis. On a besoin d’une recette sur les changements apportés et d’une qualification
du système d’information dans son ensemble.
On a besoin d’agilité d’action sur le business case.
Ceci amène l’enjeu de conduite des projets de manière agile : c’est l’objet du MODE projet - au
sens strict du terme, non pas dans son usage galvaudé -.
Mais on aussi besoin d’un mode produit, distinct du mode projet, permettant des changements
limités sur une application (ou une partie du système d’information), mais pouvant être à haute ou
très haute fréquence (continuous delivery).
Le MODE projet amène à recentrer les savoir-faire du chef de projet ; le mode produit repose
essentiellement sur un rôle spécifique : le propriétaire de produit.
Attention : le mode produit et le MODE projet sont tous les deux faits pour optimiser
l’agilité d’action ; mais chacun est efficient sur ce pourquoi il est conçu : il faut les
distinguer.
Incertitude de réalisation :Faible Forte
Propriétaire de produit Chef de projet
Une action sur un business case peut être tout un projet. On cherche alors à travailler
l’agilité de ce projet, ce qui nécessite concrètement le MODE projet.
Attention : le terme mode projet est galvaudé : il est constamment utilisé pour désigner
une réalité très approximative, voire franchement éloignée, de ce qu’est le MODE projet.
Il y a alors un recentrage à opérer pour retrouver son agilité spécifique7.
Un projet est fait pour gérer de la complexité et de l’incertitude : on a besoin de
réflexion, de collaborations et d’interventions de la part de compétences qui ont leur
7 Chapitre ‘3.4 Le mode projet’.
23 © Yphise
logique propre ; on a besoin d’un processus qui permet d’intégrer progressivement les
tests de sorte à vérifier et valider tout le système d’information.
La maitrise de l’investissement passe évidemment par des projets là où on en a besoin.
Mais cela ne suffit pas pour être agile : on a aussi besoin d’un mode conçu pour
maximiser l’agilité lorsqu’on n’est pas en situation de complexité ou d’incertitude
nécessitant un projet ; c’est ce qui est appelé le mode produit.
Le mode produit vise l’adaptation d’une application sur des changements sans besoin
complexe d’analyse ou d’intervention de compétences diversifiées. Il amène le rôle de
propriétaire de produit.
Détaillons ces deux modes.
24 © Yphise
3. Comprendre la ligne directrice
3.3 La transformation devops
Le mode produit est dans une logique d’adaptation ; ce qui amène un rôle SPECIFIQUE : le
propriétaire de produit qui a autorité sur les changements, dans le cadre d’une délégation qui
cadre et surveille le développement de ce produit.
Le mode produit est par nature sans recette détaillée par des utilisateurs ou un demandeur qui
peuvent refuser le résultat jusqu'à obtenir satisfaction point par point d’une liste de modifications.
Il permet de se situer dans un objectif d’industrialisation automatisée, c’est-à-dire d’une
automatisation des tests et de tout ce qu’il faut en terme d’environnements et de montées
d’environnements.
Sprintdemandes
de changements
ProdBanc
d’essai
Analysesignaux
SprintProduct
backlog
Propriétaire de produit
Le mode produit
− Un propriétaire de produit (product owner) a autorité sur les changements pour adapter un
produit avec l’agilité voulue ; dans le cadre d’une délégation qui cadre la valeur, les
orientations, les jalons ou autres exigences de développement de CE produit (1).
− Les tests sont automatisés (banc d’essai) afin d’assurer l’agilité voulue jusqu’en production
(fréquence des changements, durée de réalisation, prédictibilité de cette durée) (2).
− Une surveillance en production du fonctionnement et de l’usage remonte les risques de non
qualité en raison des limites du banc d’essai et de la suppression (ou la restriction) de la
recette (3).
1
2
3
Le développement du mode produit constitue la transformation devops8.
Le mode produit considère une application (ou une partie d’un système d’information)
comme un produit (ou un élément d’une prestation) de l’entreprise. L’entreprise fait
progressivement évoluer ce produit selon ce qu’elle juge utile de faire ou non : elle
adapte librement son produit.
LA caractéristique essentielle est l’absence de recette détaillée (user acceptance test) :
on n’a pas d’utilisateurs ou un demandeur qui peuvent refuser le résultat jusqu'à obtenir
8 Etude « Transformation devops ».
25 © Yphise
satisfaction point par point d’une liste de modifications 9.
C’est LA différence fondamentale avec un projet : dans un projet, le demandeur exprime
en amont son besoin et recette le résultat face à ce besoin de sorte à obtenir précisément
satisfaction10.
L’absence de recette qui caractérise le mode produit a deux conséquences clés :
− elle amène le rôle de propriétaire de produit qui a l’initiative et l’autorité sur les
changements,
− elle rend envisageable une industrialisation automatisée, c’est-à-dire une
automatisation des tests et de tout ce qu’il faut en terme d’environnements et de
montées d’environnements.
Voyons ces deux points.
Le mode produit est dans une logique d’adaptation par distinction avec une logique
d’implémentation11 : il n’y a pas de demandeur arrivant avec une spécification détaillée
point par point ; mais un cadrage de l’évolution du produit qui donne au propriétaire de
produit une liberté d’appréciation de ce qu’il faut faire : il pilote l’équipe de
développement par des objectifs de valeur qu’elle doit concrétiser.
C’est précisément ce qui se passe en Scrum, qui est une règle du jeu conçue pour
l’adaptation : le propriétaire de produit est une personne physique qui a autorité sur les
changements (product backlog)12. L’incrément réalisé par un sprint répond à un objectif
de valeur (sprint goal), défini par le propriétaire de produit, que l’équipe de
développement s’engage à atteindre. Cet objectif de valeur est précisé par les
9 Ex. un éditeur de progiciel adapte progressivement son progiciel selon ce qu’il juge utile à sa compétitivité.
Le client du progiciel achète ou non la nouvelle version, utilise ou non les nouvelles fonctions, mais il ne peut
pas se livrer à une recette amenant une liste précise de modifications à prendre en compte par l’éditeur : le
client est face à un produit.
10 Attention à ne pas se méprendre sur les tests : nous ne sommes pas en train de dire que le mode produit
signifie l’absence de test, mais l’absence de recette. On distingue dans les tests la vérification de la validation.
La vérification est une responsabilité de maitrise d’œuvre qui garantit la conformité d’un résultat à l’ensemble
de ses exigences : ceci inclut tous les tests unitaires, d’assemblage, d’intégration ou de qualification
(préproduction), qu’ils soient fonctionnels ou techniques, des nouveaux développements ou de non
régression : le mode produit comporte tous ces tests. La validation (ou recette ou user acceptance test) est
une responsabilité de maitrise d’ouvrage qui apprécie le résultat au regard du besoin. En pratique, la recette
des projets fait surtout de la vérification, mais c’est le résultat d’une faiblesse de cette vérification.
11 Chapitre ‘2.2 Une logique d’adaptation’.
12 La notion de propriétaire de produit a été parfaitement introduite par Scrum.
26 © Yphise
changements du product backlog sélectionnés par l’équipe de développement pour le
sprint (sprint backlog)13.
On ne peut pas, par nature, automatiser une recette, puisque c’est précisément le regard
du demandeur ; à l’inverse, la vérification peut s’automatiser : on vérifie un code par ce
qui le spécifie ; cette vérification est répétée un grand nombre de fois dans l’évolution du
produit car elle doit assurer la non régression.
Une fois l’agilité obtenue sur le développement, le grand challenge du mode produit est
d’automatiser les tests permettant cette vérification : c’est indispensable lorsqu’on est
sur des enjeux de changements à haute fréquence ou à délai réduit14.
La montée en puissance du mode produit est un sujet récent et de fond. Le socle est le
rôle de propriétaire de produit dont le fonctionnement doit être en ligne avec la logique
d’adaptation du mode produit ; ce qui est plus difficile à réussir qu’il y paraît15.
13 Scrum n’impose pas de niveau de formalisation des changements du product backlog : on peut être à un
niveau de spécification détaillée lorsque c’est utile pour donner des consignes impératives à l’équipe de
développement ; mais la recommandation de fond est une formalisation qui donne de la liberté à l’équipe de
développement afin qu’elle puisse faire preuve d’initiative au regard de son expérience et des difficultés
rencontrées. Dans cet esprit, il peut arriver qu’il y ait des écarts entre ce que dit le sprint backlog et le code :
l’engagement est tenu dès lors que le sprint goal est atteint ; l’engagement ne porte en effet pas sur une
implémentation détaillée mais sur une adaptation selon l’objectif de valeur. Etude « Le bon usage de Scrum ».
14 Ex. e- ou m-commerce.
15 Chapitre ‘4.3 La confusion des modes d’action’.
27 © Yphise
3. Comprendre la ligne directrice
3.4 Le mode projet
LE sujet clé du mode projet est l’intervention à temps et fiable des différents centres de
compétences dans un contexte d’incertitude de réalisation, d’exigences nécessitant des compromis
et de contraintes de ressources qui font échouer la logique de planification.
Le mode projet
− La réflexion de plan de projet travaille le quand et selon quelle technique (règle du jeu ou
méthode) mener chaque réalisation, de sorte à maitriser le projet au regard de ses risques
spécifiques de dérapage (1).
− La conduite du projet est menée de sorte à réussir à temps l’intervention de compétences
diversifiées, ayant des intérêts différents, avec des enjeux de collaboration et de compromis
à trouver, dans un contexte d’incertitude de réalisation pouvant être forte. L’agilité se joue
sur trois dispositifs.
− Le fonctionnement en plateau projet : une équipe pluridisciplinaire, chaque membre
étant détaché par son centre de compétences ; regroupée sur un même plateau de
sorte à permettre un travail conjoint de ses membres (par opposition à une intervention
séquentielle des différents centres de compétences avec une multiplication des
remontées hiérarchiques pour planifier ou arbitrer) (2).
− La collaboration planifiée du centre de compétences avec le projet selon un plan qualité
qui règle les modalités de cette collaboration en début du projet (avec révision
régulière), lorsque son intervention ne justifie pas ou ne permet pas le fonctionnement
en plateau (3).
− Un flux de conception sur l’ensemble du projet qui permet de poser et traiter au fil de
l’eau toute question de conception de sorte à ce qu’un centre de compétences ne se
retrouve pas à découvrir tardivement une contrainte qui fasse déraper son intervention
où celle d’autres centres de compétences (4).
Plan de
projet
Chef de projet
flux de conception à temps
Plan
qualité
Plateau du projet
Service manager
Centre de compétences
Service manager
Centre de compétences
Service manager
Centre de compétences
1
23
4
Le mode produit est la solution d’agilité efficiente sur son périmètre d’application. Mais il
n’est pas fait pour se substituer à un projet là où on en a besoin. L’agilité est alors affaire
de conduite du projet en MODE projet.
28 © Yphise
Le mode projet est ancien ; il est d’ailleurs antérieur à l’émergence du sujet de l’agilité en
tant que tel16.
La caractéristique fondamentale du mode projet a trait à la manière de collaborer des
intervenants, en proximité et en responsabilité conjointe, c’est-à-dire à proprement
parler en agilité : LE principe fondamental est le fonctionnement en plateau (physique ou
virtuel grâce aux outils de collaboration) ; on est donc en situation de collaboration forte
et à plat, ce qui permet d’adapter l’action, sans être en permanence à devoir planifier,
négocier ou arbitrer avec des centres de compétences ayant chacun ses intérêts, son
organisation et sa hiérarchie.
L’erreur la plus fréquente (ce n’est pas la seule) est de parler de mode projet pour
désigner un fonctionnement caractérisé par un chef de projet sans autorité hiérarchique
sur les intervenants17, tout en restant dans une logique de planification, c’est-à-dire un
mode bureaucratique ; mais dans le contexte d’incertitude des projets qui fait que ce
mode bureaucratique ne peut pas fonctionner18.
Les projets dits en mode projet sont donc souvent qualifiés ainsi de manière abusive :
c’est une étiquette qui ne correspond pas à la réalité. L’enjeu est alors de revenir à un
MODE projet, digne de ce nom.
LE sujet clé est l’intervention à temps et fiable des différents centres de compétences
dans un contexte d’incertitude de réalisation, d’exigences nécessitant des compromis et
de contraintes de ressources qui font échouer la logique de planification.
Nous venons de voir que le fonctionnement en plateau est le principe fondamental. Mais
il faut aller plus loin avec deux autres dispositifs, trop souvent négligés.
Le premier dispositif est le plan qualité. Sa finalité essentielle est de définir les modalités
de collaboration avec les différents centres de compétences qui doivent intervenir
localement pour une analyse, une réalisation ou un contrôle. Le chef de projet se
rapproche du centre de compétences pour définir la collaboration adaptée : atelier
(workshop) d’analyse d’une exigence, participation à un sprint de développement, etc.
Le point clé à bien comprendre qui distingue la logique de plan qualité de celle de
planification est que la première réfléchit au mode de collaboration adapté, alors que la
16 Défini dans les années 90, d’abord dans l’industrie automobile. L’objectif était d’ingénierie concourante. En
bref : éviter l’intervention successive des métiers concernés par la conception et la fabrication d’un nouveau
modèle, ce qui conduit à découvrir tardivement les problèmes et à passer à côté de compromis permettant des
opportunités de gains : donc, à l’inverse, mettre en place des dispositifs permettant aux différents métiers de
travailler simultanément ensemble pour trouver les idées, équilibres ou compromis permettant la meilleure
valeur. Dans ce cadre, le dispositif le plus marquant est le plateau du projet qui amène les métiers à travailler
de manière conjointe, en une équipe avec une délégation de responsabilité de chacun de ses membres de la
part de sa hiérarchie métier.
17 On parle aussi d’organisation matricielle.
18 Chapitre ‘1.3 Une remarque sur la validité’.
29 © Yphise
seconde affecte des tâches à faire19. Dit autrement, la recherche d’agilité dans les projets
nécessité de revenir sur la réflexion de plan qualité20.
Rappelons que le plan qualité s’inscrit dans la continuité de la réflexion de plan de projet,
qui est fondamentale pour assurer la maitrise d’un projet au regard de ses risques21.
Le second dispositif est le flux de conception qui permet d’identifier et traiter à temps
toutes les questions de conception détaillée qui apparaissent au cours du projet ;
questions dont la découverte ou la réponse tardive ou inappropriée fait déraper
l’intervention d’un centre de compétences avec l’effet boule de neige habituel22.
On voit bien qu’il y a ici une dimension de pilotage du projet : l’intervention à temps et
fiable de chaque centre de compétences exige de ne pas buter sur des difficultés de
réalisation liées à des points de conception défaillants ; cette découverte des points à
traiter et des réponses à donner se fait nécessairement au fur et à mesure de
l’avancement du projet23.
On parle parfois de conception fluide ou à temps (just-in-time design) pour désigner ce
flux de conception24. Mais attention à ne pas se méprendre sur l’expression « à temps » :
ce flux de conception doit permettre d’ANTICIPER la résolution des questions qui se
posent, pour que chaque centre de compétences puisse agir A TEMPS. Il ne s’agit pas
d’attendre le « dernier moment » pour faire des choix de conception.
19 La réflexion en terme de collaboration vise à établir la règle du jeu adaptée à la situation, c’est-à-dire à
mettre l’agilité qu’il faut dans l’organisation du travail ; par opposition à une logique de planification qui
prétend s’abstraire des multiples inconnues dans l’avancement du projet. Etude « Le défi de l’informatique
agile ».
20 La notion de plan qualité a précisément connu un essor dans les années 90, lorsque le mode projet a été
développé. Le problème est que ce dispositif a connu une dérive procédurière (dérive habituelle) qui fait que sa
valeur spécifique a été largement perdue.
21 Etude « Préparer un projet ».
22 On parle aussi de conception d’industrialisation. Avec un centrage sur les problématiques d’intégration qui
font que la conception fonctionnelle et technique des différents composants, faite par ailleurs, puisse aboutir à
un système en production, c’est-à-dire répondant aux exigences opérationnelles, notamment de reprise.
23 Tout projet a besoin de ce flux de conception, certains plus que d’autres. Il peut être particulièrement
développé dans un projet caractérisé par une valeur à créer très difficile, voire à la limite du possible,
nécessitant de challenger fortement la conception détaillée pour l’atteindre. On parle d’innovation fractale : les
projets disruptifs de la transformation digitale en ont parfois besoin.
24 Etude « Conception à temps ».
30 © Yphise
3. Comprendre la ligne directrice
3.5 La gestion des services
Les modes d’intervention à distinguer et à bien utiliser pour garantir l’intervention fluide (just in
time) d’un centre de compétences.
− Le détachement d’une personne du centre de compétences au plateau du projet ou à
l’équipe de développement d’un sprint du produit (1).
− La collaboration planifiée du centre de compétences avec un projet, selon un plan qualité
qui règle les modalités de cette collaboration (2).
− La délégation à l’équipe de développement d’un sprint du mode produit de tâches courantes
de paramétrage de middleware, d’applications ou autres ; avec la surveillance ou le contrôle
adapté (3).
− L’organisation d’un hub d’intervention pour le mode produit afin d’assurer un délai
d’intervention très court pour des tâches de réalisation qu’il n’est pas opportun ou possible
d’automatiser (4).
− L’organisation pour répondre au flux de conception à temps nécessaire au mode projet
(parfois au mode produit) (5).
Chaque mode d’action, produit et projet, amène un enjeu d’excellence opérationnelle sur
l’intervention fluide des centres de compétences.
La base est l’organisation de la maitrise d’œuvre en services au sens ITIL : un centre de
compétences = une responsabilité portant sur le système d’information : une responsabilité
constitue un service ; chaque service a un service manager.
L’excellence opérationnelle signifie un management et une organisation de chaque centre de
compétences conçus pour garantir les délais utiles ; ce qui amène à distinguer et maitriser
différents modes d’intervention précis.
Mode projet - Mode produit
Centre de compétences
1
Service manager
23 4
5
?
Nous venons de voir ce qu’il faut pour revenir sur un sujet clé : chaque mode d’action,
produit et projet, amène un enjeu d’excellence opérationnelle sur l’intervention fluide des
centres de compétences, c’est-à-dire leur capacité à s’engager sur les délais
d’intervention et à les tenir.
Nous avons vu l’exigence du mode projet25. Le développement du mode produit introduit
des besoins différents qui amènent à travailler des dispositifs spécifiques : hub pour
servir très rapidement des tâches de réalisation simples ; délégation à l’équipe de
25 Chapitre ‘3.4 Le mode projet’.
31 © Yphise
développement de tâches répétitives, en particulier de paramétrage d’un middleware ou
d’une application26.
L’agilité de l’investissement amène donc à reprendre le sujet de l’organisation et du
management opérationnels des centres de compétences, de sorte à distinguer et
maitriser les différents modes d’intervention nécessaires.
La clé de la réussite est de bien positionner et différencier les modes d’intervention : la
cause première de l’incapacité à s’engager sur les délais est la confusion qui fait porter
sur les équipes des interventions répondant à des logiques différentes, de manière
indifférenciée.
26 Etude « L’agilité des centres de compétences ».
32 © Yphise
3. Comprendre la ligne directrice
3.6 Le cadrage de l’action
La construction d’une cible
permettant une action réussie
Expression de besoin
EB v1 EB v2 EB
Une analyse itérative en atelier (workshop)
ActionEB
temps
Action ActionEB
aMOa opérationnel
!
Expression de besoin = la construction d’une cible permettant une action réussie = trouver le
changement juste, là où en est le scénario d’investissement.
Se fait par une analyse itérative en atelier réunissant des intervenants du ou des métiers
concernés de sorte à trouver les bons équilibres ou compromis.
Si l’atelier met en évidence des différences d’appréciation sur les changements utiles qu’il est
impossible d’arbitrer à ce niveau � il faut remonter à une réflexion de business case (BC vn �
BC vn+1).
Attention : il ne s’agit pas simplement d’un recueil de besoins ou d’une liste de
demandes de changement, mais d’un travail de construction du changement juste,
là où en est le scénario d’investissement.
Dans un business case, viennent se loger des expressions de besoin selon le déroulement dans le
temps. Chacune construit la cible à atteindre par la ou les actions à venir ; cette cible est conçue
pour une action réussie = trouver le changement juste, là où en est le scénario d’investissement.
Il s’agit de trouver les bons équilibres ou compromis sur ce qu’il faut changer ou pas maintenant :
c’est forcément un travail en agilité ; ce qui convient ici est la conduite d’ateliers réunissant les
parties prenantes en responsabilité conjointe.
Le changement juste = le changement utile au moment opportun = le changement
utile aux utilisateurs et qui permet des gains, sans fragiliser l’investissement par des
risques de réalisation informatique, d’appropriation par les utilisateurs ou
d’inadaptation aux événements.
Le business case cadre l’investissement. A l’intérieur de ce cadre, il faut exprimer au
moment opportun le besoin qui définit la solution à réaliser par la prochaine action.
Notons qu’une expression de besoin pour plusieurs actions est courant en mode produit27.
27 Une idée du développement par sprint est de faciliter le report de certains changements à la vue du résultat
obtenu en fin de sprint, ces changements paraissant alors inutiles ou inopportuns. C’est pour cela qu’un sprint
constitue un incrément, c’est-à-dire un résultat potentiellement déployable, au regard d’un objectif de valeur
(sprint goal).
33 © Yphise
La bonne nouvelle est qu’on est au cœur du savoir-faire de l’aMOa opérationnel : il est
établi et sa mise en oeuvre en est a priori mature28.
Le point à surveiller est de bien se situer au niveau d’une expression de besoin, c’est-à-
dire de la construction d’une solution informatique au regard d’une appréciation précise
du changement juste : nécessaire et suffisant, et au bon moment. C’est sur cette
réflexion en terme de changement juste qu’il peut être nécessaire de faire monter la
compétence29.
Ceci étant, la transformation digitale nécessite parfois de modifier en profondeur la
manière de construire le besoin lorsqu’on est sur la recherche d’innovations sur des
services (ou prestations) à l’utilisateur (métier de l’entreprise ou partie prenante
externe). On passe alors d’un atelier d’expression de besoin à un processus partant plus
en amont pour identifier et sélectionner les bonnes idées qui vont cadrer le besoin à
exprimer : on parle de processus de design thinking. Mais ce niveau de sophistication n’a
pas une utilité courante ; il n’est pas une condition de l’agilité de l’investissement.
28 Etude « Préparer un projet ».
29 Etude « L’expérience utilisateur ».
34 © Yphise
3. Comprendre la ligne directrice
3.7 Le pilotage de la compétitivité
aMOa stratégique
Trouver à temps les bons investissements = identifier, qualifier et gérer le backlog du système
d’information : le portefeuille de business cases.
Trois sujets :
1. Anticiper le besoin : bien investir � une construction du besoin qui repose sur une analyse
des fragilités et des limites.
2. Injecter l’opportunité : bien investir � injecter la réflexion de simplicité et d’innovation pour
trouver et apprécier la juste profondeur de réalisation.
3. Mettre le relief métier : bien investir � une mise en ordre assurant la cohérence et la
faisabilité métier.
Trouver les business cases a priori pertinents nécessite une construction par une compétence
d’aMOa stratégique.
Piloter la compétitivité
Profondeur
simple programme difficile
A lancer
Positionnement de chaque business case
dans l’année
dans un an
dans deux ans
indéterminé
Portefeuille
de business cases
Le dernier sujet est la capacité à trouver les investissements nécessaires ou opportuns :
c’est la responsabilité dite d’aMOa stratégique.
Cette responsabilité est en particulier nécessaire en raison du temps qu’il faut pour faire
évoluer un système d’information au regard des enjeux de réactivité de l’entreprise : il
faut donc anticiper suffisamment pour investir à temps en considérant les fragilités du
système d’information, ce que veut ou doit faire l’entreprise, et les opportunités
d’innovation30.
30 Etude « Anticiper l’investissement sur un système d’information » et étude « aMOa stratégique ».
35 © Yphise
4. Sécuriser l’avancement
4.1 Le risque majeur
4.2 Une montée en puissance
4.3 La confusion des modes d’action
4.4 La logique d’adaptation
! Confusions
aMOa stratégique
Service manager
aMOa opérationnel
Chef de mode projetResp business case
Propriétaire de produit
36 © Yphise
4. Sécuriser l’avancement
4.1 Le risque majeur
L’agilité de l’investissement est un édifice qui repose sur six rôles.
Le risque majeur : les confusions qui amènent des approximations dans leur mise en œuvre.
! Confusions
aMOa stratégique
Service manager
aMOa opérationnel
Chef de mode projetResp business case
Propriétaire de produit
Le risque majeur est le constat qui a amené cette étude : l’agilité de l’investissement a
besoin d’une excellence opérationnelle en six rôles ; les confusions qui amènent des
approximations dans leur mise en œuvre, conduisent à l’échec.
C’est pourquoi nous revenons ici sur les clés de la sécurisation de l’avancement.
37 © Yphise
4. Sécuriser l’avancement
4.2 Une montée en puissance
Une montée en puissance circonstanciée
et progressive des six rôles = compétences
ET organisation du travail permettant
leur bon fonctionnement.
Propriétaire de produit
aMOa stratégique
Service manager
aMOa opérationnel
Chef de mode projet
Resp business case
L’agilité ne se décrète pas : elle ne se traite pas par des procédures ou une
réorganisation ; c’est une montée en puissance progressive.
La réussite nécessite de ce fait toujours une vision et un engagement du management31.
Le danger dans cette montée en puissance est de rester sur un discours sur la nécessité
de bien collaborer ou de se comporter de manière agile : cela fait pire que mieux.
L’agilité n’est jamais une simple affaire de bonne volonté, mais de compétences et
d’organisation du travail adaptées32.
Concrètement, l’agilité de l’investissement est affaire de montée en puissance des six
rôles : mission, savoir-faire, et organisation du travail permettant les équilibres de
pouvoir et les arbitrages utiles.
Chaque rôle exprime un morceau du puzzle à réussir : il les faut tous. Mais leur mise en
œuvre dépend du contexte : priorités, affectation d’un ou plusieurs rôles aux personnes,
localisation dans l’organisation, appel à des compétences externes, répartition entre
compétences junior et senior. Ces points sont de management opérationnel, sans
considération conceptuelle difficile.
31 Agilité � tone at the top : étude « Le défi de l’informatique agile ».
32 Id.
38 © Yphise
4. Sécuriser l’avancement
4.3 La confusion des modes d’action
L’erreur à éviter absolument est le glissement vers un fonctionnement simpliste : un flux de
demandes de changement (1) et la réalisation de temps en temps de paquets de changements (2).
Cela peut donner l’impression, au moins dans un premier temps, d’être agile : on a des demandes,
on les réalise : « tout le monde est content » ...
... jusqu’au moment où on s’aperçoit qu’on tourne en rond, sans avancer correctement là où il
faut, avec des conséquences de plus en plus sérieuses sur le fonctionnement et la compétitivité de
l’entreprise.
Le fonctionnement simpliste = un flux de demandes de changement (1) + la réalisation de
temps en temps de paquets (ou lots) de changements (2).
Ce fonctionnement cumule les erreurs à éviter :
− pas de construction de projets : un paquet de changements fait un machin (et non un
projet) qui dérape et amène un résultat médiocre ;
− pas de mode produit : une accumulation de demandes ne fait pas un bon produit ;
− pas d’adaptation précise des changements dans le temps au regard des enjeux
d’acceptation ou d’appropriation ;
− pas de construction ni d’anticipation des opportunités ou nécessités d’investir.
demandes
de changements= réalisation de paquets de changementsAction
1 2
! Fonctionnement simpliste
LE piège à éviter est la confusion des modes d’action.
C’est très difficile car ce piège est a priori séduisant : on a des demandes, on les réalise :
« tout le monde est content », on a l’impression d’être agile...
... jusqu’au moment où on s’aperçoit qu’on tourne en rond, en défaisant d’un côté ce qui
est fait de l’autre, sans avancer correctement sur les objectifs : l’entreprise perd en
compétitivité parce qu’elle sous investit ou qu’elle n’agit pas à temps ; les problèmes
d’acceptation ou d’appropriation des changements se multiplient ; les fragilités du
système d’information face aux exigences opérationnelles et au besoin d’évolutivité se
mettent à grimper33.
Ce piège se concrétise de quatre manières qui amènent toujours à négliger ou à déformer
l’un ou l’autre rôle.
− Une première manière, très fréquente, est la mise en place d’un rôle de propriétaire de
produit qui est en pratique un point d’accumulation des demandes de changement,
33 Tout ceci est avéré, allant jusqu'à mettre de belles entreprises en grande difficulté.
39 © Yphise
sans réelle responsabilité d’évolution du produit concerné. Le mode produit repose sur
un propriétaire de produit qui a autorité sur les changements parce qu’il est garant de
la bonne évolution du produit, dans le cadre d’une délégation qui en cadre et surveille
le développement. Dit brutalement, le propriétaire de produit n’est pas un passe plats
entre métiers et maitrise d’œuvre.
− Une seconde manière est la négligence du travail d’expression de besoin, c’est-à-dire
du rôle d’aMOa opérationnel. Le simple traitement de paquets de demandes est en
effet contraire à la logique de construction du changement juste, avec sa recherche
des bons équilibres ou compromis en atelier.
Ceci va de pair avec la légèreté de construction et de suivi des business cases : le rôle
de responsable de business case perd sa raison d’être ; il a tendance à se
recroqueviller sur un suivi budgétaire, avec souvent des dérives bureaucratiques
contraires à la dynamique de création de valeur et d’avancement nécessaires pour
bien agir dans la transformation digitale.
− Une troisième manière est une conduite de projet qui reste sur une logique de
planification : le point d’entrée du projet étant un paquet de changements, son
pilotage est affaire de planification de chacun. Est alors négligé ce qui est nécessaire
pour réussir les enjeux de collaboration et de compromis à trouver pour faire face à
toutes les incertitudes : les projets ne sont pas en MODE projet.
Ceci amène toujours une faiblesse d’organisation et de management des centres de
compétences au regard de l’enjeu d’intervention fluide.
− Enfin, une quatrième manière est le sous-développement du rôle d’aMOa stratégique :
l’agilité étant vue comme la capacité à réaliser vite le changement du moment, n’est
pas fait l’effort continu de construction des opportunités ou nécessités d’investir. Agir
au coup par coup conduit au sous investissement.
40 © Yphise
4. Sécuriser l’avancement
4.4 La logique d’adaptation
L’agilité de l’investissement répond à un enjeu d’adaptation : on part d’une valeur à créer, avec
souplesse et intelligence dans le temps ; plutôt que d’une solution à implémenter que l’on est
capable de décrire (ou spécifier) avec précision.
Il ne faut évidemment pas opposer adaptation et implémentation ; il s’agit de développer les rôles
de la ligne directrice au regard des situations nécessitant une logique d’adaptation.
Logique d’adaptation : on a un enjeu ou un objectif ; il faut avancer sur la création de valeur, à
la bonne vitesse, mais avec de nombreuses incertitudes ou inconnues qui font qu’il faut agir
progressivement et réagir à temps. Il faut en particulier faire très attention à la bonne
acceptation et appropriation des changements par les utilisateurs (user experience).
Par distinction avec une logique d’implémentation : on a un besoin, on l’analyse, on établit la
solution, on conduit le projet qui réalise cette solution.
Logique d’adaptation �
− l’action juste = à temps, nécessaire et suffisante en l’état,
− un pilotage par une valeur à atteindre (par différence avec une spécification détaillée à
implémenter),
− une certaine liberté et intelligence d’interprétation au moment de la réalisation,
− ce qui amène de nombreuses discussions, avec le souci de trouver le bon équilibre au bon
moment : donc des modes de travail avec beaucoup d’ateliers (workshop) et d’itératif.
adaptation
Nous venons de voir que le piège de la confusion des modes d’action nous donne une
lecture en creux de la ligne directrice : on tombe dans le piège lorsqu’on en rate des
rôles.
On peut dire la même chose de manière positive en revenant sur la logique
d’adaptation34 : les rôles qui concrétisent l’agilité de l’investissement permettent de doser
précisément la logique d’adaptation, là où on en a besoin.
− Le responsable de business case considère ainsi une adaptation progressive
d’opérations et du système d’information de l’entreprise au regard d’un enjeu ou d’un
objectif sur lequel il faut avancer avec souplesse et intelligence.
− Dans ce cadre, la responsabilité de l’aMOa opérationnel est de trouver précisément
l’adaptation à réaliser là où en est le scénario d’investissement ; adaptation qui est un
équilibre constituant un changement juste, c’est-à-dire permettant une action réussie
en la circonstance.
34 Chapitre ‘2.2 Une logique d’adaptation’.
41 © Yphise
− La responsabilité du propriétaire de produit est d’adapter au bon rythme son produit
au regard d’une délégation qui cadre la valeur attendue et son jalonnement. Il définit
ainsi pour chaque étape un objectif de valeur (sprint goal) que l’équipe de
développement a pour mission de concrétiser, en adaptant sa réalisation au regard de
son expérience et des difficultés.
− Le mode projet adapte le système d’information en situation d’incertitudes de
réalisation et d’équilibres à trouver entre points de vue divergeants, notamment liés à
la diversité des centres de compétences impliqués.
− Enfin, la responsabilité de l’aMOa stratégique est d’identifier et qualifier les
adaptations nécessaires ou opportunes au regard de la situation du système
d’information et des enjeux auxquels l’entreprise doit faire face.
On voit bien que la bonne distinction des rôles, chacun agissant selon sa mission et ses
savoir-faire, constitue la ligne directrice de l’investissement en situation d’adaptation ; dit
autrement, de l’agilité de l’investissement sur les systèmes d’information.
