DevOps : Retours d’expérience et bonnes pratiques issus du Think Tank Automic

1. Quelle métrique
pour fédérer
Dev & Ops ?
Think Tank Automic
Livre Blanc
DevOps : Retours d’expérience et
bonnes pratiques issus du Think
Tank Automic

2. Livre Blanc
Follow Us2
Quelle métrique pour fédérer
Dev & Ops ?
DevOps : Retours d’expérience et bonnes pratiques issus du Think
Tank Automic
Texte établi par
Gérald Audenis
François Bazenet
Eric Bouvet
Thierry Falque-Vert
Charlotte Gondre
José Mauricio
Jérôme Meyer
Frédéric Poulain
Alexandra Sommer
Rédaction
Alexandra Sommer
Graphisme
Emilie Daboussy
Produit par
Automic
Tour Pacific
11, cours Valmy
92800 Puteaux
France
Copyright © 2016 Automic Software S.A.S. Tous droits réservés. La copie, photocopie, reproduction,
traduction ou conversion de ce livre blanc sous quelque forme que ce soit, mécanique ou électronique,
est interdite sans autorisation préalable obtenue par écrit auprès de Automic Software S.A.S.

3. Livre Blanc
TABLE DES MATIÈRES
Préface 4
Chapitre 1 : Un indicateur mutant pour fédérer Dev & Ops 8
Chapitre 2 : Le TRS, un KPI sans équivalent dans l’informatique 12
Chapitre 3 : Implémentation du TRS en environnement DevOps 15
Etape 1 : Intention 16
Etape 2 : Identification du périmètre d’application 16
Etape 3 : Implication 17
Etape 4 : Partage du vocabulaire 18
Etape 5 : Etat des lieux du système de mesure 19
Etape 6 : Collecte des points de mesure 21
Etape 7 : Premières mesures 22
Etape 8 : Analyse des gaspillages 22
Atelier Arbre des Gaspillages 23
Atelier TIMWOOD 26
Etape 9 : Système de pilotage 28
Etape 10 : Industrialisation 29
A propos du Think Tank Automic 31

4. Livre Blanc
Follow Us4
Préface
DevOps est né en 2009 après qu’un administrateur système (sysadmin) du nom
de Patrick Debois a fait le constat que l’Agile, pour être pleinement efficace, devait
nécessairement embarquer toute les équipes de la DSI : Dev (développement) et
Ops (opérations). Le mouvement DevOps a connu par la suite un essor rapide en
rassemblant sous sa bannière un ensemble de technologies et de pratiques permettant
des mises en production plus petites, plus fréquentes et moins risquées. En 2010, les
valeurs essentielles de DevOps étaient résumées sous forme d’un acronyme : CAMS
pour Culture, Automatisation, Mesure et Partage (Sharing, en anglais).
La mesure est ainsi, depuis ses débuts, l’un des piliers de DevOps*. C’est aussi l’un
de ses territoires les moins explorés et les moins documentés. Le présent Livre Blanc
cherche à répondre à une question simple : Comment mettre en place une mesure
adaptée à DevOps, qui facilite le rapprochement entre équipes Dev et Ops et qui offre
une vision objective et utile de la performance ?
Nous espérons que la réponse que nous proposons ici de manière très concrète
retiendra votre attention et vous donnera envie de la mettre en pratique. Dans tous les
cas, cette réponse n’aurait pas pu voir le jour sans un certain nombre de rencontres,
incarnées par des personnes que nous tenons à remercier chaleureusement :
• Rencontreavecl’industrie,toujoursàlapointeenmatièredeperformance,enlapersonne
de Christian Hohmann, expert en Lean Manufacturing de réputation internationale,
• Rencontre avec des managers de production informatique visionnaires, avec qui
nous avons transposé depuis 2010 les standards de performance industrielle à la
productioninformatique.C’estleurtravaildetouslesjours,dansleursorganisations,
qui a permis d’apporter une réponse pratique tant sur le « quoi » de la mesure que
sur le « comment » de sa mise en œuvre.
• Rencontre avec des managers de développement informatique, de la même étoffe,
qui ont permis depuis 2014 d’établir une vision de bout en bout de la performance
de la DSI tout en apportant une diversité bienvenue dans les approches.
En 2015, comme chaque année depuis 2010, ces rencontres ont eu lieu dans le cadre de
la communauté du Think Tank Automic, dédiée à la mesure de la performance.
*Dans son enquête 2015 « Adoption et Enjeux de DevOps en France », IDC indique que la définition
d’indicateurs communs pour Dev et Ops est un critère clé de succès pour 69% des organisations en
cours d’adoption de DevOps.

5. Livre Blanc
Follow Us5
Nous tenons à remercier de tout cœur tous les managers qui y ont participé pour leur
engagement, leur esprit de partage, leurs idées et leur capacité hors norme à les mettre
en pratique et sommes très reconnaissants d’avoir pu travailler cette année avec :
• François BAZENET, CAISSE DES DEPOTS
• Patrice BENOIT, CCI PARIS ILE DE FRANCE
• Nicolas BOGUCKI, INSTITUT NATIONAL DE L’AUDIOVISUEL
• Pierre-Yves BOUCHARD, ANTEMETA
• Eric BOUVET, ARKEMA
• Didier CANITROT, EULER HERMES
• Cyrille CARTIER, ANTEMETA
• François GILLES, RECTORAT DE VERSAILLES
• Geneviève GLEIZES, CCI PARIS ILE DE FRANCE
• Charlotte GONDRE, RECTORAT DE VERSAILLES
• Gilles LAVIGNE, POLE EMPLOI
• José MAURICIO, BRED
• Frédéric POULAIN, EDENRED FRANCE
• Olivier SOULABAILLE, SECURITAS
• Etienne TAROT, LACTALIS
Merci tout particulièrement à Charlotte Gondre et Eric Bouvet pour l’animation des
groupes de travail DevOps et ITIL dont les travaux, loin de s’opposer, se sont nourris
mutuellement dans l’intérêt de tous.
Un grand merci également à tous ceux qui ont participé à la rédaction des publications
antérieures du Think Tank Automic. L’expérimentation d’un indicateur synthétique en
environnement DevOps n’aurait pas pu être aussi rapide sans s’appuyer notamment sur
le “guide pratique d’implémentation du Taux de Rendement Synthétique (TRS)”, paru
en 2015. Nous en reprenons ici les éléments indispensables pour que le lecteur n’ait pas
besoin de s’y référer.
Merci, enfin, aux équipes Automic qui ont, année après année, œuvré à rendre toutes
ces rencontres passionnantes, productives et conviviales. Merci à Jérôme Meyer et à
Michel Enkiri pour la coordination métronomique des groupes de travail. Merci à Gérald
Audenis, Thierry Falque-Vert et Nathan Srour pour l’animation experte des sessions
de travail et ateliers. Merci à Alexandra Sommer pour l’organisation irréprochable des
événements et la mise en forme impeccable des publications.

