D E VO PS

LE S EC R ET D E L’AGI LI TÉ DES START-U PS

À LA P O RT ÉE DES GRAN DS CO MPT E S
www.wavestone.com

Wavestone est un cabinet de conseil, issu du rapprochement de Solucom et des activités européennes
de Kurt Salmon (hors consulting dans les secteurs retail & consumer goods en dehors de France).
La mission de Wavestone est d’éclairer et guider ses clients dans leurs décisions les plus stratégiques
en s’appuyant sur une triple expertise fonctionnelle, sectorielle et technologique.
Fort de 2 500 collaborateurs présents sur 4 continents, le cabinet figure parmi les leaders indépen-
dants du conseil en Europe et constitue le 1er cabinet de conseil indépendant en France.

2

DEVOPS : VERS L’AGILE DE BOUT-EN-BOUT
À l’heure des disruptions digitales, les
entreprises cherchent par tous les moyens
à gagner en agilité et à améliorer le time-
to-market de leurs produits.
Avec un leitmotiv pour y parvenir : l’agilité !
Mais l’agilité ne se décrète pas. Elle implique
une transformation à tous les étages, depuis
les méthodes de travail jusqu’à l’architecture
même des systèmes d’information, en
passant par les organisations et les
processus de décision.
Si les méthodes agiles commencent
effectivement à se déployer dans la
conception et le développement des
produits, elles se heurtent encore à un mur
infranchissable qui sépare les « dev » et les
« ops ».
Ce mur s’est créé progressivement à travers
la construction de systèmes d’information
de plus en plus lourds, monolithiques et
fortement imbriqués entre eux. À cela se
sont ajoutés des silos organisationnels
éloignant les équipes de développement
et de production.
Pour changer, et aller vers le DevOps à
grande échelle, il faut nous inspirer des
3
ÉDITO
pratiques des GAFA. Ces géants du web ont
en effet eu la chance de pouvoir construire
leur informatique en mode green field,
en pensant dès le départ la modularité et
l’agilité.
Ce qu’ils nous apprennent, c’est que le
Devops est un subtile mélange de modularité
et de grande autonomie d’un côté, et de
règles et cadre de fonctionnement très
stricts de l’autre, pour assurer l’assemblage
de l’ensemble.
Cette publication présente les principes de
mise en place du Devops et nos convictions
pour bien entamer cette transformation en
profondeur que doivent mener toutes les
DSI.
Excellente lecture à tous !
LAURENT BELLEFIN
Directeur Associé
AUTEURS

Maximilien Moulin Hasmik Manouchian

Maximilien est manager en Architecture des
Systèmes d’Information, spécialisé sur les sujets
Cloud et Agilité. Diplômé de l’INSA de Lyon,
il débute sa carrière dans l’architecture du SI
interne d’Orange. Après une aventure entre-
preneuriale il rejoint Wavestone où il conseille
depuis 4 ans les grands comptes sur leur stra-
tégie Cloud & Agilité.
maximilien.moulin@wavestone.com
Hasmik est manager chez Wavestone dans
la practice IT Data Architecture. Elle est
spécialisée sur les sujets d’architecture
technique, d’agilité et de gouvernance.
Diplômée à l’IAE Lyon 3, elle rejoint
Wavestone. il y a 6 ans. Elle accompagne ses
clients dans leurs projets de transformation.
hasmik.manouchian@wavestone.com

Pascal Bour
Pascal est manager spécialisé en architecture
technique et industrialisation de la production.
Diplômé de l’ENSEIRB, il accompagne depuis
8 ans les clients de Wavestone lors des phases
de conception de leurs projets structurants,
ainsi que pour sécuriser et optimiser leurs
exploitations.

pascal.bour@wavestone.com

Cette p u bl i cat i o n a été ré di gé e en co llabo rat io n avec Matt hieu B arret , Franck Lenor mand et R i yad Ya k i ne.

4
 SOMMAIRE

06 DEVOPS : être agile de bout-en-bout

08 Améliorer le time-to-value en rapprochant

les O ps et les Devs

17 Pilier I : des applications modulaires et faiblement couplées

entre elles

25 PILIER II : le Continuous Delivery pour des

livraisons auto-magiques

31 PILIER III : l’Infrastructure as Code , une infrastructure

pilotée par le code applicatif

36 PILIER IV : casser les silos, développer l’agile et le travail

collaboratif

40 Mobiliser quelques champions pour amorcer

la transition vers le DEVOPS

47 Vers un modèle opérationnel pour la DSI

51 Conclusion

5
 DEVOPS
ÊTRE AGILE DE BOUT-EN-BOUT

La fourniture rapide, fiable et pertinente de services IT est devenue, quel que soit le
secteur d’activité, une composante essentielle de la compétitivité des entreprises.

Pour gagner en réactivité, sans pour autant perdre en fiabilité et qualité, les grandes
structures doivent transformer en profondeur leurs pratiques sur tout le cycle de
production IT, de la conception au déploiement.

Cette transformation est déjà bien entamée à travers la démocratisation des

méthodologies agiles, comme Scrum, qui a permis d’accélérer et d’augmenter le
nombre de livraisons applicatives. Pour autant, freiné par des temps de livraison
en production trop longs, ces méthodes ne tiennent pas encore toutes leurs
promesses. Pour vraiment améliorer le time-to-value, c’est-à-dire le temps entre
l’expression du besoin du métier et l’ouverture du service idoine, c’est l’intégralité
de la chaîne de valeur IT, du métier aux opérations, qui doit être transformée.
La démarche DevOps étend les pratiques agiles venues du développement au passage
en production pour bénéficier pleinement de l’accélération des livraisons applicatives.

POUR VRAIMENT AMÉLIORER LE TIME-TO-VALUE ,

C’EST-À-DIRE LE TEMPS ENTRE L’EXPRESSION DU
BESOIN DU MÉTIER ET L’OUVERTURE DU SERVICE
IDOINE, C’EST L’INTÉGRALITÉ DE LA CHAÎNE DE
VALEUR IT, DU MÉTIER AUX OPÉRATIONS, QUI DOIT
ÊTRE TRANSFORMÉE

6
7
 AMÉLIORER LE TIME-TO-VALUE
EN RAPPROCHANT LES OPS ET LES DEVS

Le DevOps est une démarche d‘alignement des parties prenantes de la chaîne

d e v a l e u r I T ( b u s i n e s s , d é ve l o p p e m e n t , o p é r a t i o n s m a i s a u s s i s é c u r i t é ,
architecture, compliance et autres fonctions transverses) sur un objectif métier
commun, dans le but d’accroître la réactivité de l’entreprise sur son marché.

8
Cette démarche se matérialise par
un ensemble de bonnes pratiques,
méthodologies et outils qui servent deux
objectifs :
// Aligner les objectifs entre Dev et Ops
// Automatiser l’ensemble du cycle de
production
ALIGNER LES OBJECTIFS ENTRE DEV ET OPS
Le terme DevOps est né de la contraction
des termes « Development » (équipes
de développement) et « Operations »
(équipes d’ingéniérie de l’infrastructure
et d’exploitation de la production
i n fo r m a t i q u e) . H i sto r i q u e m e n t l e s
équipes assurant la construction et
l’exploitation du SI ne faisaient qu’une,
mais la complexité des architectures et la
croissance importante du SI ont poussé
à une séparation nette entre ceux qui
font évoluer le SI (les Devs) et ceux qui
assurent son exploitation et son bon
fonctionnement (les Ops).
9
D E VO PS WA S H I NG
I l n’y a p a s à ce j o u r d e d éf i n i t i o n
uni q ue fa i s a nt co n s en s u s s u r l e term e
Dev Op s . Cert a i n s , co m m e Fo rrester,
l e d éf i n i s s ent co m m e l a créat i o n
d ’un pi pel i n e d e l i vra i s o n l o g i ci el l e
a uto m at i s é  ; d ’a u t res , co m m e
G a r t n er, i n s i stent s u r l ’a d o p t i o n d e
p rat i q u es Lea n et a g i l es p o u r l i vrer
ra pi d em ent u n s ervi ce I T. Cette
a b se n ce d e d éf i n i t i o n p réci s e et l e
« b ra n di n g  » d e n o m b reu x o u t i l s
sous l a term i n o l o g i e D evOp s , d o n n e
cl a ire m ent l a s en s at i o n d e vi vre u n
« DevOps wa sh i n g  » , s u ccéd a nt l es
va g u es d e «   Green wa sh i n g  » p u i s
« Cl o u d wa sh i n g  » d es d ern i ères
a nn ées . I l co nvi ent d o n c d ’êt re
v ig i l a nt et d e n e p a s s e l a i s s er
p ren d re a u j eu d es ét i q u ettes .
Le mur de la confusion

APPLICATION
DÉPLOYÉE

ÉQUIPE «DEVELOPMENT» ÉQUIPE «OPERATIONS»

