DevOps

Et si c’était vrai ?
Nos convictions pour réussir

Juin 2019
Avant-propos

Où en sommes-nous dans l'adoption de DevOps dans l'entreprise et sur le marché ?

Le sujet semble maintenant se bonifier mais quand on demande quel est le degré de maturité
de cette pratique aux responsables de l’Informatique, du Digital et plus largement aux
collaborateurs, peu considèrent qu'elle est vraiment ancrée dans les usages ni déployée
largement. En effet, nous constatons que les certifications « DevOps Foundation® » et
« DevOps Leader® » restent moins plébiscitées que celles de SAFe® (Scaled Agile
Framework®) ou Large Scale Scrum (LeSS).
Même si l'un des principaux objectifs des entreprises est la réduction du « Time-to-market, »
tous les développeurs n’utilisent pas encore des solutions complètes d'intégration et
livraisons continues (CI / CD). Quant aux chaînes d’outillage DevOps elles peuvent
apparaître comme un écheveau de dizaines d'outils qu'il faut s’approprier.
D'autant, l'enjeu dépasse largement les technologies ou l'outillage et son succès dépend bien
plus des capacités de l'organisation à instaurer une gouvernance propice à créer une culture
DevOps adéquate. On parle de BizDevOps, soit Business Development Operations, pour
signifier que toute l'entreprise doit être partie prenante dans la libre circulation de l'information
et la collaboration de bout en bout.
Les discussions du Club DevOps IBM, regroupant des clients, parties prenantes et experts
DevOps, mettent en valeur les difficultés concrètes rencontrées, parmi lesquelles les modes
de fonctionnement en silo, ou l’éternel jalon clé du "qui" est responsable au moment des
mises en production.
Nous avons donc décidé de traiter de ce sujet, largement prégnant chez IBM, qui dépasse
les frontières de l'organisation, couvre la technologie, les rôles et activités, les processus, la
culture, avec pour objectif premier le Business et les clients.
« DevOps, et si c’était vrai ? » Les Consultants d'IBM Services partagent avec vous leurs
convictions sur le sujet d'après leur vision et les retours d'expérience issus des missions
menées chez les clients, étayées des témoignages de membres du Club DevOps IBM.

Frank Allard
IBM Services
Consulting Leader France

2
 Les auteurs
Vincent Patrice
Bertet Corbard

DevOps Practice Leaders

Guillaume Eric
Raud Dron
Associate Partner Senior Managing IT
Consultant
Expert DevOps

Justin Derbyshire
Innovation, Digital et Adoption
Responsable Editorial

Les contributeurs
Florent Barth
Responsable d’équipe nationale de développement et d’intégration
d’applications au Ministère de l’Education Nationale

Sylvain Doriath
Directeur de projet e-commerce & Agile manager, Editions Lefebvre Sarrut

Dany Garnier
Ingénieur production chez Editions Lefebvre Sarrut

Henri Giordano
Responsable Centre d'expertises et DevOps chez Groupama

Olivier Thiebaut
Chef de projet national DevOps au Ministère de l’Education Nationale
01 Vous avez dit DevOps ?
02 Les clés d’une démarche réussie
03 Les chaînes d'outillage DevOps
04 Créer une culture DevOps
05 Comment bien déployer DevOps ?

4
Introduction

En 2008, des pionniers réfléchissent à une collaboration plus étroite entre les
équipes de développement et les opérations IT, pour proposer un niveau de
service aligné sur les attentes des utilisateurs et des cycles de déploiement
accélérés. Puis des enseignes iconiques, avant-gardistes dans les pratiques,
ont déployé une nouvelle démarche collaborative DevOps : Facebook, Spotify,
Netflix, …
Les résultats obtenus font rêver, que ce soit en fréquence de mises à jour, en
performance et scalabilité, ou encore en sécurité. Ces avant-gardistes sont
avant tous des licornes issues de l’industrie Tech, et ont grandi avec cette
culture, par nécessité. Nous pensons qu’aujourd’hui ces pratiques concernent
toutes les organisations IT, et qu’elles peuvent adapter la démarche pour en
tirer les bénéfices.
Parce qu’après tout, si cette histoire était vraie ? Et si nous avions
l’opportunité d’apporter une meilleure qualité de service à nos utilisateurs, et
une meilleure efficacité opérationnelle à nos organisations ?
De nombreuses avancées ont été réalisées depuis 10 ans. Nous vous
proposons aujourd’hui un retour d’expérience des initiatives menées avec nos
clients, que nous remercions vivement pour leurs témoignages.
Avec ce livre blanc, nous souhaitons partager nos convictions et celles de nos
clients. Ils témoignent de leurs expériences en pointant les principaux
obstacles et les facteurs clés de succès de leur transformation DevOps.

5
01.

Vous avez dit DevOps ?

Définition de DevOps par Gene Kim

Qu’est ce que DevOps ?
DevOps est apparu en 2008 lors d’une présentation
« Working towards a « Œuvrer dans un but « Agile Infrastructure & Operations » de Patrick Debois
common goal that commun permettant [1]. Le terme DevOps lui-même, issu de la
enables the fast flow of d’accélérer la vélocité concaténation du début des mots anglais «
planned work into des mises en production Development » et « Operations », est né l’année
production while tout en assurant une suivante avec les conférences DevOpsdays [2].
achieving world-class stabilité, résilience,
stability, reliability, disponibilité et sécurité Gene Kim, l’un des leaders du mouvement, propose
availability, and de premier ordre » une définition reconnue de DevOps.
security »

CALMS, les 5 piliers

DevOps repose sur les 5 piliers CALMS : DevOps
• Culture : collaborer et s'entraider à l'atteinte
Measurement
Automation

d'objectifs communs
Sharing
Culture

• Automation : automatiser les tâches pour

Lean

aller vers une livraison continue

• Lean : optimiser le flux et la livraison de
valeur aux utilisateurs
• Measurement : mesurer les performances
pour favoriser l’amélioration continue
• Sharing : décloisonner et partager
l’information, les retours d’expérience et les
objectifs Les 5 piliers DevOps

Quel est le lien entre Agilité et DevOps ?

À cette question fréquente de nombreuses réponses différent et amènent de la confusion :
• « DevOps est une évolution de l’Agilité »
• « DevOps est le complément faisant le lien entre les Développements Agiles et la Production
Informatique »
• « DevOps est un sous-ensemble de l’Agile », ou « Agile est un sous-ensemble de DevOps »
• « Il n’y a aucun lien entre Agile et DevOps »

[1] - Patrick Debois, « Agile 2008 Toronto: Agile Infrastructure and Operations Presentation », 2008
[2] - Evénements DevOpsDays : https://www.DevOpsdays.org/ , depuis 2009
6
Le « Manifeste pour le développement Agile de logiciels » [3] énonce 4 valeurs et 12 principes pour
améliorer les pratiques de développement de logiciels. Livrer rapidement et régulièrement un logiciel
opérationnel fait partie intégrante de ces principes et des priorités centrées sur la satisfaction des clients.

Des principes fondateurs communs

• La livraison en continu de valeur métier aux utilisateurs
• La prise en compte des retours au plus tôt
• L’amélioration et l’apprentissage en continu

Agile [4] DevOps [5]