6. Livre Blanc
Follow Us6
LES MEMBRES DU THINK TANK TÉMOIGNENT...
« Membre du Think Tank depuis plusieurs années, j’ai pu bénéficier dans mon quotidien
del’immensetravaildegroupetournantautourdel’idéequ’ilestpossibledansl’ITcomme
dans l’Industrie d’identifier la Performance de notre activité et de nos organisations.
Trouver un moyen de Mesurer a été la toute première étape complétée avec succès
par l’équipe initiale. Mais elle s’est rapidement complétée grâce à l’arrivée de nouveaux
membres par la phase d’identification des gaspillages puis enfin par la phase de
correction pour boucler par une nouvelle campagne de mesure… La roue de Deming
avait fait un premier tour, il ne s’agissait plus que de consolider pour progresser et ce fut
la rédaction des Livres Blancs. Encore bravo à tous et surtout un grand MERCI ! »
Pierre-Yves Bouchard – Directeur de Production Cloud - ANTEMETA
« J’ai participé aux travaux du Think Tank dès sa création en 2010. Débattre sur
l’intérêt de transposer à l’Informatique un indicateur de performance issu de l’Industrie
fut passionnant. Expérimenter puis industrialiser la démarche sur le Service Desk et
des processus clefs (gestion des mises en production, gestion des événements) pour
piloter la performance, parfois dans un contexte international, le fut encore davantage.
Aujourd’hui, les entreprises et les administrations disposent, au travers des livres
blancs, d’une méthodologie et des retours d’expérience documentés. De quoi faciliter
l’adoption et accélérer la mise en œuvre en quelques semaines seulement, alors que
plusieurs mois étaient requis lors des premières expérimentations. »
Eric Bouvet, Responsable IT Operations - ARKEMA
« Le groupe de travail DevOps est une bonne illustration de l’intelligence collective. Les
échanges sympathiques et riches nous ont permis de mieux penser nos processus de
travail transverse, de les améliorer et de s’initier aux indicateurs synthétiques. Thanks
Think Tank ! »
Geneviève Gleizes, Responsable technologies transverses et Développement Web
DPMA - DPSI - CCI PARIS ILE DE FRANCE
« En appliquant simplement la méthode et grâce aux échanges avec les participants, j’ai pu
mettre en place rapidement un indicateur pertinent pour mesurer la performance de notre
nouvelle chaine de déploiement pour une application stratégique, dans un esprit DevOps. »
Frédéric Poulain, Responsable Système & Réseaux - EDENRED
« Un partage très riche et unique d’expériences avec nos pairs actuels (OPS) et futurs
(DEV). Des échanges constructifs en toute transparence intégrant les besoins et
contraintes de chacun. Et du concret, un indicateur de référence pour mesurer l’impact
de la mise en œuvre de DevOps en terme de valeur Business. »
Didier Canitrot, Head of GIP Process and Service Design - EULER HERMES

7. Livre Blanc
Follow Us7
« La direction des systèmes d’information de Météo France est soumis à des contraintes
de marché et d’adaptation aux normes qui nécessitent des mises en production rapides
et sûres. La mise en oeuvre d’indicateurs de bout en bout, caractéristique du DevOps
est en cours. C’est en suite des réunions et présentations du Think Tank Automic que
ces idées on pris de la substance et sont devenues plus concrètes. »
Daniel Dure, Directeur des Systèmes d’Information - METEO FRANCE
« Nouveau Think Tank, nouvelles rencontres et toujours des résultats à forte valeur
ajoutée. Le partage des réussites et des difficultés de chacun permet au groupe de
progresser … Besoin d’un TRS pour mesurer ces progrès ? »
Gilles LAVIGNE, Directeur Adjoint des Opérations - POLE EMPLOI
« Travailler à définir, puis à évaluer, des points de mesures de qualité, de disponibilité et
de performance d’une chaine de production logicielle en mode « DevOps » a permis de
confronter la théorie d’un modèle synthétique, celui du TRS, à la réalité opérationnelle.
Le résultat a dépassé nos attentes . Il s’avère en effet qu’une définition et une analyse
concertée des mesures favorisent la cohésion des équipes DEV (Etudes) et OPS
(Exploitation). Ceci contribue à rendre de fait les équipes acteurs de la conduite du
changement DevOps et à en mesurer de façon factuelle les gains pour servir l’objectif
premier de la DSI à savoir la satisfaction des clients. »
Charlotte Gondre, Chef du Service Etudes & Développement - RECTORAT DE VERSAILLES

8. Livre Blanc
Follow Us8
Chapitre 1 : Un indicateur mutant
pour fédérer Dev & Ops
Une affaire non résolue : DevOps & la mesure
DevOps a connu un essor fulgurant depuis son apparition au tournant des années
2010. En l’espace de cinq ans, près d’un tiers des organisations informatiques se sont
lancées dans l’aventure DevOps, au moins sur un pilote. Le principal moteur de cette
transformation est l’ambition affichée de réduire le délai entre l’expression d’une idée et
son activation en environnement de production (Time to Production).
Mais au fait, quel est aujourd’hui votre Time to Production ? De combien s’est-il amélioré ?
La question peut sembler provocatrice à l’heure où la Mesure est affichée comme l’un
des quatre piliers de DevOps. Pourtant, l’expérience montre que la pression continuelle
portée sur la livraison de projets toujours plus urgents empêche les organisations
de réfléchir à leur système de mesure et de répondre à ces questions basiques. Le
développement enchaine les sprints et puis, un beau jour, les features finissent bien par
arriver en production. Mais quand ? Avec quel impact ? Et à quel prix ?
La mesure dans DevOps est bel et bien une affaire non résolue. Il suffit d’évoquer la
question avec des personnes confrontées au sujet pour que reviennent les questions
suivantes :
• Comment contrôler le fonctionnement et mesurer les progrès d’une chaîne de
delivery Agile ?
• Comment mesurer la Performance de bout en bout plutôt que celles des Dev et
des Ops en silo ?
• Comment éviter les indicateurs toujours verts qui masquent les problèmes (l’effet
“Dev-Oups”) ?
• CommentamenerDevetOpsàmieuxprendreencompteleurscontraintesrespectives?
• Comment gagner en lisibilité et ne pas se laisser submerger par une information
surabondante (Dashboard Everything) ?
La vérité est ailleurs : Un standard industriel, le TRS
Les mesures existantes apparaissent inopérantes pour fédérer Dev et Ops car elles
sont en décalage profond avec les enjeux collaboratifs de DevOps. Les KPIs reflètent
le cloisonnement des organisations. Les Opérations ne se retrouvent pas dans les
métriquesAgiles.LesEtudesneseretrouventpasdanslesSLAs.Lesoutilsfonctionnent
« en silo » et ne permettent pas une vision de bout en bout.

9. Livre Blanc
Follow Us9
Il fallait donc chercher la vérité ailleurs que dans l’informatique. En l’occurrence, nous
avons trouvé l’inspiration dans l’industrie, confrontée depuis des décennies aux enjeux
d’agilité et de fiabilité au point d’avoir établi un standard de mesure de la performance :
le Taux de Rendement Synthétique (TRS). Largement répandu dans les environnements
industriels, cet indicateur n’est pas un indicateur de plus mais bien la clé de lecture
principale de la performance pour les directeurs d’usine.
Notre démarche a simplement consisté à appliquer ce standard industriel à un nouveau
type d’usine : la digital factory. Nous avons voulu transposer le TRS en environnement
DevOps et valider sa pertinence en environnement réel. Nous avons voulu en faire un
indicateur commun qui permette de gagner en lisibilité et de piloter la Performance
globale de la chaîne de delivery de la DSI, plutôt que les performances locales au niveau
des Dev et des Ops. Nous avons voulu également nous inspirer des méthodes d’analyse
et d’amélioration continue qui sont utilisées dans le sillage du TRS comme l’arbre des
gaspillages ou la méthode TIMWOOD.
Des résultats concrets : Bonnes pratiques & Retours d’expérience
Les résultats présentés dans ce Livre Blanc sont le fruit d’un travail d’équipe. Pour
garantir des résultats concrets, chaque membre du Think Tank Automic s’est engagé
personnellement à produire une mesure dans son propre environnement. L’approche
communautaire et collaborative a fait le reste : le fait d’avancer de concert et de
confronter l’expérience de chacun à chaque étape a permis d’aller plus vite et d’aborder
la mise en œuvre avec confiance.
Dans un premier temps, le groupe a convergé sur la définition d’un TRS transposé à la
chaine de delivery logiciel. Cette définition est intervenue à deux niveaux. Le niveau
général définit ce qui doit être mesuré (le quoi). Le niveau détaillé propose différents
indicateurs permettant de le mesurer (le comment). Il existe en effet différents moyens
de mesurer le TRS selon la capacité d’une organisation à produire certaines mesures.
Certaines mesures, plus simples, sont suffisantes dans une première approche et
permettent de franchir un premier pas significatif en matière de pilotage. Cette
définition flexible a permis de construire une boite à outils générique adaptable aux
contextes des différents membres.
Dans un second temps, le groupe a mesuré le TRS à partir de cette définition. Les
premiers résultats ont été suivis mensuellement. Ils ont permis de valider la pertinence
de la mesure et son intérêt tant pour l’identification de pistes d’amélioration que pour
sa capacité à fédérer équipes Etudes et Production. Des ateliers spécifiques ont été
conduits durant cette phase pour rentrer dans l’analyse des gaspillages et identifier
des plans de remédiation. Les retours d’expérience ont été partagés entre membres