CULTURE PRODUIT CULTURE SERVICE
Avec des objectifs : Avec des objectifs :

d’ INNOVATION & FONCTIONNALITÉS de STABILITÉ & RATIONALISATION

Adapter le SI aux demandes du marché Maintenir la disponibilité en contrôlant

en faisant régulièrement évaluer le les évolutions pour réduire les risques
produit de pannes
= =
MAXIMISER LE CHANGEMENT MINIMISER LE CHANGEMENT

10
Aujourd’hui, la collaboration entre
les équipes de développement et les
opérations est souvent douloureuse.
Leurs mandats respectifs a priori peu
compatibles – innovation, évolution et
réactivité pour les Devs, stabilité et fiabilité
du SI pour les Ops – ainsi que leurs fortes
dépendances mutuelles expliquent la
complexité de leur relation. Cet état peut
se traduire par un manque de performance
mais aussi par un « agacement » mutuel.
Parce qu’elles n’impliquent que trop
peu les équipes d’exploitation, les
méthodologies agiles, telles qu’appliquées
dans la plupart des grandes entreprises,
n’ont pas remédié à ce problème. Au
contraire, l’accélération du rythme de
livraison applicative et la philosophie
test & learn ont parfois creusé encore plus
le fossé. Les équipes d’exploitation doivent
déployer en production un nombre
croissant d’évolutions, avec souvent une
augmentation des taux d’erreurs alors que
l’exigence de fiabilité reste constante.
Cela mène non seulement à la création
d’un goulot d’étranglement au niveau
du passage en production, mais aussi
à toujours plus de « frottement » entre
11
l e s é q u i p e s d e d éve l o p p e m e n t e t
d’exploitation.
Les pratiques et outils DevOps permettent
d’intégrer l’ensemble des acteurs de la
chaîne de valeur IT au sein d’un processus
unique, intégré et continu reposant sur
les principes agiles (itérations, forte
collaboration business, test & learn…)
e t s u r u n e vé r i t a b l e c u l t u re d e l a
collaboration entre les Devs et les Ops.
A U TO M AT I S E R L’ E N S E M B L E D U C YC L E D E
PRODUCTION
Le DevOps repose également sur la mise
en place d’outils d’automatisation sur tout
le cycle de production IT : automatisation
de la fourniture d’infrastructure, de la
construction applicative, des tests et du
déploiement applicatif.
Cette automatisation a pour intérêt
premier d’absorber l’augmentation du
volume et du rythme des tests découlant
du fonctionnement itératif. Elle est donc
indispensable pour garantir la qualité du
code applicatif à chaque itération sans
créer un goulot d’étranglement en aval
de la construction applicative.
 EXEMPLE DE KPIs

QUELQUES EXEMPLES D’INDICATEURS : ET LES GAINS ESCOMPTÉS * :

Nombre de livraisons applicatives 200x plus de livraisons

Temps de mise en production 2 555x plus rapide

Nombre d’incidents 3x fois moins d’incidents

Temps de résolution (MTTR) 24x plus rapides à résoudre

Nombre de rollbacks 0 rollback

... * Puppet & DORA 2016 State of DevOps Report

Parce qu’elle permet de réduire les erreurs Le DevOps met en avant l’automatisation
humaines et de faciliter la mesurabilité de l’ensemble du cycle de fabrication et
à chaque étape, l’automatisation dans de déploiement. De ce fait, avec l’outillage
la démarche DevOps est également approprié tout devient mesurable sur
un levier pour fiabiliser et améliorer de l’ensemble du cycle. La mesure est la
manière continue l’ensemble du cycle de clé qui permet l’adhésion des parties
fabrication et de déploiement. prenantes à la démarche et à son
amélioration continue. C’est par là même
Une automatisation performante et
que l’on pourra lutter contre le « DevOps
adaptée de l’ensemble du cycle est le
washing », mais aussi disposer des bons
principal levier pour éviter le goulot
indicateurs pour démontrer les gains sur
d’étranglement entre le développement
tout le cycle.
et la mise en production. C’est la clé pour
sortir les équipes d’exploitation du rôle
de « pompier » (gestion d’incidents en
continu) dans lequel elles tendent à être
poussées suite à la démocratisation des
pratiques agiles.

12
 LE DEVOP S , N’EST PAS  :

• U N P RO D UI T F I N I ou une d é m a rche g é né r iq ue. I l n’y a p a s u n e t h éo ri e

g én éral e a p p li ca b le à tous, il e st né ce ssa i re d ’a d a p ter l es b o n n es
p rati qu e s Dev O p s à un contexte d ’e nt re p r i se.

• U N E FU S I O N d e s m issi ons d e s Devs et d e s O p s. En co ro l l a i re,

D evO ps n’ i nd ui t p a s né ce ssa i re m e nt un cha ngem ent d e l a st ru ct u re
o rg an i s at ionne ll e ; Devop s n’ im p ose p a s non p l u s l e reg ro u p em ent d es
d eu x éq ui p e s a u se in d e l a m ê m e.

• U N E A P P RO CH E Q UI CK & DI RTY i g nora nt l e s p roces s u s o u i n d u i s a nt u n e

p er te d e cont rôl e. La m i se e n p rod uct i on re ste d ’a i l l eu rs g én éra l em ent à
l a m ai n d e s O p s.

13
4 PILIERS POUR CONSTRUIRE LE DEVOPS
EN RAPPROCHANT LES OPS ET LES DEVS

Pour bien appréhender ce qu’est le DevOps, il faut comprendre ce sur quoi il

repose :
// Un brin d’automatisation

// Et beaucoup de collaboration !

14
 S I L A CO L L A B O R AT I O N S E D O I T D ’ Ê T R E O M N I P R É S E N T E , L’A U TO M AT I S AT I O N P E U T S E
DÉCLINER DANS TROIS COMPOSANTES

LA COLLABORATION qui est le liant de tous ces piliers en

favorisant l’alignement entre Devs et Ops.

CULTURE DE LA COLLABORATION

APPLICATION CONTINUOUS DELIVERY

L’APPLICATION EN ELLE-MÊME qui
doit être modulaire, intégrer les in-
FILE 1 MANIFEST
formations concernant l’infrastruc- BUILD
Env a : Desc Infra a
ture à déployer, les éléments liés
FILE 2 Env b : Desc Infra b
à l’exploitation ainsi que les tests
automatisés à réaliser.
DEPLOY ENVY

API TEST

INFRASTRUCTURE AS CODE

L’INFRASTRUCTURE AS CODE, qui doit délivrer de façon LE CONTINUOUS DELIVERY qui doit
automatisée et via une interface standardisée des offrir un pipeline permettant
environnements d’exécution pour l’application en fonction de tester l’application de façon
des besoins exprimés au sein de son code source. automatisée et de la déployer
sur le bon environnement au bon
moment.

15
Ainsi, pour réussir sa transformation // L’Infrastructure as Code : tendre
DevOps, il est nécessaire de travailler sur vers une infrastructure service
4 axes en parallèle, qui constituent les consommable, puis intégrable à la
4 piliers du DevOps : livraison applicative

// L ’A p p l i c a t i o n : p r é p a r e r l a // La Collaboration : changer la culture

transformation des applications et les pratiques pour tendre vers une
e n l e s re n d a n t m o d u l a i re s e t organisation sans silos et tirée par
automatisables des méthodologies agiles

// Le Continuous Delivery : automatiser

la chaîne de livraison de la phase
de développement à la mise en
production

L’application une fois construite

CULTURE DE LA 1 (compilée) doit être déployée
sur un environnement (de test,
COLLABORATION d’intégration, de production, …).

Le pipeline de Continuous Delivery

APPLICATION CONTINUOUS 2 fait appel à l’API de l’infrastructure
DELIVERY pour demander la construction de
l’environnement.
FILE 1 MANIFEST
Env a : Desc Infra a BUILD
L’infrastructure utilise le fichier
Env b : Desc Infra b
FILE 2 1 de configuration (Manifest)
3 de l’application pour créer
l’environnement adapté à
DEPLOY ENVY l’application.
3 2

5
6 L’infrastructure orchestre dès
API 4 lors la création effective de
4 TEST
l’environnement.

INFRASTRUCTURE Une fois l’environnement en

AS CODE 5 question créée, l’application est
déployée dessus.

L’application peut alors être testée

6 comme indiquée à partir des tests
indiqués dans le code applicatif.

16
 PILIER I
DES APPLICATIONS MODULAIRES ET FAIBLEMENT
COUPLÉES ENTRE ELLES