4 valeurs
3 voies
12 principes
Métier Client

Sprint

Dev Ops

Source
Source
Agile Manifesto (2001) The three ways :
the principles underpinning DevOps
(2012, Gene Kim)

La collaboration étroite entre les clients, les utilisateurs et les développeurs prônée dans le Manifeste Agile,
se complète avec DevOps pour couvrir de bout en bout la chaîne de développement, de déploiement et
d'exploitation en intégrant les équipes de Production, de Sécurité, et les Architectes.

Cette complémentarité entre Agile et DevOps est bien présente chez nos clients. La majeure partie des
équipes de développement ont adopté ou ont engagé des expérimentations de méthodes Agiles. La
nécessité de porter rapidement les résultats des sprints jusqu’à la production ou de disposer
d’environnements de tests les ont conduit à étudier la mise en œuvre des pratiques DevOps.

[3] [4] - Manifeste pour le développement Agile de logiciels et principes sous-jacents, 2001 : https://Agilemanifesto.org/iso/fr/manifesto.html
[5] - The Three Ways: The Principles Underpinning DevOps, 2012 by Gene Kim : https://itrevolution.com/the-three-ways-principles-underpinning-DevOps/ 7
Les pratiques DevOps ont un intérêt même sans
développement Agile
Si les pratiques Agiles se généralisent, un nombre significatif de projets sont toujours réalisés suivant
des phases séquentielles (cycle en V). L’Agilité génère des changements importants de paradigmes et
de culture qui nécessitent du temps pour être intégrés.

Considérons maintenant le cas d’un projet de développement d’une nouvelle application selon un cycle
traditionnel planifié sur plusieurs mois intégrant une seule mise en production :
• Les pratiques, technologies ou principes DevOps peuvent être appliqués pendant cette période
projet améliorant ainsi l’efficacité des équipes.
• Une fois l’application mise en production, le projet devient un produit qu’il faut maintenir et faire
évoluer plus ou moins rapidement pendant des années. Une approche DevOps qui intègre la
livraison continue peut être une réponse à ces enjeux de mises à jour fréquentes de l’application
(même si le projet initial a été réalisé de façon traditionnelle).
• La période projet sert à la mise en place des capacités DevOps permettant de maîtriser et
d’accélérer les évolutions suite à la première mise en production.

Les pratiques DevOps peuvent exister sans Agilité

Mois Années
Projet Mise en
Mises à jour de l’application
traditionnel production

Capacités DevOps livraison continue

Une forte fréquence de déploiements de l’applicatif ou de ses évolutions n’est pas le seul critère
pour décider de l’intérêt d’une approche DevOps.

Une faible fréquence peut également justifier ce choix pour capturer la connaissance et faciliter la
reproductibilité d’un déploiement sans dépendre de telle ou telle personne le faisant manuellement
de manière très occasionnelle et avec des risques d’erreur.

8
Agilité et DevOps : une même initiative !
Pour certains de nos clients, les deux initiatives Agile et DevOps sont menées en parallèle par des
leaders et départements différents. Les raisons en sont historiques ou politiques. Cette situation peut
entrainer une concurrence entre les deux initiatives et des problèmes de cohérence et d’adoption par
l’organisation.

L’Agilité et DevOps sont deux approches complémentaires, nous l’avons vu. Elles impliquent les
mêmes acteurs de la chaîne logicielle, il est donc nécessaire de les adresser conjointement lors d’une
transformation des pratiques. Celles-ci convergent progressivement pour une plus grande cohérence
et efficacité, comme les frameworks SAFe DevOps [6] ou Scrum Ops.

Des études d’analystes comme celle de Forrester « The State Of Agile 2017: Agile At Scale » [7]
montrent clairement l’intérêt de combiner Agile et DevOps au sein d’une même initiative de
transformation.

Florent Barth
Le mot de Responsable d’équipe nationale de développement et d’intégration
d’applications au Ministère de l’Education Nationale

Sans Agilité, pas de DevOps possible ?

Moi, j'en suis convaincu, l’Agilité est une première étape

Agilité et DevOps sont complémentaires,

Ce qu’il faut et offrent davantage de bénéfices en les
retenir adoptant au sein d'une seule et même
initiative de transformation.

[6] -SAFe 4.6 DevOps and Release on Demand : https://www.scaledAgileframework.com/DevOps-and-release-on-demand/ 9

[7] Forrester « The State Of Agile 2017: Agile At Scale », 2017
Les tendances du marché, en France
Selon la dernière étude d’IDC 2018 [8], le développement de DevOps est lié directement à la
transformation numérique des entreprises. De façon très opérationnelle, la démarche DevOps accélère et
facilite l’innovation. Elle contribue à l’adaptabilité des applications et positionne l’expérience client au centre
des préoccupations de l’informatique.

IDC indique les tendances suivantes quant aux conditions de progression de DevOps dans les entreprises
et institutions françaises :

Niveau dematurité
Niveau de maturité en France
DevOps dans les 2 obstacles principaux
organisations françaises
Moyens Stratégie des
Absence ou rigidité des
financiers métiers et / ou
processus métiers
Aucun ou démarrage d'initiatives 20% 5% de l'IT
5%
28%
Outils appropriés
Expérimentations au sein de l'IT 45% 10%

Extension aux métiers 28%

Généralisation 7%
Manque de suivi /
de leadership
15% Manque de
Niveau de maturité DevOps dans les organisations françaises Culture IT compétences
16% 21%

Source
Etude IDC DevOps 2018

Notre point de vue

Adoption Evolutions

• La majeure partie des entreprises sont en
phase d’expérimentation et très peu ont
engagé une mise à l’échelle.
• L’évolution des approches traditionnelles de
cycle en V vers DevOps est freinée en partie
par le fonctionnement des organisations en
silo, notamment entre la maîtrise d’ouvrage et
la maîtrise d’œuvre.
• Une évolution rapide et dynamique des pratiques
et des technologies facilite le partage des retours
d’expériences dans le cadre de nombreuses
conférences et forums de discussions.
• Le marché mondial est en pleine croissance
avec un manque crucial de compétences dès
2019.

• L’adoption DevOps se développe dans toutes

les entreprises indépendamment de leur taille
ou de leur secteur d’activité. La vitesse de sa
pénétration dépend principalement des
contraintes organisationnelles et culturelles.

[8] - Etude IDC 2018. https://ibm.biz/Bd25F2

10
02.

Les clés d’une

démarche réussie
Nos convictions pour réussir une initiative DevOps
La mise en œuvre de DevOps au sein des organisations rencontre souvent des difficultés de déploiement.
Les exemples sont nombreux tels que la seule mise en œuvre d’outils, le périmètre limité aux équipes de
développement déjà en mode Agile, etc...

La réussite de l’approche doit être dirigée et prendre en considération les dimensions culturelles,
organisationnelles, techniques et de conduite du changement.

Le Leadership : la condition première pour lancer et

conduire une transformation DevOps
L’échelle d’une transformation Agile / DevOps est impactante pour un périmètre élargi de l’organisation, et
à ce titre il est essentiel de positionner cette transformation à un haut niveau de sponsoring. La DSI, voire
la Direction Générale, doit lui apporter la légitimité et le support indispensables à sa réussite.

