Mettre

en œuvre
DevOps
 Mettre
en œuvre
DevOps
Alain Sacquet
Photo de couverture : îles Skellig, © Isabelle Sacquet.

© Dunod, Paris, 2016

5 rue Laromiguière, 75005 Paris
www.dunod.com
ISBN 978-2-10-074044-4
 Sommaire

Préface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XI

Avant-­propos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XIII

Première partie – DevOps et sa mise en œuvre

Chapitre 1 – Le récit DevOps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.1  Quelques définitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2  La fiche signalétique du mouvement DevOps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3  Le fonctionnement en silo de la DSI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4  Les préconisations de DevOps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.5  DevOps et DevOps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.6  Le fil conducteur du Lean Thinking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Chapitre 2 – La dimension Lean de DevOps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.1  Les piliers du Lean Manufacturing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2  La transformation assurée par le Lean Manufacturing . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3  Le modèle du pièce à pièce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.4  Les éléments Lean de DevOps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.5  Les limites de l’approche Lean Manufacturing de DevOps. . . . . . . . . . . . . . . . . . . . . 23

Chapitre 3 – La généalogie de DevOps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.1  DevOps a une histoire. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2  Les livres qui jalonnent l’histoire de DevOps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3  DevOps : une réflexion en cours. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
 VI Mettre en œuvre DevOps

Chapitre 4 – Développement et intégration continue . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.1  DevOps et le développement agile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.2  Fonctionnalités et composants logiciels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.3  L’organisation des développements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.4  Les modifications simultanées d’un composant. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.5  Les branches de développement et l’intégration. . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.6  DevOps et l’intégration continue. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.7  Les gaspillages de l’intégration tardive et les branches. . . . . . . . . . . . . . . . . . . . . . . 47
4.8  L’automatisation de l’intégration continue. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Chapitre 5 – Qualification continue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5.1  DevOps et les tests. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.2  Ingénierie du test. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.3  La tentation du traitement des tests par lots. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.4  La difficulté des tests des grands systèmes distribués. . . . . . . . . . . . . . . . . . . . . . . . . 57

Chapitre 6 – Le déploiement continu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

6.1  Pourquoi multiplier les déploiements ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6.2  En quoi consiste un déploiement ?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
6.3  La tactique de déploiement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
6.4  Le déploiement sans arrêt de service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
6.5  Des déploiements simples pour l’entreprise. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Chapitre 7 – L’appréciation du fonctionnement des releases en production . . . . . . . 71

7.1  Le cycle de vie des releases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
7.2  La supervision des activités métiers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
7.3  Lecture copernicienne de DevOps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
7.4  Supervision des infrastructures utilisées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
7.5  Détection des défauts, diagnostic et correction d’incident. . . . . . . . . . . . . . . . . . . . 75
7.6  Sûreté de fonctionnement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

Chapitre 8 – Sûreté de fonctionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

8.1  Les exigences non fonctionnelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
 Sommaire VII

8.2  La sûreté de fonctionnement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

8.3  DevOps et la sûreté de fonctionnement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
8.4  Productivité et sûreté de fonctionnement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

Chapitre 9 – Organisation, management et culture DevOps. . . . . . . . . . . . . . . . . . . . 85

9.1  La vision managériale de DevOps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
9.2  Organisation en équipes intégrées. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
9.3  Fonctionnement des équipes intégrées. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
9.4  L’organisation des productions DevOps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
9.5  La culture DevOps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

Chapitre 10 – DevOps : maintenance évolutive et gestion de projet . . . . . . . . . . . . . 95

10.1  Peut-­on faire des projets en DevOps ?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
10.2  DevOps et les différentes situations de développement . . . . . . . . . . . . . . . . . . . . . 96
10.3  Maintenance évolutive. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
10.4 Conception et développement dans le Lean Software Development . . . . . . . . . . . . 101
10.5  La gouvernance des projets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

Synthèse de la première partie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

La cohérence de DevOps et ses variantes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

Seconde partie – Conduire le changement vers la SI agile avec DevOps

Chapitre 11 – L’ampleur de la transformation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

11.1  Le point de vue des opérations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
11.2 L’évolution du rôle des productions informatiques au sein des DSI. . . . . . . . . . . . 119
© Dunod – Toute reproduction non autorisée est un délit.