17
UNE ARCHITECTURE NÉCESSAIREMENT PLUS
MODULAIRE
Être plus agile implique de livrer de
nouvelles versions applicatives plus
s o u ve n t e n ré p a r t i s s a n t l e t rava i l
sur plusieurs équipes (petites et
pluridisciplinaires, des « feature teams »).
Cela nécessite dès lors de découpler
leur travail pour plus d’efficacité et donc
d’utiliser des architectures applicatives
plus modulaires.
Si les architectures orientées services
ont été étouffées par une gouvernance
centralisée et rigide, il s’agira ici de
privilégier des approches décentralisées
redonnant de l’autonomie aux
développeurs dans leur publication et
consommation.
ARCHITECTURE MONOLITHIQUE
HS
 X X 
Équipe A Équipe B Équipe C
Sur une architecture monolithique, une seule intervention
est possible à un instant t, chaque livraison
embarque le monolithe.
Une application ainsi construite est un
assemblage de modules (jusqu’à plusieurs
dizaines), qui sont autant d’éléments
de code indépendants, chacun sous la
responsabilité d’une « feature team » :
petite équipe autonome qui réalise le
think, le build et le run du module.
Les échanges entre modules sont
standardisés et s’appuient sur des
interfaces (API) permettant de les
découpler. Ces APIs pourront utiliser des
solutions de gestion (API management)
afin de rendre les développeurs
autonomes sur leur création, publication et
consommation. Cela nécessitera toutefois
de mettre en place des solutions de
cartographie des services pour éviter
toute perte de contrôle du SI.
ARCHITECTURE MODULAIRE
HS
 
Équipe A Équipe B Équipe C
Sur une architecture modulaire, plusieurs équipes peuvent
travailler en même temps sur différents modules.
18
Au-delà de la tendance, cette approche
est aussi un facilitateur important dans
une démarche de développement Agile,
à la fois pour améliorer la qualité du code,
faciliter le travail en équipe, accélérer
l’exécution des tests, etc.
L E C AS D E S MICRO-S ERV ICES
Parad i g m e i s s u d e s p rat i q ue s d e s
acteu rs B 2 C à t rè s l a rg e a ud ie nce,
l ’arc h i tect u re m icro-se r v ice of f re
n ot am m ent u n e ré p onse à un b e soi n
d ’ext rêm e s cal a b i li té d e fonct i ons
préc i s es d’u n systè m e. Da ns une
l o g i q u e de d é com p osit ion d ’un
pér i m èt re fo n ct i onne l e n se r v ice s
à fi n e m ai l l e a utonom e s m a i s
co l l ab o rant ent re e ux , le s p rat iq ue s
d’arc h i tect u re, d ’ inf ra st r uct ure
et d’ex pl o it at ion d oive nt
s i g n i fi cati vem ent évol ue r p our g é re r
u n e co n stel l at ion d e m icro-se r v ice s
i n stan c i abl es à l a vol é e et volat i le s.
Dans une approche modulaire, les
éléments constituants l’application doivent
donc être très faiblement couplés, et ceci
à tous les niveaux :
// Vis-à-vis de framework ou de
bibliothèques, qui peuvent être
utilisés comme des outils mais ne
19
doivent pas définir la structure de la
couche applicative.
// Entre modules de l’application
et vis-à-vis de l’extérieur pour
simplifier la réalisation de tests.
Les modules de l’application
doivent être testables de manière
unitaire sans nécessiter d’interface
utilisateur, de base de données ou
d’autres applications. Ceci impose
d’accorder une grande importance
aux tests unitaires au sein du code
de chaque module de l’application,
ainsi qu’à la constitution de bouchons
pour permettre de tester un service
unitairement.
// Vis-à-vis de l’Interface utilisateur.
Celle-ci doit pouvoir être remplacée
sans aucun impact sur la couche
applicative et ses fonctions.
// Vis-à-vis de la persistance des
données. Pour pouvoir être scalable,
ce type d’architecture requiert
un fonctionnement stateless des
services. La persistance des données
et des sessions doit être gérée de
façon à pouvoir assurer une montée
ou une baisse de charge tout en
garantissant la cohérence des
données.
// Vis-à-vis de toute autre fonction
externe à l’application issue d’autres
applications ou services.
UNE MISE EN PRODUCTION RAPIDE ET
MAÎTRISÉE
La conception d’applications en mode
DevOps nécessite de renforcer les
tests réalisés (notamment par leur
automatisation) et de prendre plus de
risques dans les mises en production.
Cela signifie une évolution des méthodes
de développement et l’introduction de
nouvelles démarches comme l’approche
«   Te s t D r i v e n D e v e l o p m e n t   » , l e
« Feature Flipping » ou le « Blue-Green
Deployment » pour mettre en production,
partiellement ou de façon ciblée, certaines
fonctionnalités.
De la même façon, cela induit de concevoir
l’application pour qu’elle soit directement
exploitable et ne pas attendre le moment
d e l a m i s e e n p ro d u c t i o n p o u r s e
préoccuper de sa mise sous supervision,
sous sauvegarde, de la conception de
nouveaux scripts d’automatisation, des
problématiques de performance, de
scalabilité et autres problématiques
d’exploitabilité.
20
 TESTS UNITAIRES : L’APPROCHE TEST-DRIVEN DEVELOPMENT

LORSQUE LE DÉVELOPPEUR CODE UNE FONCTION, IL SUIT GÉNÉRALEMENT 3 ÉTAPES :

1 Écrire le code source de la fonction ;

2 Écrire le code source du test unitaire relatif à la fonction ;

3 Exécuter le test unitaire relatif à la fonction pour vérifier qu’il passe.

AVEC UNE APPROCHE TEST DRIVEN DEVELOPMENT, LE DÉVELOPPEUR FAIT L’INVERSE :

1 Écrire le code source du test unitaire relatif à la fonction à développer ;

2 Écrire le code source de la fonction permettant de passer le test ;

3 Retravailler le code pour l’améliorer tout en s’assurant que le test continue

de passer.

Cette méthode permet de s’assurer que chaque fonction est bien associée à un ou
plusieurs test(s) unitaire(s) et facilite ainsi les tests de non-régression tout en
précisant les spécifications puisque le test décrit le comportement attendu.

TEST-DRIVEN DEVELOPMENT

1 TEST FIRST 2 DEVELOP 3 REFACTOR

Rédaction du test Écriture du code minimal Réécriture du code

correspondant à la fonctionnel pour de manière optimisée
fonctionnalité à développer passer le test

Vérification de l’échec Vérification de la validation Vérification de la validation

du test du test du test

Répéter le cycle pour les nouvelles fonctionnalités

21
EXEMPLE DES MÉTHODES DE DÉPLOIEMENT

Web Server App Server DB Server

Version n

BLUE/GREEN Version n+1

DEPLOYMENT

Déploiement d’une version n+1 sur un environnement parallèle à la version de

production n et bascule facilitée de n vers n+1 et de n+1 vers n (rollback).

Version 3

UTILISATEURS
INTERNES

Version 2

petit groupe
d’utilisateurs

CANARY
RELEASE Version 1
CLIENTS

Déploiement de plusieurs versions en parallèle, certaines versions (voire

fonctionnalités) ne sont ouvertes qu’à certaines populations (alpha puis beta testeurs)
avant d’être (ou pas) généralisées.

22
 Version 1A
67%
50% de conversion

Version 1B
A/B TESTING CLIENTS
50%
11%
de conversion

Déploiement de 2 variantes d’une même version en parallèle pour en comparer

les résultats et en déduire laquelle conserver.

NEW FEATURE FEATURE FLAG OR CONSUMERS

TOOGLES

ON

OFF
FEATURE
FLIPPING OFF

Déploiement de fonctionnalités activables via une interface de l’application.

Permet notamment de ne pas activer certaines fonctionnalités si les tests ne passent pas
sans pour autant freiner la mise en production. Peut être couplé à canary release.

23
Les tests fonctionnels (ou recettes)
d o i ve n t e u x a u s s i ê t re l a rg e m e n t
automatisés pour pouvoir vérifier l’absence L’ANO NY M I S ATI O N D E S
de régressions fonctionnelles à chaque D O NNÉ E S
itération et valider le bon comportement
des fonctions nouvellement créées ou
modifiées.
Da ns ce r t ai n s s ecteu rs ( b a n q u e et
Cela n’est pas trivial et suppose d’être a ssura nce n ot a m m ent ) l e b es o i n
en capacité de tester les appels aux d ’a nony m i s at i o n d e l a d o n n ée
fonctions ainsi que les interactions d ev i e nt d e p l u s en p l u s p ro n o n cé.
homme-machine, de pouvoir récupérer Da ns ce contexte, l a m i s e en p l a ce
et analyser les éléments (données ou d u Dev O p s d o i t i n cl u re l a ca p a ci té
éléments graphiques) retournés et de d ’a utom at is at i o n d e l ’a n o ny m i s at i o n
maintenir et faire évoluer l’ensemble des d e s d onné e s d e p ro d u ct i o n u t i l i s ées
jeux de données nécessaires à l’exécution p our les test s fo n ct i o n n el s .
des tests.
Ce ci re prés ente u n ef fo rt n o n
La mise en place de cette automatisation, né g l ig e a bl e à ce j o u r, l e m a rch é
encore plus que pour les tests unitaires, n’of f ra nt p as en co re d ’o u t i l s m at u res .
p e u t re p ré s e n t e r u n e c h a rg e n o n
négligeable pour une application existante
et peut entraîner un allongement des
Pour autant, les études montrent qu’une
charges et délais à mettre sous contrôle.
approche DevOps permet de réduire
jusqu’à 22%* le temps passé sur du travail
non planifié (bugs) ou sur la reprise de
LA D E T T E T EC H N I Q U E N ’ E ST PA S G Ê N A N T E code.
SI ELLE EST SOUS CONTRÔLE
Dette Totale
L a co n st r u c t i o n p l u s ra p i d e d ’ u n e
application amène forcément à faire Dette toxique
des compromis. On « contracte » ainsi (ancienne)
rapidement et naturellement une dette
technique (code, infrastructure, outils
de gestion) que l’on «  rembourse  »
t o u t a u l o n g d e l a v i e d u p ro j e t .