Les motivations pour démarrer une démarche DevOps dans une entreprise se concentrent autour :

• Des enjeux métiers qui imposent une réduction du temps de mise à disposition de nouvelles
versions pour répondre à la concurrence toujours plus vive notamment dans le secteur privé.
• De la nécessité de réaliser des gains de productivité sur la chaîne de bout en bout.
• De la motivation des équipes à adopter des nouvelles méthodes et technologies pour les équipes
de développement et de production.

Le mot de Olivier Thiebaut

Chef de projet national DevOps au Ministère de l’Education Nationale

Ce qui est clé pour démarrer un projet DevOps, c’est un « sponsoring »

fort de la direction SI qui alloue des moyens et peut discuter des
priorités avec les métiers. En complément, les initiatives et la motivation
des ingénieurs du développement et des opérations à collaborer dans
un cadre innovant avec de nouveaux outils sont un réel facteur de
succès.

11
Les démarches DevOps sont en général des initiatives décidées par les directions d’entreprise dans le
cadre de projets de transformation numérique. Cependant, des initiatives locales sont mises en œuvre
directement par les équipes de développement avec l’utilisation de méthodes et pratiques Agiles
supportées par de nouveaux outils collaboratifs.

Le rapport « State of DevOps report 2018 » [9] indique clairement que les entreprises adoptent une
démarche « terrain » en améliorant des pratiques quotidiennes au sein des équipes de développement
et des opérations. Par exemple, améliorer la qualité et réduire les délais de fabrication, de déploiement
de nouvelles fonctionnalités en s’appuyant sur des méthodes déjà éprouvées provenant de l’industrie
(Lean, 6 Sigma...).

Les 8 facteurs clés de succès

Partager une
vision cible
Accompagner la Modéliser
mise à l’échelle la chaîne DevOps

1
8 2
Implémenter de
Mesurer et améliorer façon
en continu incrémentale
7 LEADERSHIP 3

Intégrer toutes les 6 4

parties prenantes Faciliter l’évolution
(dont la sécurité)
5 culturelle

Travailler en
équipe produit

[9] - Etude “State of DevOps 2018” : https://DevOps-research.com/2018/08/announcing-accelerate-state-of-DevOps-2018/

12
 Les 8 facteurs clés de succès
L’ensemble des acteurs doit partager la même
vision de DevOps

Cette vision intègre les attentes et les besoins de chacun :

Partager Objectifs, enjeux, stratégie et déploiement… Une première étape
une vision consiste à partager les informations sur les différentes
1 composantes de l’initiative DevOps avec TOUS les acteurs dans
cible le cadre d’une action de sensibilisation – formation. Ces acteurs
incluent Métiers, Dev, Ops et Sécurité. Ils doivent partager
notamment les mêmes éléments de langage, la connaissance
des pratiques, des référentiels exploités et une chaîne d’outillage
commune.

Disposer d’une vision claire de la chaîne de

fabrication et de déploiement.

La mise en œuvre de DevOps ne doit pas échapper à la

formalisation du « processus » de bout en bout. Cette
description est nécessaire pour partager les activités, les
livrables et surtout les rôles et responsabilités de chacun. La
description de la chaîne facilite l’identification d’actions Modéliser la
d’amélioration comme l’identification des points de rupture, et
de performance pour accélérer potentiellement le « Time To 2 chaîne
Market ». DevOps

Naturellement, il est aussi indispensable de disposer d’une

cartographie des outils en place et les futures fonctionnalités
à mettre en œuvre en fonction des contraintes techniques et
du planning des équipes.

THINK

LEARN CODE

CULTURE

MANAGE DELIVER

RUN

13
 Engager par incréments le déploiement des
pratiques et des outils, avec une vision
de bout en bout

Implémenter Une erreur fréquente est de limiter une transformation DevOps

de façon 3 à la seule mise en place de déploiements applicatifs automatisés.
Cela peut contribuer à accélérer une partie de la chaîne de
incrémentale
fabrication. Il est cependant préférable d’identifier un ensemble
d’actions sur la chaîne de bout en bout en impliquant l’ensemble
des acteurs concernés.
Une stratégie peut consister à définir par exemple un MVP
(Produit Minimum Viable) correspondant à la colonne vertébrale
des pipelines de livraisons automatisés (CI/CD/CT), détaillés
dans la chaîne d’outillage (voir section 3 « les chaînes d’outillage
DevOps »).

Les « 3 C »,
au coeur de la transformation DevOps
La mobilisation des C’est un cercle
équipes DevOps vertueux qui doit
doit s’articuler se mettre en place
autour des « 3 C », Vision progressivement,
piliers de la où l’organisation Faciliter
transformation. fournit un meilleur 4 l’évolution
service aux culturelle
L’ancrage des clients, tout en
pratiques DevOps Mobilisation transformant sa
repose sur un propre culture.
accompagnement
au changement
résolument orienté
sur la collaboration
Culture
et l’évolution des
compétences et de
la culture des
équipes.
3C
Collaboration Compétences
14
 Favoriser la mise en place d’un mode collaboratif
efficace

Adapter les modes de collaboration est important pour améliorer

Travailler en l’efficacité opérationnelle quotidienne des équipes. Une taille
équipe produit 5 trop importante des équipes DevOps sur une chaîne applicative
peut amener des dysfonctionnements et une surcharge de
coordination venant à l’encontre des principes d’Agilité. Il est
possible par exemple d'aligner l'organisation des équipes sur
une architecture applicative micro-services.
On considère généralement que le nombre idéal de personnes
dans une équipe est de 6 ou 7 pour garantir un fonctionnement
optimum Agile. Ceci correspond précisément aux théories de la
dynamique de groupe : au-delà de 8 personnes, un groupe se
scinde en sous groupes et perd en efficacité.

Intégrer au plus tôt les exigences de tous les

acteurs (Biz, Dev, Ops, Sécurité...)

Ce point est fondamental pour consolider les bases d’une

transformation DevOps. Tous les acteurs doivent être
engagés au plus tôt pour définir les besoins fonctionnels et
non fonctionnels des applications. Une première approche Intégrer toutes
consiste à intégrer ces exigences dans le backlog géré par le les parties
Product Owner. 6 prenantes
Dans un cadre Agile, la participation des acteurs aux
(et la sécurité)
différentes cérémonies doit être revue avec le Scrum Master
afin de trouver l'équilibre entre les moments de collaboration
et la disponibilité des ressources. Il est important de définir le
mode opératoire le plus adapté à chaque contexte
d'entreprise et d'application.

15
Vous avez dit Dev«Sec»Ops ?
La sécurité d’un projet DevOps a pour objectif de garantir la protection des produits développés et
testés, contre des failles et des menaces connues. Elle devient un enjeu déterminant dans la
performance opérationnelle des SI et dans la mise en œuvre de pratiques Agiles et « DevSecOps ».
Les indicateurs clés d’un SI montrent la forte sensibilité des directions informatiques dans ce domaine
notamment sur la sécurité de la chaîne d’outillage qui peut s’avérer fragile et vulnérable aux attaques
de hackers. Il devient donc nécessaire de définir une gouvernance de la sécurité.