10. Livre Blanc
Follow Us10
que ce soit pour l’adoption ou pour l’usage du TRS.
En fin d’année, les membres sont revenus sur les bonnes pratiques qu’ils souhaitaient
partager suite à leur propre expérience de la mise en place du TRS. Ces conseils sont
présentés dans le tableau ci-dessous.
Les enseignements : La mesure est un outil collaboratif très efficace
Au-delà des résultats détaillés dans les chapitres suivants, il est ressorti de cette
année de travail en communauté que la mesure était un outil collaboratif extrêmement
puissant.
La mesure aide à fédérer et à faire adhérer. On réduit trop souvent DevOps à
l’automatisation et à la technologie et on oublie par la même occasion la dimension
du partage qui est essentielle. A la base DevOps est une question de culture, de
communication, de confiance, de collaboration. Au sein des organisations qui l’ont
mis en place, la mesure a amené Dev et Ops à travailler ensemble sur des indicateurs
communs et a contribué à transformer la culture. La volonté de s’améliorer ensemble
en est ressortie renforcée.
Expérimentation du TRS : Bonnes pratiques
1 Assimiler la méthode
• Avoir une vision claire du TRS et une bonne compréhension du
modèle
• Développer une certaine curiosité
• Partager les retours d’expérience à travers des Think Tank par
exemple
2 Procéder par étape
• Cibler et définir un périmètre d’application restreint et maîtrisé
• Se remettre en cause continuellement
• Ne pas hésiter à adapter le périmètre ou les définitions au fur et à
mesure que l’on comprend mieux le modèle
3 Partager / Impliquer
• Communiquer autour du TRS, privilégier la collaboration et le
partage des besoins
• Partager les mesures et en conséquence les processus
• Réfléchir aux modalités d’analyse des écarts en impliquant les
équipes
4 Démontrer la valeur
• Impliquer les acteurs du terrain
• Proposer des plans d’actions pragmatiques et priorisés
• Capitaliser sur les quick-wins
5 Pérenniser
• Penser à la gestion du cycle de vie du TRS et son maintien en
condition opérationnelle
• Penser à revoir et à réactualiser les objectifs et critères de mesure
• Inscrire l’ensemble des indicateurs dans les standards

11. Livre Blanc
Follow Us11
Un moyen pratique d’établir un dialogue. La Mesure ne doit pas être imposée mais
présentée comme un moyen d’établir un dialogue. La Mesure ne doit pas être un projet
uniquement Dev ou uniquement Ops mais être conçue de façon concertée. La Mesure
ne doit pas se focaliser sur le chiffre mais apporter une discussion entre équipes. Les
membres du Think Tank ont construit leur TRS ensemble, avec leurs équipes dans une
approche résolument Bottom-up.
Le TRS permet d’aller vite à l’essentiel. Tout le monde veut mesurer mais rares sont
ceux qui prennent le temps de mettre les mesures en place. Le TRS présente l’intérêt
de pouvoir être implémenté rapidement, quitte à ce que la mesure soit embryonnaire
dans un premier temps. Le cadre de définition général permet d’aller vite sans rien
oublier d’essentiel. La valeur vient ensuite en marchant : On commence avec ce qu’on
sait faire et on progresse au fur et à mesure. Les résultats sont apparus comme très
pertinents même à partir de mesures partielles. Par ailleurs, la méthode en 10 étapes
présentée au Chapitre 3 est une aide précieuse pour avancer pas à pas et franchir des
étapes clairement identifiées.
Cultiver un état d’esprit collaboratif. L’avantage des mesures, c’est qu’elles sont
factuelles, objectives, transparentes, honnêtes et partagées. Pour en tirer le meilleur
parti, il faut se mettre en position d’écoute de l’autre et accepter que l’on ait des choses
à améliorer. Par ailleurs, la discussion sur les mesures à mettre en place nécessite de
s’écouter pour se comprendre : Dev et Ops ne mettent pas toujours la même chose
derrière un même terme. Du point de vue du manager, il importera d’être bienveillant et
de ne pas mettre en place la mesure dans un objectif de sanction. Compte-tenu que le
TRS est un indicateur de progrès, sa valeur est par définition non optimale (c’est-à-dire
loin de 100% !) et il est recommandé de s’axer sur la variation de l’indicateur, et non sur
sa valeur absolue. En tout état de cause, la communication est clé !
L’essayer c’est l’adopter ! Dans un premier temps, le principe d’un indicateur unique
permettant de mesurer la « performance de DevOps » a laissé certains membres
dubitatifs. Les mêmes sont aujourd’hui les premiers convaincus que « ça marche ».
La mesure leur a en effet permis de cimenter une culture de collaboration. Ils ont pu
constater que la recherche de l’amélioration continue est bel et bien partagée par
les équipes Ops & Dev. A partir du moment où ils se sont mis d’accord pour définir
des indicateurs factuels et objectifs et les analyser ensemble, le dialogue s’est établi
ainsi que la confiance. Du point de vue des managers, la valeur la plus importante a
été trouvée dans le travail mené en commun avec les équipes. Le TRS est un moyen
efficace d’y parvenir en un temps record !

12. Livre Blanc
Follow Us12
Chapitre 2 : Le TRS, un KPI sans
équivalent dans l’informatique
Plusieurs années d’expérimentation dans le cadre des activités du Think Tank Automic
ont permis de révèler que deux indicateurs standards en environnements industriels
apportaient une réponse pratique efficace aux besoins de partage et de pilotage des
organisations informatiques :
• Le Taux de Rendement Synthétique (TRS), qui mesure la performance d’une
unité de production,
• Le Taux de Rendement Global (TRG), qui intégre la charge effective de ce
moyen de production.
Ces indicateurs présentent plusieurs caractéristiques originales en environnement
informatique :
• Lisibilité : Ce sont des indicateurs synthétiques, obtenus par la multiplication
d’autres indicateurs, permettant de suivre en un coup d’œil l’évolution de la
performance. Cela permet de mieux partager objectifs et résultats avec les clients,
les équipes de la DSI ou la Direction Générale.
• Amélioration : Ce sont des indicateurs de progrès, qui n’ont pas vocation à
atteindre 99,9% ou 100%. Des taux de 60% ou 70% sont fréquents, même en
fonctionnement normal. Cela permet d’analyser les dysfonctionnements et de
constater les améliorations.
• Bout-en-bout : Ce sont des indicateurs composites qui intègrent d’une part la
qualité de la production (vue client) et d’autre part l’efficacité du processus (vue
fournisseur). Cela permet un pilotage équilibré et une implication de l’ensemble
des équipes.
Qu’est-ce que le TRS ?
L’Industrie recourt habituellement pour le pilotage de sa Performance au Taux de
Rendement Synthétique (TRS) correspondant en anglais à l’Overall Equipment
Effectiveness (OEE). Cet Indicateur Clé de Performance permet d’évaluer sur un
axe unique l’efficacité opérationnelle, les objectifs de Performance et le résultat des
initiatives de productivité.