En revanche il n’est pas utile de chercher à

atteindre le zéro dette, au-delà du risque Dette saine
de surqualité, c’est aussi un frein réel à (récente)
l’agilité.
Atteignable en pratique Temps
* Puppet & DORA 2016 State of DevOps Report Idéalement

24
 PILIER II
LE CONTINUOUS DELIVERY POUR DES
LIVRAISONS AUTO-MAGIQUES

Le Continuous Delivery (CD) est une chaîne de construction logicielle

a u t o m a t i s é e . I l s ’a g i t d ’ u n e n s e m b l e d e p ro c e s s u s , o u t i l s e t t e c h n i q u e s
permettant de gérer les livraisons applicatives, depuis la production du code
à la livraison de la fonctionnalité en passant par le build, le déploiement, les
tests, le packaging… L’objectif ? Augmenter la fréquence et la rapidité des
livraisons de manière fiable, rapide et continue.

DÉVELOPPEMENT D’UNE
NOUVELLE ITÉRATION

TEST BUILD
1
3

2
DEPLOY

25
On considère habituellement que le
Continuous Delivery s’appuie sur deux
chaînes d’automatisation :
// La chaîne de Continuous Integration
(CI), ciblée pour le développement
intégrant les processus de build, de
mesure de la dette technique (qualité
du code), des tests unitaires et de
user acceptance ;
// La chaîne de Continuous
Deployment, étendant la chaîne
CI par l’automatisation de la mise
à disposition des environnements
d’infrastructure et des livraisons
applicatives. Cette extension est
prise en charge par les exploitants
en s’appuyant sur des méthodologies
et outils quasi-identiques à ceux
des développeurs. L’exploitant gère
ainsi la consommation d’éléments
d’infrastructure, de configuration
management et le déploiement
applicatif.
Jusqu’à la mise en production, l’ensemble
de la chaîne est automatisée. L’Ops
doit dans un premier temps valider un
certain nombre de prérequis, comme
l’adhérence de l’application avec le
reste du SI, la disponibilité suffisante
des ressources au sein des équipes pour
réagir en cas d’incident, la disponibilité des
infrastructures, l’opportunité du moment
pour déployer une nouvelle version, etc.
Une fois ceci géré, ne lui reste plus qu’à
déclencher le déploiement de l’application
(déploiement « push-button »).
En revanche, le déploiement sur d’autres
environnements (hors-production, pré-
production) peut être complètement
automatisé.
À partir d’un certain niveau de maturité,
il est tout à fait envisageable d’imaginer
un déploiement automatique de bout-en-
bout (cf. schéma ci-contre).
C H O I S I SS E Z L’O U T I L LAG E E N FO N C T I O N D E
VOTRE CONTEXTE, PAS DE SON ÉTIQUETTE
Aujourd’hui, l’outillage de la chaîne de
Continuous Delivery est assez hétérogène :
chaque fonction a son outil à choisir parmi
une myriade de solutions, le marché
de l’outillage DevOps étant en pleine
effervescence.
La première raison tient en l’absence
de définition claire et partagée de
DevOps ce qui permet à de nombreux
éditeurs d’appliquer l’étiquette DevOps
sur tout outil ayant trait à la conception
logicielle, à l’usine logicielle, à la gestion
de configuration ou toute autre forme
d’orchestration (« DevOps washing »).
26
 CODE BUILD TEST DEPLOY

Continuous Integration

Source Code Builds Tests

Management automatisés automatisés

Continuous Deployment
Un commit déclenche Un build réussi lance Si les tests passent,
le build les tests le build est validé

À ce stade, le code Déploiement

est déployable à automatisé
tout moment

Continuous Delivery

27
De plus, beaucoup d’outils essaient d’étendre leur scope au-delà de leur champs
technico-fonctionnel traditionnel, ce qui contribue à complexifier les réels apports
respectifs des différents outils sans pour autant offrir une vraie suite logicielle de
bout-en-bout.

Pour s’y retrouver, nous proposons de classer les outillages selon la matrice suivante :

CONTINUOUS INTEGRATION

SOURCE CODE MANAGER CONTINUOUS INTEGRATION SERVER

• git • Bitbucket • Github

• AWS CodePipeline • XL
• CodeCommit • CVS
Release • TC • B amboo
• Subversion • Mercurial •
•Travis CI •
Helix •

BUILD TEST

• J Unit • Selenium
• Maven • Gradle • Grunt •
• S auce Labs • Test
Apach ANT • NPM •
Complete•

CODE QUALITY

• SonarQube • Kiuwan •
Semmle •

28
 DEPLOYMENT CONFIGURATION MANAGEMENT

• IBM Active Deploy • XL

• Vagrant • Puppets Labs •
Deploy • Google Cloud
Chef • Ansible • S altstack •
Deployment Manager •
Terraform • CF Engine •
Container & orchestration

Docker • Kubernetes • Mesos •

COLLABORATION

• Trello • Slack • Jira• HipChat •

Continuous Integration Continuous Deployment Collaboration

L’absence de consensus sur la mise en œuvre de DevOps empêche l’industrie logicielle

de proposer aujourd’hui des solutions dédiées. Pour autant, ces solutions feront leur
apparition dans les prochaines années tout en imposant leur mode de fonctionnement
(et donc certaines pratiques).

29
Le choix du type d’outillage se fera en fonction du contexte de l’entreprise : selon si
elle est de type  « early adopter » elle préfèrera un modèle Best of Breed ou une solution
se basant sur un Cloud public et son outillage associé ; si elle est de type « follower »
elle pourra choisir la suite intégrée d’un fournisseur du marché ou la solution clé en
main d’un infogérant.
EARLY ADOPTERS

CLOUD PUBLIC BEST OF BREED

ADOPTION

SUITE ÉDITEUR
INFOGÉRANT
COMPLÈTE

COMPÉTENCES INTERNES
EXPERTISE

Enfin, certains outils doivent naturellement // Les outils de publication des résultats
être centralisés quand d’autres peuvent d’analyse.
être instanciés par équipe pour que
chacune puisse garder la main sur le Tandis que les outils que l’on est amené à
rythme de mise à jour de l’outil en question instancier par équipe peuvent être :
ou pour en gérer certaines spécificités de // Le builder d’applications ;
configuration.
// Les outillages de tests unitaires, cou-
Généralement les outils centralisés et
verture de code, respect des normes
partagés par tous sont :
de codage ;
// L e g e s t i o n n a i re d e s o u rc e s /
artefacts (librairies, fichiers de // Les outils de déploiement (configu-
configuration…) ; ration management et déploiement
applicatif).
// Les outils de gestion de la couverture
des tests ;

30
 PILIER III
L’INFRASTRUCTURE AS CODE, UNE INFRASTRUCTURE
PILOTÉE PAR LE CODE APPLICATIF

L’Infrastructure as Code (IaC) est l’étape ultime d’agilité et de banalisation

de l’infrastructure.

31
Depuis plusieurs années beaucoup
de progrès ont été faits sur le marché
pour tendre vers l’automatisation et la
consommation de l’infrastructure : on parle
« as a service », « on demand », catalogue
de services, Cloud, API… L’Infrastructure as
Code pousse plus loin encore cette idée.
Le but de l’IaC est de permettre la
c ré a t i o n e t l a c o n f i g u ra t i o n d ’ u n
environnement d’exécution complet
(éléments d’infrastructure et middleware)
automatiquement au travers du code
applicatif. Les développeurs manipulent
ainsi l’infrastructure dans le code même
de l’application, au même titre qu’une
fonctionnalité.
L’IaC permet donc de définir
l’infrastructure d’une manière nouvelle :
l’infrastructure n’est plus que simple
puissance de calcul, scalable sans
difficulté, manipulable par les Devs à
travers des langages de codes applicatifs
habituels.
COMMENCER À RENDRE L’INFRASTRUCTURE
AGILE EN L’AUTOMATISANT
B i e n e n te n d u , l ’a u to m at i s at i o n d e
l’infrastructure reste un prérequis à
l’IaC : pour manipuler de l’infrastructure
au travers du code applicatif, il faut que
l’infrastructure soit exposée à travers des
interfaces programmatiques (APIs).
Cette automatisation peut se faire en
3 étapes, qui correspondent à 3 niveaux
de maturité.