11.3  Le fonctionnement des DSI aujourd’hui. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

11.4 DSI traditionnelles et DevOps : un nouveau paradigme. . . . . . . . . . . . . . . . . . . . . 123
11.5  Une transformation en marche. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

Chapitre 12 – La conduite du changement vers DevOps. . . . . . . . . . . . . . . . . . . . . . . 129

12.1  Les changements DevOps en cours. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
12.2  Un changement de type émergent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
12.3  Produire la vision DevOps de l’entreprise. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
VIII Mettre en œuvre DevOps

Chapitre 13 – Vision DevOps, architecture d’entreprise et transformation digitale. . . . . 135

13.1  Vision devOps et architecture d’entreprise. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
13.2 Cycle de vie des modèles d’entreprise et transformation digitale. . . . . . . . . . . . . . 140
13.3 DevOps et le cycle de vie des modèles d’affaires. . . . . . . . . . . . . . . . . . . . . . . . . . . 143

Chapitre 14 – Les adaptations du modèle d’entreprise. . . . . . . . . . . . . . . . . . . . . . . . . 145

14.1 Adaptations et mise en œuvre informatique d’un modèle d’entreprise . . . . . . . . . 145
14.2 Les organisations de la transformation digitale. . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

Chapitre 15 – Relation client et expérience utilisateur. . . . . . . . . . . . . . . . . . . . . . . . 153

15.1 La relation client au cœur du modèle des purs acteurs d’Internet . . . . . . . . . . . . . 153
15.2 La réaction des entreprises traditionnelles et les sites commerciaux . . . . . . . . . . . 154
15.3 L’expérience utilisateur dans le monde physique. . . . . . . . . . . . . . . . . . . . . . . . . . . 156
15.4 Une démarche marketing et commerciale globale. . . . . . . . . . . . . . . . . . . . . . . . . 158
15.5 Imitation des entreprises Internet et importation de DevOps . . . . . . . . . . . . . . . . 160

Chapitre 16 – Performance opérationnelle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

16.1  DevOps importé et DevOps choisi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
16.2  La performance opérationnelle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162

Chapitre 17 – DevOps et l’externalisation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

17.1  Faire ensemble ou faire faire ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
17.2 Impact de DevOps sur le périmètre des contrats. . . . . . . . . . . . . . . . . . . . . . . . . . . 170
17.3 Modification des périmètres des contrats ou réinternalisation ?. . . . . . . . . . . . . . . 175
17.4  La stratégie d’externalisation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178

Chapitre 18 – ITIL, DevOps et le release management. . . . . . . . . . . . . . . . . . . . . . . 181

18.1  L’opposition ITIL / DevOps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
18.2  DevOps et la transition des services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
18.3 ITIL et le modèle de fonctionnement de l’informatique. . . . . . . . . . . . . . . . . . . . 191
18.4 Le malaise des directions de la production vis-­à-­vis de DevOps. . . . . . . . . . . . . . . 192

Chapitre 19 – Un cadre de référence pour DevOps et la DSI agile . . . . . . . . . . . . . . 193

19.1  Les cadres de référence. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
 Sommaire IX

19.2  Différents modes DevOps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194

19.3 DSI multimodale et DSI agile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
19.4  Les modes DevOps par axe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
19.5  Plan de transformation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204

Chapitre 20 – CAMS et la mise en œuvre de la vision DevOps. . . . . . . . . . . . . . . . . 207

20.1  La vision DevOps et sa mise en œuvre. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
20.2 La mise en œuvre académique des changements . . . . . . . . . . . . . . . . . . . . . . . . . . 208
20.3 CAMS : les valeurs de la mise en œuvre DevOps. . . . . . . . . . . . . . . . . . . . . . . . . . 210
20.4  La difficulté de la mise en œuvre DevOps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211

Synthèse de la deuxième partie. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213

Changer grâce à DevOps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
© Dunod – Toute reproduction non autorisée est un délit.
 Préface

En professionnel de l’informatique, j’ai découvert DevOps il y a 10 ans, sans que ce