13. Livre Blanc
Follow Us13
Il s’agit d’un indicateur sans grandeur, consistant en la multiplication de trois taux :
• Le Taux de Disponibilité « Td » (capacité de l’unité de production à être utilisée),
• Le Taux de Performance « Tp » (variant en fonction des cadences),
• Le Taux de Qualité « Tq » (ratio entre le nombre de pièces non défectueuses et le
nombre de pièces produites).
Le TRS peut donc être défini comme suit : TRS = Td * Tp * Tq
Qu’est-ce que le TRG ?
L’industrie recourt également au Taux de Rendement Global (TRG) pour piloter sa
performance, correspondant en anglais à l’acronyme TEEP, Total Effective Equipment
Performance. Cet indicateur dont les caratéristiques sont similaires à celles du TRS,
consiste en la multiplication de quatre taux :
• Le Taux de Disponibilité « Td » (capacité de l’unité de production à être utilisée),
• Le Taux de Performance « Tp » (variant en fonction des cadences),
• Le Taux de Qualité « Tq » (ratio entre le nombre de pièces non défectueuses et le
nombre de pièces produites),
• Le Taux de Charge « Tc » (mesure de la charge productive réelle, ratio entre temps
requis et temps d’ouverture).
Le TRG peut donc être défini comme suit : TRG = Td * Tp * Tq * Tc
Apport du TRS à la DSI
L’apport principal de cette approche industrielle est de fournir un système de pilotage
permettant d’appréhender globalement la performance au travers d’un indicateur
synthétique.
L’identification d’un indicateur unique de performance, différencié des indicateurs de
gouvernance existants est jugée comme un apport déterminant au management des
directions informatiques :
• En termes de gouvernance et de communication externe avec les clients, la DSI et
la Direction Générale,
• Entermesdepilotageetdedécisioninternevisantàl’améliorationdelaproductivité,
• En termes de benchmark et de possibilité de se comparer en interne dans le temps,
voire en externe.
Le TRS apporte une aide particulièrement pertinente pour les DSI qui mettent en
œuvre une démarche collaborative DevOps, par l’adoption d’un indicateur commun
entre équipes Etudes et Production habituées à travailler chacune de leur côté en silos
en matière de méthodes, d’outils et de mesure de la performance.

14. Livre Blanc
Follow Us14
Application du TRS à la Digital Factory
Le principe du TRS s’inscrit de manière naturelle en environnement DevOps. En premier
lieu, la mesure est un pilier du mouvement DevOps. En second lieu, le concept de Digital
Factory rejoint la dimension industrielle propre au TRS. Enfin, avec le TRS, l’accent est
mis sur la chaine de delivery logiciel et sur la capacité de la DSI, comme moyen de
production, à allier vélocité et fiabilité.
Plusieurs approches ont été envisagées pour transposer le TRS en environnement
DevOps selon que l’on considère la chaine de delivery logiciel de manière globale ou
par segments. Les travaux du Think Tank Automic présentés dans le cadre de ce livre
blanc, se sont intéressés à l’approche de bout-en-bout du processus (TRS end-to-end)
depuis la validation des demandes (Plan) jusqu’à l’activation du service en production
(Operate).
Il est à noter que d’autres travaux complémentaires ont été menés par Automic pour
mesurer le TRS uniquement sur la partie aval de ce processus (TRS release pipeline).
La méthode pourrait également être appliquée à d’autres segments (gestion des
demandes, synchronisation SPRINT / RELEASE) si ces derniers répondent à des enjeux
et des contraintes prioritaires des organisations.
Plan Code Build Test Release Deploy Operate
TRS
Gestion des demandes
TRS
Synchronisation SCRUM/RELEASE
TRS
Release Pipeline
TRS
end-to-end

15. Livre Blanc
Follow Us15
Chapitre 3 : Implémentation du
TRS en environnement DevOps
La méthode proposée ci-après est issue des premiers cas de mise en œuvre du
TRS. Cette méthode est la capitalisation de retours d’expérience et non un exercice
théorique : à mesure que les membres pionniers trouvaient les moyens d’appliquer le
TRS dans leurs environnements propres, les bonnes pratiques étaient communiquées
au sein de la communauté du Think Tank et des jalons étaient posés pour permettre aux
autres membres de suivre leur trace. En passant par les mêmes étapes, ces membres
ont permis de challenger la méthode et de l’améliorer.
Progressivement, une méthodologie s’est dégagée avec l’objectif affiché de multiplier
les cas d’adoption sur un même périmètre, et d’accélérer le temps de mise en
application. En définitive, l’application de la méthode a permis de constater un gain de
temps important dans la mise en œuvre en évitant pièges et fausses pistes pour aller
droit à l’essentiel.
Cette méthodologie est organisée en 10 étapes, permettant de suivre la progression
des membres de 1 à 10 et d’identifier les blocages. Elle s’est enrichie des feedbacks
des différents groupes de travail pour aboutir à un consensus dans l’identification des
étapes, leur contenu et leur ordre.
Les étapes sont présentées succintement dans le tableau ci-dessous et décrites dans
la suite du document.
Méthode d’adoption du TRS en 10 étapes
Etape 1 Intention
Identifier le besoin d’amélioration de la performance justifiant la
mise en place d’une approche « TRS »
Etape 2
Identification du périmètre
d’application
Identifier précisément le périmètre d’application du TRS et
partager si nécessaire le périmètre en plusieurs lots
Etape 3 Implication
Assurer le bon niveau de sponsorat et mobiliser les parties
prenantes
Etape 4 Partage du vocabulaire
S’assurer que le vocabulaire est compris et partagé pour chacune
des composantes du TRS (disponibilité, performance, qualité)
appliqué au périmètre choisi
Etape 5
Etat des lieux des systèmes
de mesure
Identifier l’aptitude du système de mesure à remonter les
éléments entrant dans le calcul du TRS
Etape 6
Collecte des points de
mesure
Mettre en place les moyens de mesure du TRS à partir de
l’outillage existant
Etape 7 Premières Mesures Produire une première mesure du TRS sur le périmètre choisi
Etape 8 Analyse des gaspillages
Analyser les écarts de performance à partir du TRS et utiliser
l’arbre de gaspillage pour en identifier les causes
Etape 9 Systèmes de Pilotage
Inscrire le pilotage de la performance opérationnelle dans une
démarche d’amélioration continue
Etape 10 Industrialisation
Mettre en place l’organisation et l’outillage permettant de
pérenniser la mesure

16. Livre Blanc
Follow Us16
La méthode proposée n’est pas un cadre normatif, chaque nouvel adoptant pouvant
adapterladémarcheàsoncontexte,àsesspécificités,ainsiqu’àsonsystèmedemesure.
Nous pensons toutefois que les modèles présentés vous permettront de gagner du
temps et que l’application des mêmes principes pourra faciliter la comparaison entre
les organisations adoptant le TRS.
Etape 1 : Intention
La première étape consiste à apporter des éléments de réponse à la question suivante :
Quel objectif recherchez-vous dans la mise en place d’un TRS ?
On cherche ici à identifier et à valider les enjeux opérationnels ou transformationnels
qui seront facilités par cet indicateur. Attention ! On parle bien ici de l’objectif recherché
dans la mise en place du TRS et non de l’objectif recherché dans la mise en place de
DevOps.
Les objectifs suivants sont généralement à l’origine de la mise en place du TRS en
environnement DevOps :
• Partager un indicateur commun entre Dev et Ops,
• Partager de bout-en-bout une même vision de la performance de la chaine de
delivery logiciel,
• Partager des objectifs communs d’amélioration globale,
• Mesurer la performance dans ses différentes dimensions sans la réduire au Time-
to-Market,
• Faciliter l’analyse de la performance et l’identification de leviers d’amélioration
continue,
• Facilier la gouvernance d’un programme de mise en œuvre de DevOps,
• Obtenir une valeur de référence (baseline) et valoriser les bénéfices d’un pilote
DevOps,
• Améliorer la satisfaction client et l’efficience de l’organisation,
• Benchmarker les résultats obtenus en interne ou avec des pairs.
Etape 2 : Identification du périmètre
d’application
A cette étape, il s’agit d’identifier le périmètre pour lequel on mesurera le TRS.
Afin de progresser efficacement, il est conseillé de partager le périmètre d’application
en plusieurs lots.