Nos convictions pour intégrer la sécurité dans une approche DevOps sont les suivantes :
• Identifier les besoins et exigences de sécurité en amont du développement des produits, en
engageant les experts sécurité au plus tôt.
• Gérer et maintenir le niveau de sécurité opérationnel du service : nouvelles menaces, changement
de contexte d’utilisation, etc…
• Former les équipes aux règles de l’art sécurité, dont les métiers.
• Repérer les User Stories qui ont un impact fort sur la sécurité.
• Intégrer les outils de sécurité au sein des « pipelines » de livraison DevOps (chaînes d’outillage)
pour effectuer les vérifications au plus tôt, et systématiquement.

L’intégration des vérifications de sécurité doit avoir lieu tout au long du cycle

U.S. spécifique
sécurité /
Backlog conformité Vérifications
Tâches
Produits de sécurité
(User Stories)

Analyse des
risques sur les Test
User Stories Local Tests Déploiement
UAT Prod
Outils de revue de code

Processus
Evaluation des risques, sélection des tâches, formation, validation
automatisé
Gestion des risques, évaluation, validation, rapport et
vérification de la conformité

Validation du service, vérification des rapports et de la conformité,

prise de décision

16
 Mesurer et améliorer en continu la chaîne DevOps

Toute idée, suggestion d’évolution des pratiques DevOps en terme

d‘organisation, de mode de fonctionnement, d’outillage doit contribuer
à l’amélioration globale de qualité et de performance. Cette boucle
d’amélioration peut être réalisée dans le cadre des cérémonies
Mesurer et rétrospectives (cf SCRUM) où toutes les parties prenantes sont
engagées. Il est important que chacun puisse s’exprimer et contribuer
améliorer 7 à ce plan d’amélioration en s’assurant que les actions identifiées
en continu fassent partie d’un backlog suivi et mis à jour.

Selon cette approche, la mise en place d’indicateurs de performance

trouve toute sa justification. En effet, elle constitue les bases
nécessaires à l’identification de solutions (automatisation, correction,
etc…) pour l’amélioration de la performance et de la qualité
d’exécution de la chaîne. Pour une plus grande efficacité, une priorité
toute particulière sera appliquée aux problèmes détectés et résolus en
amont.

Le mot de Sylvain Doriath

Directeur de projet e-commerce & Agile manager, Editions Lefebvre Sarrut

Nous souhaitions expérimenter l’approche DevOps au travers d’une

démarche MVP centrée sur la valeur. Ce MVP portait sur la réalisation d’une
application digitale. Les objectifs étaient de démontrer les résultats apportés
au travers de KPIs (Qualité et Time To Market), de faciliter le déploiement
des méthodes et la démarche pour d’autres applications au sein de ELS.

Le mot de Henri Giordano

Responsable Centre d'expertises et DevOps chez Groupama

Nous avons comparé les temps de déploiement entre le mode traditionnel

et la filière DevOps / conteneur, clairement en faveur de la filière DevOps (1
mn de déploiement en Docker contre 1 journée en classique).
Nous n’avons pas encore mesuré les bénéfices au niveau humain (par
exemple la satisfaction des équipes), ni les gains financiers (baisse des
coûts liés à la diminution des gestes opérationnels nécessaires).
Mais on sait déjà que les bénéfices sont réels, et avec la forte croissance du
mode DevOps, nous pourrons sans doute valoriser ces gains
prochainement.

17
 Garantir la mise à l’échelle cohérente des
pratiques et de l’outillage DevOps avec une offre
« DevOps As A Service »

Cette offre de service « DevOps As A Service » partagée

BizDevOps au sein des organisations IT constitue un cadre de
référence sur lequel s’appuyer pour progresser dans les
pratiques et intégrer progressivement les applications éligibles à
ce mode de fonctionnement. Cette mise en œuvre doit combiner
l’outillage de la chaîne et les pratiques associées.

Cette offre implique également un support organisationnel que

l’on peut appeler centre d’expertise DevOps pour assister et
généraliser la démarche DevOps au sein de l’entreprise comme Accompagner
suit : 8 la mise à
• Accompagner les équipes dans la mise en oeuvre des l’échelle
pratiques et outils DevOps.
• Effectuer un transfert progressifs des connaissances et
competences vers les équipes DevOps.
• Maintenir un cadre de référence DevOps au sein de
l'entreprise en lien avec les référentiels externes (SAFe ®,
Scrum…)

Cycle de fonctionnement « DevOps As A Service »

Composition d’une
Amélioration continue de la chaîne DevOps
équipe DevOps-aaS
Recueillir les demandes
DevOps Déployer et permettre aux
de support DevOps et les
Leader équipes d’être autonomes
« pain points »
DevOps
Coach
A fairedes solutions
Proposer
Technical (principes et outils)
Leader

Référent Concevoir la chaîne

Engager les actions
Outils Créer et mettre à jour le
Les suivre
backlog

18
03.

Les chaînes
d'outillage DevOps

Un marché de l’outillage en pleine effervescence

L’automatisation est un pilier fondamental d’une approche DevOps. En effet, le remplacement des travaux
manuels par des processus outillés est un des premiers moyens envisagés pour répondre aux impératifs de
vitesse.
L’attrait pour les approches DevOps entraîne une profusion d’offres d’outils étiquetés DevOps.

Certains méritent cette appellation, car ils

supportent nativement la mise en œuvre de ces
principes et nouvelles pratiques. D’autres outils
plus historiques se repositionnent sous ce terme DevOps
chapeau pour essayer de moderniser leur image

Measurement
de marque. Automation

Sharing
Culture

Lean
Ces dizaines d’outils et même de types d’outils,
chacun pouvant s’autoproclamer « l’outil leader
du marché DevOps », entraînent des confusions.
Leurs créateurs peuvent aussi chercher à
convaincre que la seule mise en œuvre d’outils
serait suffisante pour transformer les modes de
fonctionnement. CALMS
Enfin, à l’image du domaine DevOps, l’outillage évolue constamment. De nouveaux outils ou services sont
créés pour supporter les toutes dernières évolutions technologiques ou architecturales. Des consolidations,
des rachats d’éditeurs ou de solutions open source sont également fréquents. Ceci pose la question de la
pérennité des choix, toujours plus difficile pour les décideurs.

L’outillage en support d’une vision et d’une stratégie

clairement définies
Les choix d’outils doivent s’appuyer sur une vision claire de la cible, et notamment :
• Les objectifs métiers à atteindre pour les chaînes de valeur de bout en bout.
• Les qualités recherchées tout au long de cette chaîne et les caractéristiques souhaitées des systèmes
mis à disposition des utilisateurs finaux.
• Les typologies d’applications, de technologies, de plateformes et de standards à mettre en œuvre.

19
 La stratégie de l’outillage DevOps à mettre en œuvre doit aussi aborder plus spécifiquement :
• L’équilibre entre l’autonomie confiée aux équipes pour expérimenter et choisir d’utiliser des outils
et les besoins de conformité, standardisation et partage de savoir-faire à l’échelle de l’entreprise;
• Les types de solutions (open source, éditeur, solution maison), les modes d’acquisition (interne,
partenaire, logiciel ou service) et d’hébergement des outils (on-premise ou cloud : SaaS, PaaS,
CaaS, DaaS…).

L'architecture de chaîne intégrée d'outils