nom ne lui soit donné à cette époque, lorsque les sites d’e-­commerce cherchaient à
ouvrir de nouvelles fonctionnalités chaque semaine pour rester dans la course. Pour
y arriver, les champions avaient travaillé sur l’organisation en parallèle des équipes
– chaque semaine une équipe livrait –, et la communication était sans faille entre
ceux qui préparaient ou développaient ces nouvelles fonctionnalités et ceux qui assu-
raient le fonctionnement du site Internet. Une étincelle a jailli à cette époque dans
mes pratiques de management des systèmes d’information, issues des méthodes de
gouvernance traditionnelles de l’informatique et développées pour un monde de sta-
bilité qui avait tout le temps devant lui.
Peut-­être avez-­vous aussi déjà été confronté à cette intuition que parfois la façon
de manager les systèmes d’information n’est plus adaptée quand le rythme des projets
s’accélère, que les ressources disponibles se réduisent et que la complexité et la tech-
nicité augmentent.
Aujourd’hui, à cette intuition, on lui donne un nom : DevOps.
Son ampleur dépasse déjà la contraction (en anglais) de Development et Operations,
lieu du passage de témoin entre la construction et l’exploitation. Car c’est bien de
la transformation complète de la DSI qu’il s’agit et, plus que de nombreux ouvrages,
ce livre met parfaitement en évidence cette nécessité de changement de la DSI et
plus largement de toutes les équipes en charge de manager le SI. Il démontre aussi
très bien que DevOps, c’est pour l’Internet mais aussi pour les systèmes intranet ou
applications plus internes.
DevOps n’est pas une nouvelle mode, ni un nouvel acronyme pour briller dans les
dîners. DevOps est un guide de survie dans une économie numérique et collabora-
tive, dans laquelle les professionnels de l’informatique se sont retrouvés en première
ligne.
Pourquoi en sommes-­nous là ? DevOps n’est pas arrivé par hasard.
DevOps est la matérialisation, par un nom, d’un besoin de productivité et d’agilité
pour construire ensemble ce monde numérique où plus de 2 milliards d’individus se
connectent de partout dans le monde. Un Internet à la fois réseau des réseaux de
XII Mettre en œuvre DevOps

machines, recueil de la connaissance et de l’information, place du village pour les

échanges les plus futiles ou les plus professionnels, temple de la consommation et
même système d’exploitation pour applications en ligne et demain pour les objets
connectés. Derrière DevOps, c’est bien la transformation de l’Internet qui est en
marche, même si le champ d’application concerne tous les systèmes et pas que ceux
exposés sur Internet. Car ces choix irriguent aussi de plus en plus en interne de l’en-
treprise, et la séparation entre interne et externe est de plus en plus floue.
DevOps est arrivé quand la productivité amenée par le cloud, l’agilité demandée
par la conquête de l’Internet, et le fonctionnement 24 h/7 j amené par la mondiali-
sation de l’Internet, se sont combinés pour créer ce nouveau paradigme. L’évolution
des méthodes informatiques ne pouvait plus progresser de façon incrémentale comme
elle l’avait fait depuis le mainframe, puis le client serveur. Un point de rupture était
atteint.
C’est donc une nouvelle façon de faire de l’informatique adaptée à l’attente
numéro un des entreprises : leur transformation digitale interne et externe.
Or si la DSI a su grandir et trouver sa place dans le modèle d’informatique stable
et robuste, au point d’absorber la Direction des télécommunications et de reprendre
dans son management tout ce qui se connecte au réseau de près ou de loin, cela ne
lui préserve pas nécessairement sa place dans une époque d’informatique agile et
dynamique. Car le cloud amène aussi la possibilité aux directions métiers de mettre
en place leur propre informatique, aux utilisateurs d’amener leur propre matériel
(« BYOD »), et la quête de celui qui pilote la transformation numérique, au nom de
code « Chief Digital Office », a déjà commencé dans bon nombre d’entreprises.
Pourtant la DSI a de sacrés atouts pour assurer ce rôle, et DevOps, quand elle le
maîtrise, est la matérialisation concrète que la DSI est l’une des toutes premières
directions de l’entreprise à avoir adopté à grande échelle l’agilité. Une compétence
dont toutes les directions auront besoin, tôt ou tard. Et puis, dans une économie
numérique, il reste le socle robuste du système d’information à faire vivre, alors pour-
quoi ne pas s’organiser pour la robustesse ET pour la flexibilité, et prendre un second
coup d’avance dans cette économie numérique si puissante mais finalement si fragile ?
Je vous souhaite que ce livre déclenche l’étincelle d’une prise de conscience de
l’ampleur du changement en cours et de comment vous pourriez en tirer un bénéfice,
pour votre entreprise, votre service et même pour vous bien sûr.
Frédéric Charles
Directeur Stratégie Digitale & Innovation – SUEZ Smart Solutions
 Avant-­propos