17. Livre Blanc
Follow Us17
Ces lots peuvent être a minima :
• Un lot « pilote » correspondant à un périmètre restreint, qui permettra de tester
la méthode,
• Un deuxième lot qui peut être le périmètre cible, et où l’on passera en mode
« industriel » avec potentiellement, un outillage plus performant.
Le domaine des applications et portails web a été le pilote le plus fréquemment choisi
pour l’implémentation du TRS en environnement DevOps. Le TRS a pu également être
généralisé sur l’ensemble des domaines applicatifs dans le cadre d’un programme de
transformation DevOps.
Etape 3 : Implication
Il s’agit à ce stade de s’assurer du bon niveau de sponsorat et de mobiliser les parties
prenantes. Le niveau d’implication dépendra bien entendu de l’approche adoptée
(expérimentation par un opérationnel, déploiement par une entité transverse) et de
l’avancement du projet.
Dans un premier temps, il convient de s’assurer d’avoir :
• Identifié le niveau de sponsorat,
• Justifié de l’approche et de l’investissement,
• Obtenu validation de la démarche.
Il est fondamental d’impliquer les Etudes et la Production dès le début. Constituer un
binôme avec un manager Dev et un manager Ops en co-responsabilité du sujet s’est
révélé être très efficace pour conduire le changement. Le sujet peut également être
porté uniquement par un responsable Dev ou un responsable Ops à condition de s’être
assuré du soutien de l’autre partie prenante. La présentation de la présente méthode en
10 étapes lors de sessions d’information a permis de familiariser les organisations avec
le concept et d’accélérer son appropriation.
Par ailleurs, il faut s’assurer que les personnes amenées à mettre en place le TRS et les
leviers d’amélioration associés sont disponibles a minima. Le nombre de personnes à
impliquer est fonction :
• Du périmètre d’application (cf. Etape 2),
• De la difficulté à mesurer,
• Du niveau d’industrialisation souhaité pour la mesure,
• Du temps dont on dispose pour mettre en place la mesure.

18. Livre Blanc
Follow Us18
Etape 4 : Partage du vocabulaire
Avant de commencer à définir et mesurer les différents taux du TRS et du TRG, Il
faut s’assurer que le vocabulaire est bien compris et partagé pour chacune des trois
composantes de l’indicateur de TRS (Disponibilité, Performance, Qualité) et chacune
des quatre composantes de l’indicateur de TRG (Charge, Disponibilité, Performance,
Qualité).
Ces notions sont ici utilisées dans leur définition industrielle. L’application à DevOps du
TRS et/ou du TRG nécessite de s’accorder sur ce que sont la Charge, la Disponibilité
et la Performance de la chaine de delivery elle-même (l’efficacité opérationnelle des
activités) et ce qu’est la Qualité en bout de cette chaine de production (ce qui est
produit).
Une traduction de ce vocabulaire industriel appliqué à la chaine de delivery logiciel est
proposée ci-dessous :
• Charge : Utilisation efficiente des ressources,
• Disponibilité : Disponibilité de la plateforme ou des environnements à chaque étape,
• Performance : Ponctualité des Mises en Service par rapport à la date prévue,
• Qualité : Niveau de qualité d’expérience utilisateur et de respect des exigences
non-fonctionnelles des packages livrés en production.
Le schéma ci-dessous associe les différentes composantes du TRS et du TRG aux
différentes étapes d’une chaine de delivery logiciel et aux différents niveaux d’activités
(applicatif, plateforme, infrastructure) qui y contribuent. La qualité apparait bien
comme la qualité du produit en bout de chaine. A l’inverse, la Charge, la Disponibilité et
la Performance mesurent l’efficacité de l’ensemble de la chaine à un niveau d’activité
donné.
Agile Coding Cont. Integration Cont. Delivery Cont. Deployment
Application-
level
Activities
Performance
Plateform-
level
Activities
Disponibilité
Infra-
level
Activities
Charge
Qualité

19. Livre Blanc
Follow Us19
Ce sont ces définitions qu’il convient de partager avec les équipes Etudes et Production.
IlnefautpasconfondrecesnotionsaveclesnotionshabituellesdeCharge,Disponibilité,
Performance et Qualité telles qu’elles sont utilisées dans l’informatique. Au contraire, il
faut regarder ces notions avec un regard neuf et définir quels critères représentent le
mieux, dans son environnement DevOps propre, les différents axes constitutifs du TRS
et/ou du TRG.
Etape 5 : Etat des lieux du système de mesure
Cette étape identifie l’aptitude du système de mesure à remonter les éléments entrant
dans la mesure du TRS. La réponse à cette question doit tenir compte de la capacité à
mesurer simplement ces différentes composantes.
Pour cela, chaque organisation peut s’appuyer sur la check-list présentée dans la figure
ci-dessous. Cette check-list est un outil permettant de choisir parmi dix indicateurs
proposés les mesures qui sont les plus pertinentes et les plus faciles à obtenir dans un
contexte donné. Dans un premier temps, il suffit de cocher au moins un indicateur par
composant. Le taux de Charge n’est utile que pour les organisations souhaitant mesurer
le TRG. Le taux de Qualité sera d’autant plus équilibré qu’il associera un indicateur
correspondant aux exigences non fonctionnelles et un indicateur correspondant à
l’expérience utilisateur.
Taux de
Performance
Taux de
Disponibilité
Taux de
Charge
Taux de
Qualité TRG
Taux de
Performance
Taux de
Disponibilité
Taux de
Qualité TRS
Utilisation
efficiente des
ressources
C1 - Taux
d’utilisation des
ressources /
plateformes
Exigeances non
fonctionnelles
Q1 - Qualité du
code
Q2 - Préparation
de la MEP
Expérience
utilisateur
Q3 - Performance
applicative
ressentie par
l’utilisateur
Q4 - Incidents
suite à MEP
Disponibilité de la
plateforme à
chaque étape
D1 - Rapidité de
mise à
disposition des
environnements
D2 - Disponibilité
des
environnements
Ponctualité des
Mises en
Production
PA - Respect des
dates de MEP
P2 - Cadence des
MEP par
rapports aux
spints
P3 - Profondeur
des décalages de
date de livraison