L a m is e en œ u v re d ’u n I a C à l ’ét at d e l ’a rt n’e st p a s u n p ré- req u i s au D ev Op s :

vo u s p o u vez d ém a r re r vos p re m ie rs p roj et s e n aya nt a u to m at i s é s eu l em ent u n e
par ti e d e vot re i nf ra st r uct ure et te nd re ve rs une I nf ra st ru ct u re a s Co de
d e b out-e n-b out p a r i té rat ions succes s i ves .

32
 La première étape de fourniture
1
de l’enveloppe de la machine
virtuelle est souvent la plus simple.
Dans une optique DevOps, il faudra
cependant lever les derniers freins
à une automatisation complète
(souvent la configuration réseau) et
être en mesure de provisionner en un
clic cet environnement.
La deuxième étape de
2
déploiement des middlewares
est déjà plus complexe.
Pour faire simple on pourra par
exemple, créer des modèles de
m a c h i n e s v i r t u e l l e s a ve c d e s
middlewares préinstallés mais cette
méthode atteint vite ses limites
(difficulté à gérer le cycle de vie
du modèle, à ajouter un nouveau
m i d d l ewa re , e tc . ) . I l e s t d o n c
préférable de s’outiller pour être en
mesure de provisionner directement
les machines et middlewares requis
de façon automatisée éventuellement
en ayant même défini des topologies
applicatives (déploiement d’un
ensemble d’éléments suivant un
schéma défini au préalable).
Enfin la troisième étape est souvent
3 ou s o l u t i o n s éd i teu rs d ép l oyées
la plus complexe puisqu’elle requiert
d’interagir avec d’autres éléments de
l’infrastructure (un firewall, un load
balancer, une passerelle d’échanges,
etc.) pour fournir à l’application un
environnement d’exécution complet.
33
Ces trois étapes peuvent être réalisées
séquentiellement ou en une fois
selon le degré d’automatisation de
l’infrastructure.
Il est également nécessaire de tendre
vers une automatisation des services
d’infrastructure : sauvegarde, supervision
technique et applicative, ordonnancement,
sécurité. La cible étant que la résilience, la
sécurité, les services d’exploitation soient
directement gérés dans l’application
par les développeurs eux-mêmes, il est
important que les développeurs puissent
s’abonner à ces services directement au
travers d’une API.
LE PAA S ,
UN ACCÉ LÉ R ATE UR
Le s o u t i l l a g es Pa a S ( P l at fo rm a s
a Servi ce) s o nt d e fo rm i d a b l es
a ccél érateu rs p o u r p eu q u e l ’o n
re lève l e d éf i d e l eu r i ntég rat i o n
a u S I et n ot a m m ent à l a ch a î n e
d ’exp l o i t at i o n .
O n se m éf i era a i n s i d es s o l u t i o n s d e
Pa a S P ri vés (d ével o p p ées en i ntern e
on-p rem i s es) s o u vent p eu m at u res ,
q ui n’ i ntèg rent p a s s i m p l em ent
l e s p ro b l ém at i q u es d es s ervi ces
d ’ i nf ra st ru ct u res (s a u veg a rd e,
supervi s i o n , rés ea u & s écu ri té) .
B A N A L I S E R L’ I N F R A S T R U C T U R E P O U R UTILISER LE CLOUD PUBLIC EN CAS DE
RENDRE LES DÉVELOPPEURS AUTONOMES PROJET PARTANT D’UNE PAGE BLANCHE
L’automatisation de ce processus ne L’outillage est avant tout une question de
suffit pas à elle-seule à constituer une contexte. Les outils sont nombreux : de
Infrastructure as Code, il est nécessaire celui bien limité à une fonction particulière
de rendre accessible ce déploiement via à la suite complète de grands éditeurs
une API et de pouvoir définir, dans le code en passant par les solutions pure-player
source de l’application, l’infrastructure Cloud, il en existe pour tous les contextes.
requise pour faire fonctionner
Ainsi une organisation avec de fortes
l’application :
compétences techniques en interne n’aura
// Nombre de serveurs et middlewares pas la même stratégie qu’une entreprise
associés ; ayant l’habitude de s’appuyer sur des
ressources externes. De la même façon
// Services applicatifs à déployer (cache une entreprise prête à prendre des risques
mémoire, queue de messages, etc.) ; pour se différencier (« early adopter »)
ne réagira pas de la même façon qu’une
Ce l a d o i t p e r m e t t re d e b a n a l i s e r
entreprise qui cherche de la stabilité et
l’infrastructure pour ne plus offrir aux
des solutions matures pour assurer son
développeurs qu’une simple puissance
fonctionnement.
de calcul.
EARLY ADOPTERS

SOLUTION CLOUD PUBLIC SOLUTION BEST OF BREED

composée de plusieurs logiciels

Microsoft • Azur • Heroku • Acquia •

Engine Yard • SAP • ORACLE Cloud • Chef • CF Engine • Ansible • Puppets
Google Cloud platform • IBM • Labs • S altstack •
Amazon web services •
ADOPTION

PLATEFORME DE SON INFOGÉRANT SUITE ÉDITEUR COMPLÈTE

IBM • Atos • Linkbynet • Sygma • HCL

• Capgemini • GFI • CGI • Tata • Wipro
BMC • WM Ware • IBM• HP• CA
• Cloud Temple • Accenture • Orange
• Atlassian •
Business Service • Sopra • Steria • CSC •
Claranet • HP Enterprise •

COMPÉTENCES INTERNES
EXPERTISE

34
L’approche Cloud public est quoiqu’il
arrive une approche à considérer, tant
les acteurs de ce type de Cloud sont en
avance sur le marché. Amazon, Microsoft,
Google atteignent un niveau de maturité
qui ne saurait être rattrapé par des équipes
internes d’entreprises dont ce n’est pas le
cœur de métier. Il convient donc dans une
stratégie Cloud privé de savoir pourquoi
et pour quels workloads l’on adopte cette
stratégie.
35
Enfin lorsque l’on conçoit une IaC,
il est indispensable de standardiser
l’infrastructure et donc faire des choix :
// Choisir où investir l’effort pour auto-
matiser et industrialiser des compo-
sants qui font sens.
// Accepter de ne pas intégrer les
workloads qui n’entreraient pas dans
ce standard. Ce qui implique égale-
ment que toute nouvelle application
doit être conçue pour suivre ces
standards.
 PILIER IV
CASSER LES SILOS, DÉVELOPPER L’AGILE
ET LE TRAVAIL COLLABORATIF

La culture DevOps puise ses sources dans les méthodes Agiles et le Lean (responsabiliser,
faire confiance, respecter, communiquer avec transparence) ainsi que sur une approche
« Business-centric », catalyseur d’une plus grande collaboration entre les Métiers,
le Développement et la Production.

36
Ce changement culturel ne peut pas se
faire du jour au lendemain, et il convient
de l’échelonner sur 2 grands paliers :
SUR UN PROJET
1
// Former une équipe qui embarque toutes
les compétences (Dev, Ops mais aussi
architecture, sécurité, compliance…)
// Orienter le métier d’Ops sur la construc-
tion de nouveaux services automatisés
// Responsabiliser les Dev sur l’exploita-
bilité de leur produit
DANS L’ENTREPRISE
2 collaboration.
// Généraliser ce mode de fonctionnement
à la majorité des projets
// Diffuser la culture DevOps à tous en par-
tageant les enjeux et les success stories
// Planifier l’évolution des modèles et l’or-
ganisation de la DSI
Pour ce faire, il faut adopter un langage,
des indicateurs et des outils communs et
partagés :
// Avoir une vision « produit » et non
plus « projet » : les équipes réalisent
un produit qui sera utilisé par un
client final et ne contribuent plus
seulement à un projet lambda.
37
// Faire évoluer les indicateurs pour
ne plus objectiver les développeurs
sur la seule qualité de leur code ou
fréquence de leur release mais aussi
sur leur bonne compréhension de la
production (et vice-versa pour les
exploitants).
// Tirer parti des outils collaboratifs
(type Trello ou Jira agile) pour faci-
liter et renforcer le lien entre les Dev
et les Ops
« IT IS ALL ABOUT PEOPLE » #HUMANFIRST
Une transformation DevOps est avant tout
une question de personnes, d’humains, de
Les premiers freins à lever seront donc des
questions de collaboration, des personnes
à convaincre que l’on peut faire mieux
différemment, des process à casser, des
objectifs (y compris ceux de fournisseurs)
à revoir, des outils à changer, etc. Tout
cela ne peut se faire qu’en s’appuyant
sur des personnes fiables, motivées, très
compétentes (Google parle de « Highly
Skilled Engineers » dans sa méthodologie
« Site Reliability Engineering » - SRE), avec
de fortes capacités d’adaptation.
De plus comme dans tout projet de
conduite du changement, il sera nécessaire
de beaucoup communiquer, sur les
réussites et les échecs, sur les objectifs, sur
les impacts, l’organisation et les métiers.
L E S O R G A N I S AT I O N S S ’A G I L I S E N T E N émerger des principes et des méthodes
S’ I N S P I RA N T D E S P RAT I Q U E S D E S G É A N TS plus ou moins complexes pour développer
l’agilité à l’échelle de l’entreprise.
DU WEB
Les pratiques popularisées par Google
(SRE), Spotify, Amazon, Facebook et
consorts font aujourd’hui des émules.
Ces pratiques sont le prolongement du
chemin vers le « tout agile ». Elles ont fait