Est-­ce une bonne idée d’écrire sur DevOps ? Ce sujet brûlant n’est-­il qu’un feu de
paille ? La question est légitime.
Pour ma part, le doute ne m’effleure pas. Après trente années passées avec mes
clients à améliorer le fonctionnement de l’informatique de leur entreprise, le mouve-
ment DevOps est une excellente nouvelle pour au moins trois raisons.
La première est que le succès de DevOps est indéniable. Les entreprises qui le
mettent en œuvre montrent qu’il est possible d’augmenter considérablement la pro-
ductivité de l’IT, la qualité des applications et la réactivité de la DSI.
La deuxième est que ce succès ne doit rien au hasard. Les pratiques de DevOps
n’ont rien de magique. DevOps est une autre façon très cohérente de faire de l’infor-
matique d’entreprise, différemment organisée, plus moderne, plus technique, où le
bon génie logiciel retrouve sa flamme et son souffle.
La troisième raison est que ces pratiques si efficaces reposent sur un système qui a
déjà fait ses preuves. Si le nom est récent, les bases sont anciennes. DevOps réalise
une transposition parfaite des principes et des procédés du Lean Manufacturing à l’IT.
Cette dimension théorique, rarement explicite, valide l’importance du mouvement
en cours et garantit son avenir. Quoi de plus pratique qu’une bonne théorie ?
Tant de vertus valent bien un ouvrage !

À qui s’adresse ce livre ?

Ce livre est destiné à tous ceux qui s’intéressent à l’informatique d’entreprise, qui la
souhaitent performante, réactive jusqu’à être instantanée, sans faille, économique,
moderne.
Il s’adresse à ceux qui souhaitent voir l’informatique de leur entreprise au rendez-­
vous de la transformation digitale, mais aussi à ceux qui s’interrogent sur l’écart qui se
creuse entre l’informatique dont ils disposent à titre personnel et celle qu’ils utilisent
au bureau.
Il s’adresse aux professionnels qui connaissent déjà DevOps mais souhaitent
approfondir leur compréhension globale de ce mouvement aux contours un peu flous.
XIV Mettre en œuvre DevOps

Il s’adresse à tous les acteurs de l’informatique d’entreprise violemment partisans

ou adversaires de DevOps qui cherchent un argument définitif dans un sens ou dans
l’autre. Il s’adresse aux éditeurs, aux gens de production ou d’études, aux architectes
et aux décideurs au cœur des transformations de l’IT ainsi qu’aux professionnels des
métiers et des maîtrises d’ouvrages qui se demandent si DevOps va enfin vraiment
changer quelque chose, sans trop y croire peut-­être.
Il s’adresse surtout aux dirigeants, et à ceux qui les conseillent, parce qu’ils ont
besoin de saisir rapidement la nature profonde de transformations déjà initiées ou aux
portes des structures dont ils sont responsables, et qu’ils n’ont pas beaucoup de temps
à consacrer à la réflexion.
Il s’adresse enfin aux étudiants et à leurs professeurs qui s’intéressent à l’organi-
sation d’entreprise, au Lean Management, à la productivité de l’informatique et qui
verront dans DevOps une transformation en marche, si ce n’est un cas d’école.

Quel est son objectif et comment est-­il construit ?

L’objectif de ce livre est de faire le point sur le mouvement DevOps, d’en comprendre
la dynamique et de permettre aux différents acteurs de l’entreprise de discerner les
avantages qu’ils peuvent tirer d’une mise en œuvre de cet ensemble de principes et
de pratiques, adapté à leur contexte.
Faire le point sur le mouvement DevOps n’est pas aisé : le mot n’est ni une marque
déposée ni un référentiel formalisé.
De quoi DevOps est-­il le nom ? La réponse à cette question est présentée dans la
première partie de cet ouvrage.