20. Livre Blanc
Follow Us20
Un bref descriptif des indicateurs de la check-list est présenté dans le tableau ci-
dessous :
Une fois les indicateurs choisis dans la check-list, les questions suivantes doivent être
considérées :
• Pouvez-vous mesurer chacun des taux définis ?
• Quels sont les points de mesure ?
Indicateurs de la check-list Descriptif
C1. Taux d’utilisation des ressources /
plateformes
Mesurer le taux d’utilisation des ressources pour valider le bon
dimensionnement des ressources des environnements de la
chaine de production DevOps.
D1. Rapidité de mise à disposition des
environnements
Mesurer le taux des demandes d’environnement traitées en
respectant l’accord de service. L’enjeu est d’accélérer les temps
de déploiement des environnements et de réduire le délai de
prise en charge des demandes d’environnement.
D2. Disponibilité des environnements
Mesurer le taux de disponibilité des environnements, obtenu en
divisant la durée durant laquelle l’environnement est opérationnel
par la durée totale durant laquelle on a exprimé un souhait qu’il le
soit (hors plage de maintenance convenue au préalable).
P1. Respect des dates de MEP
Mesurer le nombre de MEP à date prévue par rapport au nombre
total de MEP pour valider la capacité de l’organisation DevOps à
accélérer le Time to Market.
P2. Cadence des MEP par rapport aux
sprints
Mesurer la capacité des organisations à synchroniser SPRINT et
RELEASE en suivant le rapport du nombre de MEP / nombre de
Sprints.
P3. Profondeur des décalages de date de
livraison
Identifier les écarts de livraison en nombre de jours par rapport à
la date de livraison initialement prévue.
Q1. Qualité du code
Evaluer la qualité du code pour pouvoir mesurer la dette
technique en s’appuyant sur la méthode SQALE.
Q2. Préparation de la MEP
Mesurer la qualité de la préparation des MEP selon 4 axes :
- l’anticipation des besoins d’infrastructures,
- l’anticipation des besoins d’exploitation,
- la bonne mise en place d’un PCA et/ou PRA,
- la bonne mise en place de la supervision.
Q3. Performance applicative ressentie
par l’utilisateur
Evaluer la performance applicative ressentie par l’utilisateur -
Mesure de la satisfaction de l’utilisateur en fonction des temps
de réponse d’un ensemble de requêtes sur une période de temps
donnée (cf. Application Performance Indexer - http://www.apdex.
org).
Q4. Incidents suite à MEP
Mesurer l’impact des MEP sur la qualité de service en suivant le
rapport du nombre d’incidents post MEP / nombre d’incidents
moyen.

21. Livre Blanc
Follow Us21
• Où se trouve la donnée relative à ces points de mesure (solution/outil, …) ?
• Quelle est la fiabilité de cette donnée ? Dispose-t-on de suffisamment de points
de mesure ?
• Quelle est la fréquence de mise à jour de cette donnée ? Quelle en sera la
fréquence de mesure ?
• Par quel moyen de collecte (automatique, manuelle, …) pouvez-vous récupérer
cette donnée ?
• Quelle équipe / personne en a la responsabilité ?
Le tableau ci-dessous présente un modèle simple qui peut être utilisé pour présenter
les réponses à ces questions.
Etape 6 : Collecte des points de mesure
Dans cette étape, les moyens de mesure du TRS sont mis en place : paramétrage de
nouveaux rapports, mise en place de traçabilité, etc.
Compte tenu des contraintes liées au système de Mesure, il est in fine nécessaire
d’identifier,pourchaquecomposant,lesdonnéesetlesformulesdecalculcorrespondant
au mieux à la définition de celui-ci.
Les discussions communes entre Dev et Ops sur les points de mesure sont un bon
moyen de constater les manques et les doublons, les erreurs et les opportunités.
Dans un premier temps, une mesure en première approximation s’avère généralement
suffisante.
QUALITE PERFORMANCE DISPONIBILITE
Mon TRS
Taux de Qualité : Nombre
d’incidents en période de
Vérification de Service
Régulier (VSR) post MEP
Taux de MEP à date prévue
Taux de Disponibilité des
environnements de Dev /
Recette
Données
Nombre de tickets > au
nombre de tickets moyen sur
2 jours après les MEP
Nombre de MEP planifiées
réalisées à date / mois
Durée d’indisponibilité /
mois
Acteurs Equipe Support (Outil ITSM) Equipe Dev (Outil ALM) Equipe Ops (Supervision)

22. Livre Blanc
Follow Us22
Etape 7 : Premières mesures
Une première mesure du TRS est produite.
Dans un premier temps, une mesure permettant une première approximation des
indicateurs peut suffire. Ce qui importe, c’est de fédérer les personnes autour d’une
démarche et de progressivement affiner et automatiser la mesure (cf. étapes suivantes).
Nouspréconisonsdoncdecommencerlecalculetl’analyseduTRSmêmesitouteslesdonnées
ne sont pas disponibles, ou qu’elles n’ont pas encore le « niveau de précision » souhaité.
Dans certains cas, des données sur les derniers mois ou les dernières semaines sont
disponibles dans les systèmes de mesure. Dans ce cas, calculez le TRS a posteriori
sur les derniers jours / semaines / mois afin de voir si le TRS est stable ou s’il varie en
fonction de la période.
Etape 8 : Analyse des gaspillages
Le but ultime du TRS n’est pas de mesurer mais bien d’analyser la performance et de
rentrer dans une démarche d’amélioration continue.
L’atelier « arbre des gaspillages » présenté ci-après est une manière pragmatique
d’initier un telle analyse en trois phases :
• Identifier les gaspillages, c’est-à-dire les causes de défaillance potentielles des
Taux élémentaires du TRS : Performance, Disponibilité, Qualité,
• Identifier les leviers d’amélioration, c’est-à-dire les moyens d’action potentiels qui
permettent d’agir sur les causes des gaspillages,
• Identifier les indicateurs d’amélioration, c’est-à-dire les moyens de contrôle qui
permettent de s’assurer que nous avons bien agi sur les causes au moyen des leviers.
Une fois l’analyse terminée, des actions d’amélioration (leviers) seront implémentées, et
leur effet sur les activités sera contrôlé / mesuré.
L’atelier « TIMWOOD » est une approche complémentaire à l’atelier « arbre de gaspillages
» en ce qui concerne la première phase d’identification des gaspillages.
MOIS TAUX DE QUALITE
TAUX DE
DISPONIBILITE
TAUX DE
PERFORMANCE
TRS
Avril 90% 80% 81,25% 58,5%
Mai 95% 90% 87,65% 74,94%
Juin 95% 85% 97,65% 78,85%

23. Livre Blanc
Follow Us23
Atelier Arbre des Gaspillages
L’arbredesgaspillagesestunebonnepratiqueissuedumondeindustriel.Lesgaspillages
sont pré-cartographiés, et associés a priori à chaque dimension du TRS. L’arbre facilite
l’identification des gaspillages et l’exhaustivité de l’identification. Il permet d’analyser le
travail et de comprendre les obstacles qui empêchent d’accomplir le travail au rythme
voulu.
TRS Disponibilité
Qualité
Performance
Composant
Savoir-faire
Synchronisation
Planning / Ordonnancement
Capacité
Pannes Techniques
Attentes
Arrêts (humain)
Approvisionnements
Méthode
Procédures
Surconsommation
Productivité
Rapidité
Facteur humain

24. Livre Blanc
Follow Us24
La réussite d’ateliers d’amélioration s’appuyant sur l’arbre des gaspillages repose
principalement sur les participants et l’interactivité des échanges. Ces ateliers
d’amélioration ont une durée de deux heures et ont pour but :
• D’impliquer les acteurs et de les sensibiliser au calcul de l’indicateur et à son
utilisation,
• De définir le système de mesure qui permet de calculer cet indicateur et de mettre
en place les premières mesures,
• D’identifier les gaspillages et les leviers d’amélioration,
• De suivre la mise en place des leviers d’amélioration et l’évolution du TRS dans le
temps.
L’atelier d’amélioration est piloté par le responsable de la mise en place du TRS. Les
participants à l’Atelier sont les personnes qui mesurent le TRS, accompagnées de deux
ou trois personnes qui travaillent sur le processus mais qui ne mesurent pas. Elles n’ont,
de ce fait, pas été associées préalablement à la démarche. Ces deux ou trois personnes
vont donc avoir un angle d’approche légèrement décalé par rapport au reste du groupe,
ce qui peut être bénéfique dans l’apport de solutions. Le déroulement type d’un atelier
d’amélioration est décrit ci-après.