// Spotify est à l’initiative d’une méthodologie dont le pilier principal est

l’autonomie donnée aux équipes (feature teams). Afin de maintenir la
cohérence de son SI, Spotify a mis en place des communautés regroupant
les sachants d’une thématique (chapters, tribes, guilds) qui forment une
SPOTIFY
sorte de hiérarchie matricielle.
// Reconnue comme l’état de l’art des organisations Agiles, c’est aussi une
méthodologie assez peu documentée et demandant un haut niveau de
maturité tant en termes d’agilité qu’en termes de management des équipes.

// SAFe est un cadre de travail développé en 2011 par une équipe d’experts
Agile pluridisciplinaires. Il a été conçu pour les organisations traditionnelles
(par opposition aux pure-players web) pour adresser des programmes com- SAFe
plexes impliquant de nombreuses équipes. Scale Agile Framework

// Il s’adresse à des entreprises maîtrisant déjà la méthode Agile Scrum.

// Le Scrum of Scrums est une technique permettant de synchroniser très

simplement plusieurs équipes Scrums entre elles sans mettre en place un
framework très complexe.
SCRUM OF SCRUMS
// Si cette technique ne permet pas réellement de développer l’agilité à
l’échelle de l’entreprise, elle peut être une étape pour la développer à
l’échelle d’un projet d’envergure.

38
 ORGANISATION ORGANISATION
TRADITIONNELLE AGILE

SILOS organisationnels et EQUIPES ET UNITÉS

fonctionnels PLURIDISCIPLINAIRES

IMPLICATION À TEMPS PARTIEL dans IMPLICATION À TEMPS PLEIN DANS

les projets UNE ÉQUIPE ET SUR UNE TÂCHE

STRUCTURE HIÉRARCHIE COMPLEXE

multi-niveaux MOINS DE NIVEAUX HIERARCHIQUES

CENTRALISATION DES DÉCISIONS

CONFIANCE ET DÉLÉGATION
au niveau management

CHANGEMENT ET LIVRAISON
Process de gestion de projet CONTINUS
LOURDS

PROCESS CYCLE EN V et gestion des Développement de MINIMUM

VALUABLE PRODUCTS et RETOURS
changements en BIG BANG
CLIENTS RAPIDES

Nombreux KPIs INDIVIDUELS Plus de KPIs COLLECTIFS

AVERSION AU RISQUE et culture du PROCESS FLEXIBLES S’ADAPTANT AUX

contrôle BESOINS DU MÉTIER

PERSONNES

39
 MOBILISER QUELQUES CHAMPIONS
POUR AMORCER LA TRANSITION
VERS LE DEVOPS

IaC, CD, Culture… Par où commencer ? Comment initier une démarche DevOps ?

40
Le passage des méthodes classiques
au DevOps représente une véritable
rupture dans l’organisation du travail.
Son déploiement est une entreprise
progressive et délicate qui exige des
investissements humains et techniques à
ne pas sous-estimer.
Les premiers temps de cette
transformation sont clés pour embarquer
les acteurs, justifier des investissements
f u t u r s e t c ré e r u n e d y n a m i q u e d e
transformation durable. La trajectoire
adoptée peut et doit permettre de réaliser
des retours sur investissement dès les
premiers temps de la transformation.
Une trajectoire projet par projet permet
ainsi d’échelonner l’effort sur le long terme
et dégager rapidement des gains visibles
et mesurables.
« La trajectoire adoptée peut
et doit permettre de réaliser
des retours sur investisse-
ment dès les premiers temps
de la transformation »
1- Est entendu par déploiement du socle : le déploiement d’outils collaboratifs, le déploiement de plateformes de développe-
ment/déploiement (Continuous Delivery), et l’automatisation (Infrastructure as Code, automatisation des tests…).
41
La stratégie de déploiement du DevOps
peut se décliner selon les 3 axes suivants :
// Le choix du premier périmètre
// Le déploiement du socle1
// Le développement des compétences
CHOISIR UN PROJET VITRINE DE LA
T R A N S FO R M AT I O N , A M B I T I E UX E T «   S A F E
TO FAIL »
La priorisation du portefeuille projet
doit permettre d’embarquer les Métiers
dès le démarrage et de pérenniser
l a d y n a m i q u e p ro j e t a p rè s p ro j e t .
Pour cela, il est clé de choisir en priorité un
périmètre qui concentre de fortes attentes
des Métiers et pour lesquels les bénéfices
du DevOps seront réellement significatifs
et simples à mettre en œuvre.
Dans la démarche DevOps, l’approche
itérative associée à une forte proximité des
équipes, du Métier jusqu’à la production,
permet de s’adapter rapidement aux
évolutions en réduisant les freins liés
aux opérations. Le DevOps garantit
donc pleinement une réponse adaptée
au besoin même si celui-ci se précise
– voire change – au fur et à mesure du
projet. Ce sont par ailleurs les projets ou
produits dont le besoin évolue souvent qui
 permettront de démontrer que le DevOps
fait mieux, et plus vite, que les méthodes
classiques, y compris sur des périmètres
embarquant fortement les opérations.
Pour autant le périmètre choisi doit
être sécurisé («  Safe to Fail  »). Le
risque d’échec n’étant pas négligeable
il est important d’avoir un plan B, ce qui
facilitera d’autant plus l’acceptation du
risque.

TOUS LES PROJETS PEUVENT TROUVER DES BÉNÉFICES AUX MÉTHODES AGILES, LE GRAAL ÉTANT
POUR LES PROJETS DONT LE BESOIN ÉVOLUE RAPIDEMENT
Les projets dont le besoin est instable (le résultat final n’est pas prédictible), sont très
naturellement éligibles aux méthodologies Agiles et DevOps puisque bénéficiant directement
du caractère itératif de ces démarches.

Les projets simples et stables peuvent sans grand risque être traités par les méthodes
classiques. À terme, ils seraient aussi bien couverts par des méthodologies Agiles.

Enfin les projets complexes mais dont le besoin est stable sont éligibles à l’un ou l’autre si
l’on est sûr de la compréhension du besoin. Dans le cas contraire, mieux vaut privilégier des
méthodologies Agiles.
complexe

AGILE OU CYCLE EN V
AGILE
AGILISÉ
COMPLEXITÉ

CYCLE EN V AGILE

INSTABILITÉ DU BESOIN
Instable