Les choix unitaires d’outils dans chacune des directions Métiers, Etudes, Développements, Tests et
Production ont pu participer à l’établissement de silos d’informations : les approches DevOps visent à les
éliminer.

Par exemple, des équipes de développement peuvent choisir JIRA pour gérer leur backlog Agile, les
équipes de production utilisent ServiceNow pour gérer l’exploitation, les responsables métiers
communiquent leurs besoins et suivent l’avancement à l’aide d’outils bureautiques. Chaque groupe utilise
ainsi ses propres outils et pas ceux des autres, ne facilitant pas la collaboration.

En support de la première voie DevOps [10], l’outillage doit aider à fluidifier la chaîne de valeur de bout en
bout, depuis l’émergence des idées métiers jusqu’à leur mise à disposition pour les utilisateurs finaux. Pour
cela, il est nécessaire de bâtir une architecture de chaîne intégrée d’outils en adoptant une vision globale :
• Au niveau de chacune des applications.
• Au niveau d’un domaine applicatif ou de l’ensemble de l’entreprise.

Exemple de chaîne outillée DevOps

THINK CODE DELIVER RUN MANAGE LEARN

CULTURE Collaboration and Sharing

Release Planning and Management

ITSM
CMDB User Feedbacks
Events
Delivery Pipeline
Monitoring
Source Control Deployment Automation Alerts

Envi Mgt Usage Analytics

Backlog Build & CI Infrastructure Logging

Mgt as a Service
Artifact
Runbook
Repository

APM
A/B Testing
IDE
Code Config Infrastructure
Review Mgt Provisioning

Test
Test Automation
Mgt

TEST Code Analysis Unit Functional

Service
Integration Virtualization Security Performance
Test Data
Mgt

[10] - “The Three Ways: The Principles Underpinning DevOps” - August 22, 2012 by Gene Kim
https://itrevolution.com/the-three-ways-principles-underpinning-DevOps/
20
Des chaînes d'outils par architecture de référence
La chaîne d’outils à mettre en œuvre pour faire évoluer une application Web en architecture client/serveur
ne doit pas forcément être la même que pour des micro-services containerisés sur des plateformes Cloud.
Aussi, il est préférable de définir une chaîne d’outils par architecture de référence et plate-forme cible [11],
plutôt qu’une seule et unique chaîne pour toutes les applications.

Exemple de chaîne DevOps sur IBM Cloud avec containers Kubernetes et Helm charts

Chaînes intégrées DevOps sur IBM Cloud Application à Kubernetes et Helm

http://ibm.biz/DevOpspattern http://ibm.biz/DevOpsK8Helm

Des chaînes intégrées d’outils pour la gestion des

opérations en continu
De nombreuses organisations commencent l’automatisation de leur approche DevOps par les outils du
pipeline de livraison CI/CD. Néanmoins, il convient de ne pas focaliser uniquement sur ces outils de
déploiement technique depuis les phases de développement, et d’adresser aussi les chaînes d’outils de
gestion des opérations en continu :

Exemple d’audit d’outillage sur DevOps Continuous Operations

Tableaux de bord & rapports

Runbooks
Légende
Evénements Collaboration
Outillage incomplet
Notifications
Supervision Outillage déployé
(mail, slack, …)

Logs

L’utilisation d’une plateforme ChatOps facilite la collaboration sur la détection et la résolution des incidents,
en intégrant les outils de la chaîne autour d’un espace de collaboration et de runbooks.

[11] - Cloud-Based DevOps Tools Are Ripening Quickly” - April 4, 2017 by Christopher Condo with Christopher Mines, Amy Homan, Andrew Reese – 21
Forrester - https://www.forrester.com/report/CloudBased+DevOps+Tools+Are+Ripening+Quickly/-/E-RES137388
L’expérimentation et l’adoption d’outils

Comme indiqué précédemment, l’outillage et les technologies évoluent très rapidement. Par conséquent,
les choix d’outils ne doivent pas être figés. Ils doivent s’appuyer sur des hypothèses et des décisions
d’architecture revues régulièrement, ainsi que sur des expérimentations continues dans un esprit de veille
technologique du marché.
Le recensement des outils déjà en place est également une étape clé qui permet d’identifier les
investissements et compétences sur lesquels l’initiative DevOps doit se développer mais aussi les
contraintes et résistances éventuelles à des changements d’outils.
Deux stratégies sont alors envisageables, soit :
• Un changement radical en adoptant une nouvelle plate-forme PaaS avec des services Cloud DevOps
intégrés prêts à l’emploi.
• Une adoption incrémentale par l’évolution des outils existants vers des chaînes DevOps intégrées.
Dans les deux cas, la montée en compétences des équipes sur ces outillages doit être menée de manière
progressive pour faciliter l’adoption des nouvelles pratiques.
Les outils sont nécessaires (mais pas suffisants) et critiques à l’adoption d’une approche DevOps. Le choix
d’outils facilitant la mise en œuvre de processus automatisés et la collaboration entre les différents acteurs
de la chaîne représentent alors de véritables catalyseurs au changement de culture.

Les choix d'outils et chaînes d'outils

DevOps doivent être réévalués
Ce qu’il faut
régulièrement pour s'adapter aux évolutions
retenir
d'architectures applicatives et au marché en
pleine effervescence.

22
04.

Créer une culture DevOps

La conduite du changement d’un projet de transformation DevOps doit être pensée avec les équipes et la
direction de l’entreprise. Le changement ne doit pas être vu comme une simple évolution de l’outillage et un
re-engineering des processus : l’essentiel des enjeux de cette transformation est axé sur l’Humain.

L’Humain, au sens de la capacité de l’organisation à adhérer à la démarche DevOps, au sens de la

capacité des équipes à collaborer et créer des ponts, et enfin au sens des collaborateurs à se projeter et
s’adapter à un nouveau mode de travail.

Le défi culturel de DevOps

Métier
• Je n’ai aucune
visibilité sur la
capacité de l’IT.
• Je veux des
évolutions au plus tôt.
• Quel est le niveau de
satisfaction des
clients ?
• Un incident majeur
impacte nos relations
client.
Production et
Développement
Opérations
• Pourquoi est-ce si • Nos processus
long pour obtenir un garantissent la stabilité
environnement ? du système.
• Je souhaite utiliser de • Le déploiement a
nouvelles librairies. encore échoué à
• J’ai synchronisé mon cause de nouvelles
code, je veux juste librairies.
qu’il soit déployé • Le développement ne
(facilement). comprend pas les
exigences
opérationnelles.

Abattre les « murs de la confusion »

L’adhésion et l’adoption de nouvelles pratiques de travail par tous les acteurs de la chaîne applicative, des
équipes de développement à la production informatique, sans oublier la maîtrise d’ouvrage, sont donc clés.

23
Les 3 niveaux de la transformation DevOps

La transformation DevOps se décline sur 3 niveaux :

• L’organisation : définir et communiquer sa vision, expliciter les Organisation

•
raisons et créer le ‘désir’ du changement
La ou les équipes : lever les barrières, permettre la construction
d’un nouveau référentiel commun pour collaborer, instiller
+
Equipe
l’amélioration continue, de la transparence, de la responsabilité
• L’individu : l’engagement personnel est un élément important
malgré les changements de métiers et l’impact de l’automatisation +
sur les activités elle mêmes. Collaborateur