25. Livre Blanc
Follow Us25
Déroulement type d'un atelier d'amélioration
2nde
identification des gaspillages
(avec l’arbre des gaspillages)
Objectif : Utiliser l’arbre des gaspillages IT pour
consolider la liste des gaspillages identifiés
Corréler les gaspillages identifiés pendant l’Atelier
avec les natures de gaspillages présentés sur
l’arbre
Susciter de nouvelles propositions
Partage des premières mesures
Objectif : Partager une vision objective de la
Performance (factualiser)
Présenter le TRS global, accompagné des Taux
obtenus pour la Disponibilité, la Qualité, et la
Performance
Rappeler les grands principes de base appliqués
pour le calcul de ces trois taux afin que les
participants qui ne mesurent pas comprennent ce
que représentent ces résultats.
Introduction
Objectif : Rappeler l’enjeu de l’Atelier
Les difficultés perçues sur le processus,
L’intérêt de mettre en place un TRS et les gains
escomptés,
L’intérêt de définir collégialement les gaspillages et
les améliorations, en associant les acteurs du
processus
1ère
Identification des gaspillages
(sans l’arbre des gaspillages)
Objectif : Apporter des réponses par le biais
d’échanges interactifs, où chacun s’exprime
librement par rapport à son expérience.
Commencer par l’axe dont le taux est le plus en
retrait (la Qualité par exemple). Quelles sont les
raisons pour lesquelles la Qualité est insuffisante ?
Continuer axe par axe en suivant cet ordre de
priorité
Parmi les réponses apportées, certaines peuvent
concerner un autre axe. Peu importe, la proposition
est notée pour être abordée un peu plus tard,
lorsque l’axe en question sera étudié.
Identifier les leviers d’amélioration
Objectif : Définir un plan d’actions prioritaires
Identifier une ou plusieurs actions pour chaque
gaspillage
Répertorier les quick-wins en fonction de la
complexité de mise en œuvre de chaque action et
de la plus-value apportée
Proposer un premier plan d’amélioration (la
finalisation et la mise en œuvre nécessiteront des
réunions complémentaires)

26. Livre Blanc
Follow Us26
Atelier TIMWOOD
Une approche alternative consiste à organiser un atelier d’identification des
gaspillages en s’appuyant sur la méthode TIMWOOD, issue du Lean Management.
Le Lean Management suggère en effet, pour optimiser les processus de l’entreprise
et créer efficacement de la valeur, d’identifier systèmatiquement toutes les sources
de gaspillages afin de les éliminer ou les réduire. L’industrie distingue sept types de
gaspillages appelés Muda. L’acronyme TIMWOOD correspond en anglais aux initiales
de ces sept gaspillages.
Cette méthode a été appliquée par les membres du Think Tank pour identifier les
gaspillages au sein du flux DevOps “Idea to Production”. Le résultat de l’atelier est
illustré en page suivante.
TIMWOOD
Transportation
Fait référence aux déplacements des produits finis ou semi-finis soumis à des
risques de détériorations, de pertes, de délais supplémentaires et de charges de
travail supplémentaires.
Inventories
Fait référence aux stockages intermédiaires et aux inventaires effectués en
cours de processus. Ceux-ci ne contribuent pas à la transformation du produit
et générent des surcoûts n’apportant aucune valeur ajoutée.
Motion
Fait référence aux déplacements inutiles des moyens humains et matériels
en cours du processus de fabrication et qui peuvent avoir des impacts de
détérioration, d’usure et de sécurité inutiles.
Waiting
Fait référence au temps d’attente de l’activité ou de la tâche suivante pour les
produits ou services qui ne sont pas en cours de transport, de fabrication ou de
transformation dans leur processus.
Over-production
Fait référence à la surproduction de produits fabriqués par rapport à la demande
/ commandes clients.
Over-processing
Fait référence aux activités et tâches inutiles et/ou qui n’apportent pas de
valeur ajoutée au client ainsi qu’aux outils d’utilisation (logiciels, procédures,
instructions de travail) qui sont trop précis, trop complexes, ou plus coûteux
que nécessaire.
Defects
Chaque fois que des défauts et rejets des produits finis et semi-finis arrivent, des
coûts supplémentaires sont supportés pour retravailler les produits, détruire les
défectueux, reprogrammer la production, ...

27. Livre Blanc
Follow Us27
Le Lean Management suggère, pour créer efficacement de la valeur, d’identifier les sources de gaspillages et de les
éliminer ou les réduire afin d’optimiser les processus de l’entreprise. L’industrie distingue 7 types de gaspillages issus
de la méthode Lean et appelés Muda qui peuvent être transposés en DevOps selon le moyen mnémotechnique
TIMWOOD.
• Incapacité du modèle de transport des packages applicatifs à atteindre les
objectifs de volumétrie, fréquence, délai et productivité
• Inaptitude de fournisseurs de code (ex. TMA) à s’aligner sur les objectifs
• Hétérogénéité des outils et procédures utilisées, nombreuses tâches manuelles
• Surcapacité des environnements hors production
• Environnements créés mais non utilisés ou non décommissionnés
• Environnement de développement ou de tests surdimensionnés
• Doublonnement et non fiabilité des référentiels nécessaires au fonctionnement
de la chaine d’automatisation
• Chaqueoutil,chaqueéquipedelachaînededéploiementpossèdesonréférentielpropre
• Les référentiels des versions applicatives et des infrastructures ne sont pas à jour
• Hétérogénéité des pratiques agiles des équipes de développement impliquant
une perte d’efficacité aux interfaces avec la production et les métiers
• Impossibilité pour les équipes Ops d’industrialiser leurs activités
• MOA et Métiers en décalage avec ces pratiques
• Réalisation de tâches humaines répétitives et systèmatiques
• Tests (non regression, performance, techniques)
• Déploiementsapplicatifs,miseàdispositiondesenvironnements
• Mobilisationexcessivedescontributeursparmanquedecapitalisationdel’information
• Allers-retours entre équipes de développement et métiers pour qualifier le besoin
• Réunions d’analyse d’impact et de validation
• Mauvaise priorisation : les fonctionnalités à forte valeur ajoutée attendent la fin du
développement des stories moins critiques
• Membresducomitédepriorisationnonreprésentatifs,manquedeconnaissancedumétier
• Retard dans la mise à disposition d’environnements de recette ou de production
• Manque d’anticipation, de communication et d’automatisation du provisionning
• Fonctionnalités validées en attente de mise en production
• Les packages attendent une fenêtre de livraison
• Un ou plusieurs incidents en cours bloquent toute mise en production
• Blocage de l’ensemble d’une mise en production en raison d’éléments défectueux
• Manque de réactivité aux étapes clés du cycle de développement
• Sprint reviews, recette fonctionnelle, validation
• Manque de disponibilité des équipes métiers, des experts, du management
• Fréquence de livraison non alignée avec les besoins réels du métier
• Livraison applicative trop fréquente sans valeur pour le métier
• Fréquence de livraison trop basse impactant le business des métiers
• Gestion des changements et gestion des projets trop bureaucratiques
• Automatisation locale n’améliorant pas la performance de bout-en-bout
• Automatisation avancée de l’intégration continue alors que la contrainte est sur
les tests ou le déploiement
• Mise à disposition de fonctionnalités non demandées
• Miseàdispositiondefonctionnalitésdemandéesnecorrespondantpasàunbesoinréel
• Rédaction de documentations utilisateur qui ne sont pas lues
• Blocage de production avec impact sur les clients finaux
• Régression majeure non identifiée lors de l’analyse d’impact du changement
• Erreur manuelle lors du déploiement
• Régressionsfonctionnellesdansl’applicationmiseàjouroudanslessystèmesconnexes
• Introduction d’une dette technique générant un surcoût de maintenance
• Non respect des exigences non fonctionnelles
T ransportation
M otion
O verprocessing
I nventories
W aiting
O verproduction
D efects
Lean IT : Cartographie des Gaspillages
DevOps
automic.com