42
CO M M E N C E R PA R L E S A P P L I C AT I O N S
FACILEMENT AUTOMATISABLES
Le choix des premiers projets doit
é g a l e m e n t p re n d re e n co m p te l e s
applications impliquées.
L’effort d’intégration d’une application
à la chaîne du continuous delivery est
rarement négligeable. Du côté des
Devs, il faut opérer la transformation
des processus d’intégration habituels
et parfois le changement d’une partie
de l’outillage. Du côté des Ops, tous les
scripts d’automatisation des processus
de livraison doivent être revus pour qu’ils
soient gérés par les même outils que
ceux utilisés par les Devs (versionning,
build, testing…). Eviter les ruptures dans
la chaîne de delivery est au cœur des
principes du DevOps.
Pour minimiser les investissements
au démarrage, il est donc important
de sélectionner les applications pour
lesquelles l’effort d’intégration à la chaîne
de continuous delivery est minimal.
Typiquement, des progiciels qui imposent
une intervention quasi manuelle pour
l’acquisition d’une clé de licence ou
re q u i è re n t l ’ u s a g e d ’ u n e i n te r fa ce
graphique pour leur installation sont à
mettre de côté dans les premiers temps
de la transformation.
De même, certaines applications se prêtent
par nature très mal à l’automatisation des
tests.
Parmi les applications éligibles identifiées,
il est intéressant de cibler en priorité
43
celles dont le processus de livraison
est déjà un frein identifié au regard des
enjeux de time-to-market et de qualité
de service, ainsi que celles qui ont des
cycles d’évolution relativement courts.
Les bénéfices de la refonte de telles
applications seront d’autant plus évidents
que le frein est important. Ils serviront à
justifier les investissements engagés pour
l’automatisation de la livraison applicative.
PRIORISER LA CONSTRUCTION DU SOCLE IAC
& CD SELON VOS POINTS DE DOULEUR
Le déploiement du socle va demander
des investissements importants sur le
long terme, alors que paradoxalement
il est peu visible du Métier. Pour autant,
c’est sur lui que repose la pérennisation
du succès de la démarche.
Pire encore, s’il est mal ou trop timidement
réalisé, on peut à la fois accentuer les
points de douleur des Ops et mettre en
danger la réussite des projets, jusqu’à
entraîner un rejet du DevOps et un retour
aux méthodes classiques.
Les premiers projets seront ceux qui
permettront de construire un premier
socle pour l’Infrastructure as Code et
le Continuous Delivery. Le périmètre de
ce socle sera élargi dans la durée, projet
après projet.
Chaque projet DevOps doit être vu
comme une occasion de dégager du
budget pour faire évoluer les briques du
socle – et chaque transformation du socle
comme un moyen de réduire l’effort pour
les projets suivants. Pour rester dans ce
cercle vertueux, la priorisation est clé.
Une bonne pratique est de se fixer,
pour chaque projet, un objectif
d’automatisation qui sera traité
a u s e i n d ’ u n s p r i n t a u m ê m e t i t re
q u ’ u n e fo n c t i o n n a l i té a p p l i c a t i ve.
Dans certains cas, si le projet en question
est suffisamment long et complexe, il
est même possible d’observer un retour
sur investissement avant même qu’il se
termine.
Enfin, certaines organisations, face à la
complexité de gestion d’un SI très ouvert
et hétérogène (multipliant par exemple
les socles IaC) auront besoin de pousser
l’automatisation jusqu’à la mise en place
d’une couche d’orchestration de leurs
différents IaC (internes et externes s’ils
s’appuient sur des socles infrastructures
externes) et d’une plateforme
d’orchestration des chaînes de delivery.

Comme pour l’automatisation Un Meta-Orchestrator (ou BPM) peut

d e s l i v ra i s o n s a p p l i c a t i ve s , i l e s t
particulièrement efficace de profiter des
projets pour transformer en priorité les
briques déjà identifiées comme des points
de douleur par les équipes.
Le déploiement d’outils collaboratifs,
que ce soit pour la gestion de projet
ou du code applicatif, doit être réalisé
en priorité. Ces outils sont clés pour
améliorer les interactions entre les équipes
et les aligner sur des objectifs communs.
également être nécessaire pour gérer
les processus de déploiement sur un
ensemble d’applications en garantissant
la cohérence Métier. Le déploiement
d’un Meta-Orchestrator est le plus haut
niveau d’automatisation des livraisons - il
permet d’automatiser la prise en compte
des dépendances de livraisons entre
les différentes applications d’un même
périmètre Métier.

LE CLOUD P UBLIC
U N ACCÉLÉRATEUR DE LA TRANS FO RMATIO N D EVO P S

La création d’u n so c le à p a r tir d ’u n ex ista nt p e u t être lo ng ue et co üte us e.

Le C loud P ublic peut d é s lo rs être u n a ccé lé rate u r fo r t à m o ind re co ût p o ur d é mar re r
une expérim e ntatio n DevO p s e n u tilisa nt u n e su ite d é j à i nté g ré e.
Tous les grands C lo u d Pu b lic s ( Mic ro so f t A z u re, A m a zo n We b Se r v i ce s , G o o g l e Ap p
Engine) propos ent leu r p ro p re su ite co m p o sé e d ’Ia C et d ’o u tils p e r mett a nt d e co nst i t ue r
une bas e de Continu o u s De live r y e n la co m p léta nt ave c q u e lque s o ut i l s l i b re s (p o ur l e
te stin g et la q u a lité d u co d e n ota m m e nt ).
Nous recommando n s fo r te m e nt d e d é m a r re r a in si p o u r b é n é fi c i e r p l us ra p i d e me nt
de rés ultats concrets et d ’u n e tra n sfo r m atio n p lu s a m b itie u s e q ui ne p ré j ug e p as d e
l’ex ista nt et d e s p ro ce ssu s in sta llé s.

44
 DÉMARRER AVEC 3 « FEATURE TEAMS » DE
C H A M P I O N S P O U R CO N ST R U I R E L E S O C L E
E T L A P R E M I È R E A P P L I C AT I O N E N M O D E
DEVOPS
Afin d’assurer le succès du premier projet
et la bonne diffusion des pratiques, trois
équipes doivent être réunies – et leurs
membres choisis parmi les champions de
leurs domaines. (cf schéma ci-dessous)
U NE FE ATU RE TE A M IAC , en c h a rg e d e co n str u ire
l e so cl e de l’Infrastructure as Co d e (o rc h e stratio n ,
API, tem plates de déploiement) .
INFRASTRUCTURE
AS CODE
U NE FE ATU RE TE A M C D, e n
ch arge de construire le pipelin e
de Co nti nuous D elivery (s erve u r
de Co nti nuous Integration, m ise
en pl ace des outils de SVN, d e
testing, etc . ) .
CONTINUOUS DELIVERY
45
La feature team IaC et la feature team
CD vont, en parallèle du premier projet,
mettre en place les premiers éléments de
socle nécessaires au lancement de ces
projets en mode DevOps. Elles seront
dimensionnées en fonction de la vitesse
à laquelle on souhaite faire aboutir ces
premiers éléments, et bien sûr, des moyens
engagés.
A u d é m a r ra g e , i l e s t co n s e i l l é d e
regrouper ces équipes dans un même
lieu, ou a minima de les lier par des outils
collaboratifs efficaces. Dans la même
logique, il est conseillé de leur dispenser
des formations communes afin de créer
des liens dès le démarrage.
APPLICATION
U NE F EAT U RE T EAM
AP P L I C AT I ON (o u é q ui p e P ro d ui t )
à l a q ue l l e o n a d j o i nd ra un O p s
p o ur s e ns i b i l i s e r l e s D evs a ux
p ro b l é mat i q ue s d e s O p s .
L’ O R G A N I S A T I O N S E R A C O N T R E V O U S :
PROUVEZ-LEUR QU’ILS ONT TORT ! LES ER R E UR S À É VI TE R
La transformation vers un modèle agile
va nécessairement se confronter à une Le s p re mi è re s t ransfo r mat i o ns
co n sé q u e nte s p e r mette nt d e re s s o r t i r
résistance au changement. Le premier
q u e lq ue s é cue i l s à év i te r :
projet doit absolument communiquer
largement sur ses réussites.
• L E SYST ÈME SE RA CONTRE VOUS : i l est
Il est aussi indispensable de mettre en d on c n éce s s ai re d’e n fai re res s orti r l e
place, dès le premier projet, les indicateurs ROI.
chiffrés permettant de factualiser la • PROUVEZ QUE VOUS AVE Z RAI SON : dans
réussite du DevOps. cette op ti que i l faut donc me s ure r l e s
b én éfices de l a transformati on.
Les outils mis en œuvre dans la démarche
• VOUS A L LE Z ÉCHOUE R : i l est i ndi s pe ns abl e
permettent d’analyser finement la qualité d ’a ccep ter l ’é che c et l ’e rreur dans une
du code, les temps de déploiement, le d ém a rc he i té rati ve «  test & l e arn » .
nombre de livraisons applicatives, le • «  ONE SIZE D OE S NOT FI T ALL  » : chaque
nombre de bugs, etc. Ces éléments sont d ém a rc he D evOps doi t être adapté e au
autant de points de mesure qui permettent contexte et aux enj e ux de l ’e ntre pri s e.
de prouver l’intérêt de la démarche et son • RESPECTE Z LE MONOLI THE : i l e st
retour sur investissement. in d isp ens abl e de s ’i nté grer avec
les systè me s hi stori que s / l egacy et
Il s’agira de bien mettre en valeur ces d e resp ecte r un ce rtai ns nombre de
p rocessus ex i stants . Ne pas che rcher à
gains, en faire la promotion pour justifier
tou t ca sse r.
les investissements réalisés et futurs.

FACTEURS CLÉS DE S UCCÈS

D e la mê m e fa ço n l’o n p e u t re sso r tir q u e lq u e s c lé s d u s uccè s :

• S I M P LI F I E Z : l e s p rocessu s, les infra str u ctu res, etc . Tou t d oit être standard.

• AU TO M AT I SE Z : vo s infra str u ctu res, vos p rocessu s et tou tes les a cti ons ré péti ti ves où à fai bl e
va l e u r a j o u té e.