Décrire tout d’abord DevOps

DevOps est d’abord décrit comme une synthèse des différentes définitions les plus
répandues. DevOps est ainsi présenté de l’intérieur, facette par facette. La contribu-
tion du Lean Manufacturing, dans sa déclinaison en « pièce à pièce », à la constitution
de DevOps est ensuite explicitée. L’histoire du cheminement côte à côte des concep-
teurs de méthodes agiles et des théoriciens Lean est racontée, jusqu’à leur rencontre
autour du Lean IT et leur dernier pas jusqu’à DevOps.
DevOps repose aussi sur la technologie et l’ingénierie. Le processus complet de
l’informatique est décrit au long de quatre chapitres qui soulignent les apports spéci-
fiques de DevOps. Puis l’accent est mis sur la construction de la qualité et la sûreté de
fonctionnement des applications. La focale est élargie pour inclure l’aspect organisa-
tionnel de DevOps et la constitution des équipes transfonctionnelles. Une nouvelle
définition synthétique, enrichie par les chapitres précédents, est alors proposée.

Mettre ensuite DevOps en œuvre dans la DSI

La description de DevOps étant établie, la seconde partie s’attache à la mise en
œuvre de DevOps dans les DSI traditionnelles. Les écarts entre les fonctionnements
DevOps et traditionnels des DSI sont soulignés. Deux logiques différentes sont mises
 Avant-­propos XV

en évidence. La question de la conduite du changement vers DevOps des DSI tradi-

tionnelles est alors posée.
C’est un changement en cours qui prend la forme d’un « changement émergent »,
plus que d’une transformation décidée par la hiérarchie. Il en a le dynamisme, mais
il en connaît aussi les difficultés. La construction d’une vision DevOps partagée par
toutes les parties prenantes de la DSI s’avère alors nécessaire pour les dépasser, éviter
les tensions et conduire les évolutions organisationnelles. L’architecture d’entreprise
est la discipline théoriquement en charge de l’élaboration d’une telle vision mobili-
sant la direction générale et les métiers. C’est sans compter sur la révolution numé-
rique et les directions digitales missionnées depuis quelques années pour entraver
dans l’urgence l’obsolescence des modèles d’affaires des sociétés établies.
Induit par la transformation digitale, DevOps s’introduit à l’occasion des évolu-
tions des modèles d’entreprise, lesquels connaissent trois formes complémentaires.
La première est l’adaptation du modèle d’entreprise lui-­même, qui peut se traduire
par la création de filiales dédiées au canal Internet, ou par l’acquisition de start-­up
nées DevOps.
La deuxième évolution met l’accent sur la relation client afin d’éviter qu’un pur
acteur de l’Internet ne s’immisce sur le marché de l’entreprise et ne capte une part
significative de la marge jusque-­là possible dans ce secteur d’activité. Les innovations
logicielles destinées à améliorer l’expérience utilisateur ont le même objectif. Leur
développement agile repose sur le prototypage de solutions minimales testées rapide-
ment sur le marché, puis consolidées dans le cadre de DevOps.
L’excellence opérationnelle est la troisième solution entre les mains des entre-
prises traditionnelles pour résister à l’obsolescence de leur modèle d’affaires. Cette
troisième démarche fait passer l’adoption de DevOps d’une évolution importée à une
évolution choisie. Les applications digitales ont amené DevOps dans leurs valises. Le
constat de son efficacité à l’occasion des efforts d’adaptation au monde numérique
fait ensuite de DevOps un levier explicite de la transformation agile de l’entreprise et
de l’amélioration de sa performance opérationnelle.
C’est dès lors l’occasion de construire la cible de la DSI agile, d’organiser la gouver-
nance commune des développements DevOps et de ceux qui continuent de donner
© Dunod – Toute reproduction non autorisée est un délit.

lieu à des mises en production massives. C’est le moment de refonder la stratégie

d’externalisation, d’adapter l’organisation de la DSI et de la politique des ressources
humaines informatiques. C’est enfin l’occasion de maîtriser les forces centrifuges de
la DSI bimodales.