Vision et Mobilisation
1
Leadership

Construction
2 Collaboration
d’équipe

Engagement Confiance et
3 individuel Respect

Vision et leadership
1 Mobiliser les ressources

Sans une vision partagée sous l’impulsion d’un leadership fort, un projet de transformation
DevOps devra faire face à de nombreuses difficultés. En effet, les équipes attendent
beaucoup de leur encadrement en matière d’orientation stratégique, ceci pour donner du
sens à leurs actions au quotidien.
La vision doit éclairer l’ensemble des acteurs sur la cible stratégique de l’entreprise,
pourquoi c’est important pour la réussite collective de l’organisation, quelle en est la valeur
pour les clients ? Quels en sont également les impacts pour chacun des collaborateurs ?
Le leadership d’une équipe dirigeante doit permettre de sponsoriser le projet en allouant des
moyens financiers et humains, en communiquant régulièrement sur les succès du projet et en
accompagnant toutes les équipes dans le changement de culture DevOps.

24
 La construction de l’équipe
Assurer une bonne collaboration 2

Il est évident qu’un groupe ne devient pas une équipe performante

immédiatement et qu’il faut réunir les conditions minimales et nécessaires à
ce développement.
Dans un premier temps, établir un point de départ par une évaluation de la
maturité de l’équipe DevOps à collaborer ensemble et en identifier les freins.
Ensuite, évaluer régulièrement la progression des capacités de l’équipe à
atteindre des objectifs communs.

Les caractéristiques « cible » d’une collaboration performante entre les

acteurs DevOps nécessitent :
• Le volontarisme et le volontariat (idéalement).
• Le partage : de ressources, de connaissances et compétences, de
responsabilités, de résultats.
• Le respect et la confiance entre les individus, pour une coopération
active.
• La participation : donner du feedback, identifier et résoudre des
problèmes, apprendre et partager.
• La responsabilité : partager voire échanger les responsabilités, définir et
respecter des engagements.

Dans un environnement collaboratif, la contribution de l’équipe et de chaque

membre est nécessaire. Elle doit être valorisée.

Florent Barth
Le mot de Responsable d’équipe nationale de développement et d’intégration
d’applications au Ministère de l’Education Nationale

Tout repose sur l'humain. Les leviers de la transformation sont axés

sur l'effort de communication, l'accompagnement au changement de
la culture Agile et DevOps.
L'engagement et la motivation des individus et des équipes sont un
facteur de succès.

25
 Confiance et Respect
3 L’engagement individuel
L’adhésion puis l’adoption des équipes vers un nouveau mode de travail et de
collaboration passent nécessairement par une implication et un engagement
individuel basé sur le respect et la bienveillance de chacun. Lorsqu’une erreur est
commise, elle est acceptable et doit être communiquée pour être corrigée au plus
vite. C’est un changement profond de paradigme de nos comportements formatés où
l’erreur n’est pas permise et n’est pas un moyen identifié de progression. Ce
problème culturel doit faire l’objet d’une prise de conscience collective au niveau de
l’équipe DevOps et de l’encadrement en général.

DevOps Institute préconise dans son rapport « Culture Eats Strategy for Breakfast –
Five Unique Skills of DevOps Leaders » [12] de créer les conditions de changement de
la culture d’entreprise en mettant en œuvre le modèle de transformation défini par
Kurt Lewin et basé sur 3 étapes majeures :

Modèle de Kurt Lewin

• Obtenir un « Exec Sponsor »

Unfreeze • Identifier les dysfonctionnements du terrain, définir des
1
Décristallisation objectifs et un planning
• Partager la situation avec tous les acteurs

• Commencer à mettre en place de nouvelles pratiques

Change • Partager très régulièrement avec le feedback de tous les
2 Changement acteurs sur les changements en cours
• Responsabiliser tous les acteurs

• Formaliser et documenter les changements de pratique

• Encourager les retours d’expérience entre les équipes pour
3 ReFreeze ancrer les nouvelles pratiques
Recristallisation
• Faire témoigner les acteurs qui développent les meilleures
pratiques

L’ancrage de nouvelles pratiques pour faire évoluer la

Ce qu’il faut
culture d’entreprise passe par un engagement fort des
retenir
personnes et la collaboration active des équipes.

[12] – Etude DevOps Institute – https://www.DevOpsinstitute.com/resources/DevOps-leadership-ebook/

26
L’impact RH de DevOps : de nouveaux rôles, de
nouveaux métiers
De nouveaux rôles DevOps et l’acquisition de nouvelles compétences doivent être développés, à savoir
des connaissances des outillages et méthodologies, les « Hard skills » mais aussi des capacités de
leadership, de relations interpersonnelles, et de changement, les « Soft skills». Les 2 natures de
compétences sont complémentaires et nécessaires pour permettre, à terme, de travailler en équipe de
manière performante.

On observe également le développement de nouveaux métiers en concertation avec les DRH de plus en
plus impliqués dans les projets de transformations numériques.

Exemple de nouveau rôle lié à DevOps

Ingénieur DevOps / Site Reliability Engineer
MISSION
Garantir le fonctionnement opérationnel des services en
terme de performance, disponibilité et capacité au travers
du pilotage et d’actions d’automatisation.
COMPETENCES (Selon domaine Cloud)
• Excellente connaissance de l’architecture technique Cloud
en support des offres de service
• Expérience dans les projets Agile Scrum / Kanban.
• Excellentes capacités de codage (Python, Java etc.);
Maîtrise des technologies d'orchestration du cloud
• Connaissance des outils d'automatisation OS (Ansible,
Puppet, Chef etc.)
• Connaissance de l'orchestration de conteneur (Docker,
Kubernetes etc.)
• Connaissance des technologies suivantes: Apache, Tomcat,
JBoss, DB etc.
ACTIVITES
RUN
• Piloter le fonctionnement opérationnel des services :
capacité, disponibilité et performance.
• Prendre en charge et résoudre les incidents de la
plateforme
• Assurer la coordination opérationnelle avec les services
providers.
BUILD
• Contribuer dans le cadre des solutions XaaS au
développement de nouvelles fonctionnalités et automatiser
la résolution des problèmes opérationnels.
• Piloter les initiatives de stabilité et de fiabilité pour
augmenter la disponibilité globale des solutions .
• Développer les tests et critères d’acceptation des services.
• Contribuer à la gestion des risques des solutions

Dans les nouveaux rôles, on observe l’apparition du « DevOps Product Owner ». Le métier de Product
Owner était jusqu’à maintenant limité à un périmètre Agile essentiellement sur des activités du
développement. Le “Product Owner” DevOps devient responsable globalement du cycle de vie de
l’application durant le développement et également de l’exploitation comme par exemple l’analyse des
incidents. Il engage, anime et motive une équipe complète DevOps.

Le mot de Henri Giordano

Responsable Centre d'expertises et DevOps chez Groupama

Nous avons créé un nouveau rôle « Ingénieur DevOps », avec un double