• R ECRU T E Z D E S I N GÉ NIEURS ET DES DÉVELOPPEURS DE H AUT NIVEAU : pour e n fai re de s Ops

q u a l i f i é s e n c h a rge d e la con cep tion d es n ou vea u x ser vices et b r ique s du SI .

46
 VERS UN MODÈLE OPÉRATIONNEL
POUR LA DSI

Une fois que les premiers projets auront démontré l’intérêt de la démarche, il
s’agira alors d’étendre ces bonnes pratiques à l’échelle de l’entreprise.

Les membres des premières équipes doivent servir de coachs, d’ambassadeurs,

pour diffuser les pratiques au sein des équipes produits qui se formeront au
fur et à mesure au sein des DSI.

L e s é q u i p e s aya n t c o n t r i b u é à l a c o n s t r u c t i o n d u s o c l e I a C e t C D d o i ve n t
constituer les premières briques des centres de compétences qui feront évoluer
ce socle en fonction des besoins des équipes produits et qui appuieront les Ops.

47
Afin d’assurer une certaine « pollinisation » (diffusion du savoir entre les équipes), il est
important d’aider à la construction de communautés pour partager les bonnes pratiques
entre Ops, Dev, mais aussi Architectes, etc.

Ces communautés doivent également permettre d’enrichir un cadre de référence commun

sur les méthodologies agiles (projet, management, animations de communautés, etc.).

Enfin cette transformation devra respecter le legacy et les personnes qui continueront
de le maintenir. Il ne faut donc pas seulement prévoir de gérer les aspects techniques
(interopérabilité, évolutivité, maintenance, etc.) mais également les aspects humains
(attractivité des postes, gestion des compétences, etc.) pour éviter de mettre en risque

LE S ÉQ U IP E S P RO D U ITS VO N T SE DÉ V E LO PPE R PO UR CR É E R DE M U LT I P L ES ÉQU I P ES

PA R FO NC TIO N N A L ITÉ AU SE I N DE S DSI :
Au plus proche des Métie rs p o u r s’a d a p te r à le u rs b e so in s
I nté grant des D evs et de s O p s et u tilisa nt l’Ia C et le C D p o u r livre r p l us rap i d e me nt et p l us
fréq uemment de nouvelle s fo n ctio n n a lité s

LA C RÉ ATIO N D ’ U NE CO UCH E D’ I N T ÉG RAT I O N E T DE G E ST I O N DES S ERVI C ES

S’ap puyant s ur des centre s d e co m p éte n ce s Ia C et C D co n stitu é s d e s é q ui p e s ayant
co ntribué s ur les premie rs p ro jets Dev O p s
En charge également de la co h é re n ce d ’e n se m b le ( a rc h ite ctu re, sé cur i té, o ut i l l a g e… )

DE S L IGN E S D E S E RVIC ES D’ I N F RAST RUCT UR E S SI M PLE S , m o d u l ai re s , «   se c ure d by

d esign » , et des opération s a u to m atisé e s

Le développement de C A PACI T É S D’ I N N OVAT I O N E T DE R& D p o u r g ard e r une l o ng ue ur

d’avance et un lien étroit ave c le s Métie rs

Mai s aus s i une CO H A BITAT I O N DURAB LE ave c le s m o d è le s o p é rati o nne l s t rad i t i o nne l s

48
 cette partie. Dans un second temps, il sera nécessaire de le faire évoluer également,
soit en le « rafraichîssant » (avec de nouvelles technologies), soit en le transformant
complètement (réécriture morceau par morceau dans une philosophie agile).

MÉTIER

SKILLS NETWORK FEATURE TEAM FEATURE

FETAURE TEAM ÉTUDE «LEGACY» TRANSVERSE

MOA MOE

UX Build/ Build/ Études (SI&Process) RH

Dev Dev (GPEC)
Product Product
owner owner
FRONT-END Pilotage projet & conception de solutions
Ops Ops
Scrum Scrum
Master Master
OPS Archi Archi
Développement et maintenance
VMO
Appli/ Appli/
TMA TMA
ARCHITECTURE Architecture

Intégration et gestion des services Recette

Idéation, croquis ,prototytage

PILOTAGE
S upport ÉCONOMIQUE
Infrastructure Continuous Centre de
Architecture
as Code Delivery commande

LAB MÉTHODE
DE QUALITÉ
INFRASTRUCTURE
Lignes de services

IaaS PaaS Workplace Sécurité Legacy Outils PORTEFEUILLE

LAB

opérations PROJET
ARCHITECTURE

DÉVELOPPEMENT
CATALOGUE DE
OPERATIONS SERVICES

COUCHES HARDWARE Feature Feature Feature Feature Feature

Teams Teams Teams Teams Teams

HÉBERGEMENT ET TÉLÉCOMS CONFORMITÉ

49
ACCOMPAGNER VOS DEVS & OPS DANS LEUR
CHANGEMENT DE MÉTIER
La nouvelle organisation de travail a
nécessairement un impact sur les métiers
des exploitants et des développeurs. Il ne
s’agit pas de transformer les Ops en Devs,
ou l’inverse, mais bien de faire évoluer les
deux métiers vers de nouvelles pratiques.
Ainsi l’Ops va évoluer vers la préparation
d’éléments d’infrastructure réutilisables
et automatisés. Tout en continuant, le
temps de la montée en compétence
des Devs d’assurer le développement
des scripts de déploiement de chaque
application et ce en utilisant les mêmes
outils que les Devs.
Les compétences de développement et la
connaissance des outils de configuration
management deviennent ainsi
particulièrement importantes. Les Ops
ont déjà une culture de scripting. L’enjeu
pour eux sera de passer des pratiques « à
l’ancienne » - scripts peu réutilisables, peu
commentés et difficilement maintenables
- à des pratiques et outils uniformes sur
toute la chaîne de valeur IT.
la variabilisation de la matière applicative
pour la rendre déployable quel que soit
l’environnement visé, sans surcoût de
gestion. Ils vont désormais s’intégrer
dans une chaîne complète de continuous
d e l i ve r y , i n té g re r ( à l a d i f fé re n ce
des habitudes prises jusqu’ici) les
processus de build, la mesure de la dette
technique (qualité du code), ainsi que
les tests unitaires et de user acceptance
automatisés.
Cela induit pour eux de :
// mieux comprendre la production
et les modèles de déploiement
applicatifs afin de « variabiliser
l’application » pour permettre son
déploiement différencié en fonction
de l’environnement visé ;
// s’inscrire dans une démarche dite
de « test driven development » pour
assurer un haut niveau de qualité et
de contrôle de non-régression.

En contrepartie, le renforcement de
l’automatisation et de la qualité des
déploiements va entraîner une diminution
du nombre d’incidents et de demandes de
changement gérés par les Ops jusqu’ici.

De leur côté, les Devs ne peuvent

plus se contenter de produire le code
d e l ’a p p l i c a t i o n . I l s vo n t i n té g re r
les contraintes de déploiement des
environnements, concevoir les modèles
de déploiement applicatif et permettre

50
 CONCLUSION

S’il est aujourd’hui impératif pour les Il faut donc démarrer dès maintenant,
entreprises d’être plus Agile, de déployer adopter ces pratiques progressivement,
plus vite, les pratiques DevOps à mettre en test & learn, en s’inspirant des pratiques
en œuvre n’en ont pas moins des impacts des pure-players du web. Cela requiert un
profonds sur les DSI : changement d’état d’esprit : il faut être
orienté résultat, penser produit et non plus
// Transformation de la façon de
projet, faire des pas plus petits mais en
concevoir une application en la ren-
plus grand nombre. C’est un changement
dant plus modulaire et en intégrant
profond qui ne se fera pas en quelques
les infrastructures et les opérations
mois, mais qui donnera des résultats très
dans son code ;
rapidement.
// Automatisation et «  softwarisa- Et il faut le faire d’autant plus vite que
tion » des infrastructures, ainsi que la cible est loin : le NoOps. Ce concept
la mise à disposition des services selon lequel ce sont les développeurs
d’infrastructures via des interfaces eux-mêmes qui assurent l’exploitation
programmables directement dans le de l’application quand les opérations se
code ; concentrent sur l’automatisation (et la
supervision de bout-en-bout). Cela peut
// Évolution des métiers d’Ops vers
paraître une utopie mais c’est déjà une
le développement et vice-versa (et
réalité pour des géants comme Amazon
donc nécessité de recruter différem-
qui en tire de vrais bénéfices en recentrant
ment, de former, d’accompagner au
les personnes sur la valeur ajoutée qu’elles
changement).
peuvent apporter.
// Modification des façons de travail-
ler avec les métiers, via des « feature
teams » intégrant toutes les parties
prenantes et modifiant également
l’organisation et le modèle opéra-
tionnel de la DSI.

51
www.wavestone.com