Comment lire la première partie de ce livre ?

Le plan qui vient d’être évoqué ou le sommaire permettent au lecteur pressé d’ac-
céder directement au sujet qui a sa faveur. Le livre est toutefois écrit pour être lu de
façon linéaire.
Le lecteur pressé pourra garder le chapitre 3, consacré à l’histoire de DevOps, pour
une seconde lecture, bien qu’il permette de comprendre en quoi DevOps n’est pas un
mouvement de circonstance.
XVI Mettre en œuvre DevOps

La description la plus classique de DevOps repose sur le chapitre 1 de présenta-

tion, puis court des chapitres 4 à 7 consacrés à l’ingénierie, qu’il faut encore com-
pléter par le chapitre 9 qui présente l’organisation d’une DSI DevOps et la culture
collaborative, pièce maîtresse du mouvement agile.
Les lecteurs qui ne connaissent pas le Lean Manufacturing dans sa déclinaison en
« pièce à pièce » ne doivent cependant pas omettre de prendre connaissance du cha-
pitre 3 pour comprendre la nature de DevOps lorsqu’on ne le confine pas à l’automa-
tisation des mises en production.
Deux chapitres de cette première partie sont plus personnels dans la présenta-
tion de DevOps. Le premier porte sur la notion de sûreté de fonctionnement. Cette
notion qui m’est chère étend le terme d’exploitabilité ou d’exigences non fonction-
nelles. Le second est le dixième chapitre, qui s’intéresse à la notion de projet dans
DevOps. L’introduction d’une référence au Lean Design permet de préciser la manière
de conduire les phases de conception dans une approche DevOps.

Comment lire la seconde partie ?

La seconde partie est par nature moins didactique. Elle est nourrie d’expérience et de
discussions avec les participants aux séminaires DevOps que j’anime et reflète direc-
tement les difficultés de la conduite de changement DevOps.
Elle s’ouvre sur une analyse des deux paradigmes que constituent DevOps et le
fonctionnement traditionnel. Le chapitre 11 ne doit pas être omis.
Le bref chapitre présentant la notion de « changement émergent » correspond à
mon expérience de terrain et convainc, je pense, de la nécessité de construire une
vision partagée de DevOps qui est selon moi un prérequis de la conduite du change-
ment apaisé des DSI.
Il m’a semblé nécessaire d’expliciter le lien souvent évoqué entre la transforma-
tion digitale et DevOps. Ce sujet est abordé dans le cadre de la notion d’obsolescence
accélérée des modèles d’entreprise en relation avec la révolution digitale. Il conduit
au chapitre 16, chapitre clé consacré à la recherche de la performance opérationnelle
de la DSI, et donc à la mise en œuvre de DevOps.
La question de l’externalisation est systématiquement abordée par les participants
aux séminaires sur DevOps. Le chapitre 17 tente de faire le tour de cette question très
concrète pour la mise en œuvre de DevOps, non sans recourir à la théorie des coûts
de transaction.
Le lecteur intéressé par le positionnement relatif de DevOps et d’ITIL ne man-
quera pas le chapitre 18. Le processus de release management y est décrit. Il est souvent
confondu avec le processus de déploiement. C’est un levier de la conduite du change-
ment dans la mesure où il relie ITIL et l’instrumentation DevOps.
Les évangélistes de DevOps retrouveront la description de CALMS au cha-
pitre suivant ainsi qu’une synthèse sur les difficultés concrètes de mise en œuvre de
DevOps. Il rappelle si nécessaire les valeurs de DevOps et le rôle absolument central
de la culture collaborative au sein du mouvement DevOps.
 Avant-­propos XVII

Après la lecture
Écrire sur DevOps n’alla pas sans efforts, ni plaisirs que j’espère partagés par le lec-
teur. Ce livre n’a pas de point de final car DevOps est un mouvement professionnel
ouvert qui appelle à l’échange et au débat. J’espère par conséquent vous retrouver
sur le réseau social LinkedIn. Vous pouvez également me faire part directement de
vos retours1 avant qu’un futur blog associé à ce livre nous permette de prolonger la
discussion.
© Dunod – Toute reproduction non autorisée est un délit.

1. [email protected]