rattachement : un rattachement opérationnel à 1 ou 2 projets Agiles, et un
rattachement hiérarchique à l’équipe DevOps.
Avant les équipes étaient beaucoup en mode « contributif » avec un
fonctionnement par tickets et un périmètre de prestation bien défini pour
chacun. Désormais il y a un véritable esprit d’équipe, plus d’échanges et de
collaboration… les équipes ont moins l’esprit « silos »

27
05.

Comment bien déployer

DevOps ?
Le point de vue du marché

D’après la littérature et les approches recommandées sur le marché, la démarche DevOps peut être
réalisée suivant 2 étapes :
• Une étape d’expérimentation se focalisant sur la mise en place de pratiques et d’outils favorisant la
collaboration et la fluidité de fonctionnement entre les équipes Dev et Ops.
• La mise à l’échelle après Go / No Go. Cette étape doit répondre à 3 questions :
1. Quels sont les périmètres et critères de sélection des chaînes applicatives ?
2. Quel est le modèle d’organisation et sa gouvernance associée ?
3. Comment accompagner l’ensemble des équipes et l’encadrement pour se transformer ?

Mise en œuvre de DevOps en 2 étapes

Expérimentation Jalon Mise à l’échelle

décisionnel

1 Ciblage des chaînes applicatives

Unification et collaboration
Dev et Ops 2 Modèle de gouvernance

3 Transformation organisationnelle

28
 La recommandation d’IBM
Le modèle préconisé par IBM étend la proposition d’expérimentation suivie d’industrialisation en
insistant particulièrement sur l’anticipation et l’acculturation : c’est un projet de transformation
d’organisation à l’échelle.

Notre point de vue est d’aborder la mise à l’échelle progressivement, en commençant par
sensibiliser l’organisation dans son ensemble, puis via des expérimentations couvrant les pratiques,
l’outillage et la métrologie. Cette approche progressive est déterminante pour l’ancrage de nouveaux
modes de fonctionnements notamment dans la relation avec les métiers. Elle permet de mesurer
l’adoption, les progrès et les dysfonctionnements.

L’approche IBM : une évolution progressive

1 2 3 4

Concevoir Lancer un Mettre à

Sensibiliser
la trajectoire Pilote l’échelle
(MVP)

1. Acculturer 1. Etat des lieux 1. Lancement de 1. Gouvernance

2. Légitimer la vision 2. Etude détaillée pilote 2. Plan de
3. Mobiliser les d’une chaîne 2. Elaboration de la transformation à
équipes applicative chaîne cible l’échelle
3. Conception de la 3. Accompagnement 3. Conduite du
trajectoire de changement
l’expérimentation 4. Indicateurs de
4. Rétrospectives performance
DevOps

29
 1 Sensibiliser les parties prenantes
Le ba-b.a. : un langage et une compréhension communs
1. Acculturer
Un jalon indispensable du lancement d’une démarche
2. Légitimer la
vision DevOps est l’acculturation, à tous niveaux de l’organisation.
3. Mobiliser les Fort de l’accompagnement de nombreux clients dans le
équipes monde, mais aussi de sa propre expérience interne de
transformation, IBM s’est forgé un point de vue synthétisé
dans un livret « DevOps pour les nuls » [13] .

Ce livret est destiné aux dirigeants, aux décideurs

et aux praticiens qui débutent leur approche
DevOps, veulent comprendre ce que recouvre ce
terme et comment leur entreprise peut en tirer
avantage.
Lors du lancement d’une initiative DevOps, nous
recommandons généralement d’organiser une
session de sensibilisation. Celle-ci assure que
l’ensemble des parties prenantes possède une
compréhension commune du sujet : définitions,
organisation et rôles, positionnement avec les
autres méthodes et référentiels, démarche de mise
en œuvre, outillage, etc…

Aller plus loin : IBM Cloud Garage Method

Si vous réfléchissez à introduire DevOps dans votre

organisation, nous mettons à disposition des ressources
destinées à adresser les différents leviers de la
transformation DevOps : outils, architectures, processus de
bout en bout, mais aussi culture, amélioration continue, …

L’IBM Cloud Garage Method permet aux

métiers, aux développements et aux
opérations de concevoir, délivrer et valider
en continu de nouvelles fonctionnalités :
https://www.ibm.com/cloud/garage/

IBM Cloud Garage Method propose un répertoire de

bonnes pratiques, d’architectures de référence et de
formations, parmi lesquelles :
• Culture et organisation
• Lean Startup
• Développement Agile
• Livraison continue
• Cloud et outils

[13] https://www.ibm.com/ibm/DevOps/us/en/resources/dummiesbooks/index.html 30
https://www.programmez.com/livres-blancs/DevOps-pour-les-nuls-2eme-edition
 Concevoir la trajectoire 2
L’expérience d’IBM en accompagnement de ces projets de 1. Etat des lieux
2. Etude détaillée
transformation supporte une stratégie orientée métier d’adoption des
d’une chaîne
capacités DevOps et d’amélioration des performances. applicative
La création d’une stratégie orientée métier inclut la priorisation d’un 3. Conception de la
ensemble d’objectifs métiers mesurables, leur évaluation au regard des trajectoire
pratiques actuelles, et le développement d’une trajectoire d’adoption.
Cette trajectoire doit fournir un guide pour les améliorations de capacités
et identifier des étapes incrémentales permettant d’atteindre vos objectifs
métiers.

Modèle de Maturité IBM DevOps

EXEMPLE DE CRITERES DE MATURITÉ

NIVEAU DE MATURITÉ

AXES D’EVALUATION Pratiqué Répliqué Fiable Evolutif

• Liaison des objectifs aux

versions • Planification stratégique • Définition des versions
• Documentation des
• Gestion centralisée des du portfolio avec objectifs métier
Plans & Mesures objectifs
besoins • Tableau de synthèse des • Indicateurs de mesure de
• Gestion des ressources
• Indicateurs et métriques indicateurs la valeur apportée
projet

Surveillance
Développement & Tests Versions & Déploiements Amélioration continue
& Analyses

Maturité pratique DevOps

Pratiqué
Planification métier
en continu
5
4 Répliqué
Développement 3 Expérience
collaboratif 2 utilisateur
1
0 Fiable
Supervision en
Test en continu
continu
Evolutif
Déploiement en
continu

La définition d’une trajectoire DevOps s’appuie sur :

1. Un état des lieux basé sur un modèle de maturité des pratiques DevOps développé par IBM,
ainsi que sur une analyse des initiatives de transformation déjà engagées.
2. Un ou des ateliers collaboratifs afin de décrire, dans une approche Lean, une chaîne de
fabrication et d’identifier les axes d’amélioration.
3. Les résultats et conclusions de cette étape permettent alors de tracer la trajectoire et de définir
le contenu d’un pilote.

31
 3 Lancer un pilote

L’objectif du pilote est donc d’obtenir l’adhésion des différentes

1. Lancement de
pilote
parties prenantes (management, métier, équipes côté Dev et Ops,
2. Elaboration de la RH etc…) au travers d’un plan d’actions cohérent démontrant les
chaîne cible résultats et bénéfices de l’approche DevOps. Les rétrospectives
3. Accompagnement permettent de valider l’atteinte des résultats et d’identifier les actions
du pilote
nécessaires au passage à l’échelle.
4. Retrospectives

Le choix du projet pour mettre en place ce pilote est primordial : il