28. Livre Blanc
Follow Us28
Etape 9 : Système de pilotage
Il convient à ce stade de définir et mettre en place les modalités et les instances de
gouvernance associées au TRS :
• Répondant à l’intention initiale de pilotage de la Performance (cf. Etape 1),
• Conforme à la culture de pilotage de l’organisation.
Cette étape vise à s’assurer qu’un certain nombre de préalables sont rassemblés pour
que l’analyse de cause s’inscrive dans une boucle d’amélioration continue efficace :
• Inscrire la démarche dans un cadre de pilotage de la Performance,
• Identifier un sponsor et mobiliser les ressources nécessaires,
• Partager le vocabulaire et former les contributeurs de la démarche aux nouveaux
concepts,
• Communiquer sur les modalités de mise en œuvre et les résultats attendus.
Le sponsor de l’initiative devra clairement établir la cible de l’amélioration de la
Performance attendue ainsi que le périmètre des acteurs et contributeurs concernés
(organisation interne, infogérants, tiers identifiés, etc.).
La conduite du changement peut s’effectuer à travers des séances de sensibilisation à
la démarche, des formations à partir de cas concrets. Le mode de pilotage ciblé est à
expliciter versus une démarche classique selon les objectifs poursuivis : partage d’un
objectif d’amélioration continue commun, mesure de l’efficacité opérationnelle, etc.
Des objectifs peuvent être également fixés aux contributeurs de la démarche en
terme d’amélioration du TRS et ce afin de renforcer l’intégration de ces pratiques
dans les activités courantes. Différentes modalités de pilotage sont présentées ci-
après au travers de différents cas. Ces cas illustrent différentes orientations que peut
recouvrer le pilotage de la Performance à travers l’utilisation du TRS. Par ces différents
exemples, on constate que le TRS peut être utile dans le pilotage d’une ou plusieurs
entités opérationnelles, d’un ou plusieurs fournisseurs, d’un ou plusieurs streams. Le
point commun à ces différents systèmes est d’inscrire le pilotage de la Performance
opérationnelle dans une démarche d’amélioration continue.

29. Livre Blanc
Follow Us29
Etape 10 : Industrialisation
L’Industrialisation consiste à mettre en place l’organisation et l’outillage adapté à la
collecte et au traitement des données.
Elle se justifie :
• Lors d’une extension de périmètre : passage du périmètre pilote au périmètre cible,
• Et/ou si la pérennisation de la mesure a été actée, l’objectif étant d’inscrire le TRS
dans une gouvernance ad hoc ou préexistante.
L’organisation comprend :
(1) Un responsable du TRS, clairement identifié dont la mission est de :
• Veiller à la réalisation des mesures selon la fréquence convenue et à la publication
du tableau de bord,
• Animer l’identification de leviers potentiellement nécessaires en cas de dérive du
TRS,
Intention initiale Culture de pilotage
Cas 1 :
Atelier d’Amélioration
Améliorer l’efficacité opérationnelle
d’un projet pilote DevOps incluant Dev
et Ops
Culture de l’amélioration continue
encourageant la prise d’initiative
Cas 2 :
Organisation en
domaines applicatifs
Améliorer le pilotage des différents
domaines en utilisant des indicateurs
de progrès
Gouvernance centralisée en charge du
pilotage de la performance
Cas 3 :
Programme de
transformation
Fédérer les différents streams d’un
programme de transformation DevOps
autour d’objectifs de progrès partagés
Revues individuelles des objectifs des
streams mais difficulté à démontrer
l’efficience globale de la démarche
Cas 4 :
Relation avec les sous-
traitants et partenaires
Piloter les actions d’amélioration
des fournisseurs en mesurant leur
contribution à la performance
d’ensemble
Comités stratégiques et comités de
pilotage sur la base d’engagements
contractuels

30. Livre Blanc
Follow Us30
• Contrôler l’application des leviers d’amélioration définis,
• Exprimer les éventuels besoins liés à un outillage plus automatisé pour la mesure.
(2) Une ou plusieurs équipes impliquées dans la mesure (collecte et traitement),
l’analyse et l’arbitrage.
L’outillage adapté à la collecte et au traitement des données peut s’appuyer sur :
• Les systèmes de métrologie existants (ex. BI),
• Les systèmes de métrologie propres à des outils spécifiques au périmètre
cible (ex. APM, Qualité de Code, Release Automation, Orchestration, IT Service
Management, etc...),
• Les outillages internes à une entreprise basés sur des tableurs ou des bases de
données.
Le tableau ci-dessous propose une typologie d’outils sources permettant de recueillir
les données nécessaires au calcul du TRS et du TRG :
Pour terminer, le TRS peut être utilisé à des fins de benchmark. Dans ce cas précis,
l’industrialisation doit prévoir de normaliser les mesures et d’obtenir des valeurs qui
pourront être comparées entre pairs. L’usage d’outils partagés peut faciliter cette
démarche.
CHARGE DISPONIBILITE PERFORMANCE QUALITE
• Capacity Management
• Performance
Management
• Monitoring
• Service Request
Management
• Orchestration
• Release Management
• Release Automation
• Incident Management
• Code Quality
• Application Performance
Management

31. Livre Blanc
Follow Us31
A propos du Think Tank Automic
Créé en 2010, le Think Tank Automic est un groupe de réflexion constitué d’une
vingtaine de décideurs informatiques issus de différents secteurs d’activités, privés ou
publics, et consacré au pilotage de la performance.
En 2011, le Think Tank Automic met l’accent sur un indicateur innovant issu des
méthodes industrielles : le Taux de Rendement Synthétique (TRS).
En 2012, les membres passent de la théorie à la pratique et appliquent le TRS dans
leurs organisations : mesure et pilotage, normalisation des concepts et identification
de nouveaux besoins.
En 2013 et 2014, le Think Tank étend la communauté d’adoption de l’approche TRS
et propose un guide pratique d’implémentation du TRS incluant fiches pratiques et
méthodologie.
En 2015 et 2016, le groupe propose de mobiliser les équipes Etudes et Production
autour d’un même objectif en transposant à DevOps le Taux de Rendement Synthétique
(TRS). Le résultat de ces travaux est présenté dans ce nouveau guide “Quelle métrique
pour fédérer Dev & Ops ?”.

32. Pour plus d’information ou démonstration des solutions Automic, visitez notre site www.automic.com
Automic, leader de l’Automatisation des processus d’entreprise, aide les organisations à gagner en
compétitivité en automatisant leur informatique d’entreprise, de l’hébergement sur site au Cloud, en
passant par le Big Data et l’Internet des Objets. Avec ses bureaux dans le monde entier, le groupe
soutient les activités de 2 600 clients parmi lesquels Bosch, Netflix, eBay, AMC Theatres, Carphone
Warehouse, ExxonMobil, BT Global Services, Société Générale, NHS SBS, General Electric et Swisscom.
Automic est une société privée détenue par EQT. Pour plus d’informations : http://www.automic.com/fr
A propos d’Automic Institute
Automic Institute a pour mission de promouvoir l’expertise du groupe Automic en
s’appuyant sur l’ensemble des savoirs de l’entreprise pour partager convictions,
connaissances et expériences en Management des Opérations Informatiques.
• Les Publications alimentent la communauté des managers des Opérations
Informatiques en faits et en opinions,
• Les Communautés et Think Tank sont des réunions de décideurs informatiques
décidés à faire émerger les idées qui seront la réalité de demain en matière de
Management des Opérations Informatiques,
• Les Trivial Pursuit™ Edition IT sont des outils pédagogiques innovants pour
sensibiliser les équipes informatiques : Lean IT, Cloud, Management de Projet,
ITIL®, …
Contacter Automic
Automic
Tour Pacific
11, cours Valmy
92800 Puteaux, France
Web
www.automic.com