doit être de taille conséquente pour pouvoir montrer des résultats
tangibles, tout en demeurant d’ampleur modérée afin de favoriser
son succès.

Mettre à l’échelle : DevOps As A Service 4

1. Gouvernance
A ce stade, les 3 étapes précédentes ont pour but : 2. Plan de
1. D’engager l’ensemble des parties prenantes dans une transformation à
l’échelle
dynamique de mise en œuvre progressive au travers d’une
3. Conduite du
roadmap partagée et réaliste. changement
2. D’accompagner le changement. 4. Indicateurs de
performance
3. De préparer le passage progressif à l’échelle. DevOps

Notre recommandation pour le passage à l’échelle est de mettre en œuvre un modèle de

gouvernance « DevOps As A Service », pour garantir une solution pérenne et ancrée dans une
démarche d’amélioration continue.

Comme nous l’avons vu dans les 8 facteurs de succès, cette offre de service « DevOps As A
Service » partagée BizDevOps constitue un cadre de référence. L’ensemble des acteurs peut et
doit s’appuyer dessus pour progresser dans les pratiques et étendre le périmètre des
applications et services éligibles.

32
Cette offre implique également un support organisationnel que l’on peut appeler centre d’expertise
DevOps pour assister et généraliser la démarche DevOps au sein de l’entreprise.

Période d’accompagnement Autonomie

Industrialisation
DevOps as a Service
Extension progressive
2 à N Applications

Pilote

Engagement et
sensibilisation

2 à 8 mois
2 à 12 mois
Lancement

La notion d’offre de service DevOps-aaS consiste à mettre en place un centre d’expertise DevOps pour
déployer, accélérer et garantir la cohérence de la mise en œuvre des pratiques DevOps au sein des
organisations IT. Ses missions sont notamment :
• Aider les équipes à mettre en œuvre les pratiques et outils DevOps pour les applications pour
répondre aux objectifs de qualité et de Time To Market (communication, assistance, coaching,
etc...).
• Assurer une mise en œuvre et des performances constantes des pratiques et des outils DevOps
au sein de toutes les équipes.
• Assurer un transfert progressif des connaissances et des compétences des équipes DevOps pour
les rendre plus autonomes.
• Maintenir un cadre de référence DevOps et le faire évoluer selon un processus d'apprentissage
avec les équipes internes et les référentiels externes (SAFE, Scrum, Lean IT, ITIL, etc.).

Le mot de Dany Garnier

Ingénieur production chez Editions Lefebvre Sarrut

L’accompagnement d’IBM nous a permis de bien cadrer et prioriser notre

initiative DevOps sous toutes les dimensions nécessaires : outils,
processus, organisation, communication et sensibilisation des équipes.
Nous avons pu envisager plus sereinement la transformation.
Les premiers projets mis en œuvre selon l’approche DevOps se doivent
d'être exemplaires pour engager l'ensemble de la DSI et nos métiers !

33
DevOps
Et si c’était vrai ?

C’est vrai, DevOps apporte des bénéfices tangibles, mesurables

par le métier, dans des proportions souvent impressionnantes.

C’est vrai, DevOps est un défi pour les entreprises, unique en son
genre depuis 30 ans. Cette transformation repose sur une vision
partagée et une dimension humaine forte, en particulier dans
l’accompagnement au changement et l’évolution des compétences.

C’est vrai, chaque organisation nécessite une approche adaptée :

à sa maturité, à sa culture, à ses processus et son modèle
opérationnel. Loin du « One Size Fits All », c’est une approche
mesurée et contextualisée qui donnera les meilleurs résultats.

Dans ce livre blanc, nous avons exprimé principalement nos

convictions du « Comment réussir une transformation DevOps? ».
La question primordiale pour toute organisation est de savoir
pourquoi mettre en place une transformation DevOps ?

La réponse à cette question du pourquoi doit apporter un sens

commun à toutes les équipes opérationnelles et à l’équipe de
direction de l’entreprise.

34
 Glossaire
CALMS : Culture, Automation, Lean, UAT : User Acceptance Testing
Measurement, Sharing
US: User Story
CD : Continuous Delivery
CI : Continuous Integration
Everything ‘As A Service’
CT : Continuous Testing
KPI : Key Performance Indicator
XaaS : Anything/Everything as a Service
ITIL : Information Technology Infrastructure
IaaS : Infrastructure as a Service
Library
PaaS : Platform as a Service
MVP : Minimum Viable Product
CaaS : Container as a Service
PO : Product Owner
SaaS : Software as a Service
SAFe : Scaled Agile Framework
DaaS : DevOps as a Service
SM : Scrum Master
TTM : Time To Market

Références
[1] - Patrick Debois, « Agile 2008 Toronto: Agile Infrastructure and Operations Presentation »,
2008
[2] - Evénements DevOpsDays : https://www.DevOpsdays.org/ , depuis 2009
[3] [4] - Manifeste pour le développement Agile de logiciels et principes sous-jacents, 2001 :
https://Agilemanifesto.org/iso/fr/manifesto.html
[5] - The Three Ways: The Principles Underpinning DevOps, 2012 by Gene Kim :
https://itrevolution.com/the-three-ways-principles-underpinning-DevOps/
[6] -SAFe 4.6 DevOps and Release on Demand : https://www.scaledAgileframework.com/DevOps-
and-release-on-demand/
[7] Forrester « The State Of Agile 2017: Agile At Scale », 2017
[8] - Etude IDC 2018. https://ibm.biz/Bd25F2
[9] - Etude “State of DevOps 2018” : https://DevOps-research.com/2018/08/announcing-accelerate-
state-of-DevOps-2018/
[10] - “The Three Ways: The Principles Underpinning DevOps” - August 22, 2012 by Gene Kim
https://itrevolution.com/the-three-ways-principles-underpinning-DevOps/
[11] - Cloud-Based DevOps Tools Are Ripening Quickly” - April 4, 2017 by Christopher Condo with
Christopher Mines, Amy Homan, Andrew Reese – Forrester -
https://www.forrester.com/report/CloudBased+DevOps+Tools+Are+Ripening+Quickly/-/E-RES137388
[12] – Etude DevOps Institute – https://www.DevOpsinstitute.com/resources/DevOps-leadership-
ebook/
[13] https://www.ibm.com/ibm/DevOps/us/en/resources/dummiesbooks/index.html
https://www.programmez.com/livres-blancs/DevOps-pour-les-nuls-2eme-edition
 Pour nous contacter

Devopsfr@fr.ibm.com

© Copyright IBM Corporation 2019

IBM France
17 avenue de l’Europe
92275 BOIS COLOMBES CEDEX
Tél. : 0810 015 810
http://www.ibm.com/fr

IBM, IBM Services, le logo IBM et le logo IBM Services, sont des marques de International Business Machines
Corporation aux Etats-Unis et/ou dans les autres pays. Les autres noms utilisés pour désigner des sociétés, des produits ou
des services sont des marques ayant leur titulaire respectif. La liste des marques IBM est disponible sur le Web à l’adresse
suivante :
«Copyright and trademark information» at www.ibm.com/legal/copytrade.shtml

Group Name / DOC ID / Month XX, 2017 / © 2017 IBM Corporation 36