Embed Size (px)
Citation preview
TRANSFORMATION DEVOPS
QUALITE DEVOPS
Comment réussir les fonctions devops
Table des matières 3
Résumé décideurs 5
Enjeu et plan 7
1. Comprendre la situation 9
2. Comprendre la solution 17
3. Réussir une fonction devops 23
4. Complément : devops 35
Le Portefeuille d’EtudesLes solutions sur les sujets de fond à l’attention des décideurs, managers et cadres
Recherche appliquée indépendante MOe et MOa en informatique d’entreprise
Yphise Nous voulons réussir le défi de l’informatique agile
Transformationdu travail
Investissementagile
Transformationdevops
Transformationdigitale
Gouvernanceinformatique
« Je suis fascinée par la puissance de ce quin’a pas de forme : le vent, l’eau et la pensée »
Anita Conti
Anita Conti est à la fois aventurière, océnanographe et femme de lettres du XXème siècle.
Toute organisation est confrontée à des enjeux de changement qu’elle a du mal à réaliser, tant
freinent le quotidien, les habitudes, les situations établies, l’usure du temps et les craintes.
Pour réussir l’action, il faut d’abord une pensée qui établit une vision et réfléchit les moyens de sa
concrétisation.
Anita Conti nous rappelle à juste titre à quel point une pensée puissante peut faire bouger les choses.
Elle nous suggère aussi que sans cette pensée, l’effort sera vain ; que comme le vent et la mer
peuvent aussi ravager, la pensée mal construite détruit.
Une pensée forte et construite, qui sait articuler en intelligence fins et moyens, est une condition
indispensable à la réussite de l'action en entreprise.
A l’inverse, une pensée stéréotypée n’est pas étrangère à nombre de difficultés.
Construire cette pensée nécessite du recul et du temps, largement inaccessibles au décideur,
manager ou cadre dans l’exigence de l’opérationnel. Le Portefeuille d’Etudes vous accompagne en
réalisant pour vous ce travail.
Ce que nous essayons de faire à chaque étude tient en quatre points.
− La réflexion de fond dont les managers et cadres ont besoin, sans avoir le temps de la mener.
− Les messages et solutions les plus simples, sans être plus simples que la complexité du réel.
− L’action opérationnelle en entreprise, sans débat théorique ou conceptuel inutile.
− Une dynamique de collaboration entre MOe et MOa, et entre les métiers d’une MOe.
www.yphise.com > le Portefeuille d’EtudesDirecteur : Xavier Flez
60 rue de la Folie Regnault - 75011 Paris - [email protected]
Septembre 2020
Table des matières
Classement principal sur www.yphise.com
Transformationdevops
Résumé décideurs 5
Enjeu et plan 7
1. Comprendre la situation
1.1 L’enjeu 10
1.2 La solution de base 12
1.3 Les fragilités 14
2. Comprendre la solution
2.1 Préalable 18
2.2 Une fonction devops 20
2.3 Les fonctions devops 22
3. Réussir une fonction devops
3.1 Le business case 24
3.2 Le propriétaire de produit 26
3.3 La recette devops 29
3.4 Le banc d’essai 32
4. Complément : devops
4.1 Un mot valise 36
4.2 Les principes devops 37
4.3 Les composantes du banc d’essai 38
Chaque étude est rédigée pour être accessible à tout cadre, manager ou décideur en informatique, maitrise
d’œuvre (MOe) ou d’ouvrage (MOa), indépendamment de sa spécialité ou de sa responsabilité du moment.
Cette ouverture est une clé du développement professionnel de chacun et de la réussite collective.
Synopsis thématique
Principaux sujets abordés et niveau.
Devops Les clés de la maitrise.
Nous recommandons de ressortir cette étude sur www.yphise.com en cas d’utilisation
plusieurs mois après sa date de parution : elle peut avoir fait l’objet de corrections ou
de petites modifications, notamment liées à des évolutions du Portefeuille.
Version 1.0
5 © Yphise
Résumé décideurs
La problématique devops a été un sujet important de la fin de la décennie 2010 :
comment maitriser des mises en production fréquentes de changements d’envergure
limitée sur des applications ; c’est-à-dire dans une logique d’adaptation rapide
d’applications.
Le constat courant sur les applications évoluant ainsi est d’une qualité insuffisante au
sens de la satisfaction de l’utilisateur, qu’il soit collaborateur, partenaire, client ou
autres ; avec une tendance à la dégradation de cette qualité dans le temps.
Cette dégradation est notamment liée au laisser-aller d’une époque où l’utilisateur sensé
être au centre des préoccupations, a en fait souvent été vu de manière abstraite :
quelqu’un qui finirait bien par se faire à ce qu’on lui fournit, selon le rythme ou les modes
de la transformation numérique érigée en finalité et écrasant tout sur son passage.
C’est dans cette situation déjà tendue que vient s’inscrire la crise de 2020 amenant son
lot de contraintes économiques. Un point ici essentiel est qu’une crise fait toujours chuter
brutalement et durablement la capacité des utilisateurs à s’approprier des
changements1 : elle renforce leur attente d’avoir des applications ayant des fonctions,
des modes opératoires et une excellence opérationnelle leur donnant pleine satisfaction.
Dit autrement, les utilisateurs veulent plus de qualité.
On est donc face à une situation qui est à la fois explosive et une opportunité majeure.
C’est une situation explosive car une satisfaction de l’utilisateur insuffisante va fragiliser
encore davantage l’activité ou sa capacité à reprendre. C’est à l’inverse une opportunité
car travailler la qualité des applications peut se faire selon une amélioration pas-à-pas
avec des moyens limités, tout en amenant une valeur décisive aux yeux de leurs
utilisateurs.
Accroitre la qualité sur la problématique devops est de fait un sujet hautement
stratégique pour sortir vite et bien d’une crise. Nous insistons : la maitrise opérationnelle
de l’investissement en situation de crise nécessite de remettre la qualité au centre des
enjeux ; la réussite est affaire d’excellence opérationnelle dans l’adaptation
d’applications, c’est-à-dire de fonctions devops robustes.
Et l’essentiel tient en peu de mots. Il s’agit de centrer correctement le rôle de
propriétaire de produit : le passer d’un gestionnaire des changements à un
responsable de la satisfaction de l’utilisateur. Ceci amène en particulier à introduire une
gestion des évolutions du banc d’essai, c’est-à-dire un test backlog. Plus largement, il
faut une boucle d’amélioration rapide qui vise à obtenir les bons signaux d’insatisfaction
des utilisateurs, c’est-à-dire des dispositifs formant une recette devops. Il faut enfin
une gouvernance de l’adaptation rapide, ce qui se fait en l’insérant dans un business
case.
1 Etude « Investir en crise ».
6 © Yphise
Nous vous proposons donc d’entrer dans cette dynamique renouvelée de la qualité qui
constitue aujourd’hui une priorité.
Bonne lecture.
Yphise
Septembre 2020
7 © Yphise
Enjeu et plan
Enjeu
Comment maitriser l’adaptation rapide d’applications, c’est-à-dire la qualité dans un
contexte de mises en production fréquentes de changements d’envergure limitée.
Le constat courant sur les applications évoluant ainsi est de problèmes récurrents de
qualité, avec une tendance à la dégradation dans le temps. Ainsi, de nombreux webs ou
applications mobiles ne satisfont pas leurs utilisateurs, qu’ils soient collaborateurs,
partenaires, clients ou autres. Des activités ou entreprises sont ainsi fragilisées, parfois
de manière explosive : redresser la situation est un sujet hautement stratégique,
d’autant plus qu’une situation économique difficile exacerbe la gravité des risques
d’insatisfaction.
Résultat
La solution est la maitrise de fonctions devops.
Cette maitrise n’est pas très difficile si on centre bien la solution sur les points clés. Mais
ce centrage n’est pas évident : c’est pourquoi nous partons d’une prise de recul sur ce qui
a été en général mis en œuvre, pour distinguer ce qui est valable et mettre le doigt sur
ce qui ne va pas (1. Comprendre la situation).
Ceci permet de mettre en lumière les points essentiels (2. Comprendre la solution) ;
puis de descendre dans ce qu’il est important de comprendre sur chacun pour réussir
l’opérationnel (3. Réussir une fonction devops).
Cette étude ne présuppose pas de connaissances sur devops : un bref complément
fournit ce qui est utile (4. Complément : devops).
Les résultats de cette étude sont présentés de sorte à faire immédiatement ressortir
l’essentiel pour l’opérationnel. Nous avons beaucoup travaillé la simplicité et la rapidité
d’accès aux résultats par l’utilisation systématique de schémas (13 schémas) et un texte
à lire réduit ; un résumé synthétique (encadré rouge) permet un accès immédiat aux
points importants (13 encadrés rouges).
Cette étude fournit aux décideurs et managers de l’informatique la compréhension de
fond pour réussir le sujet hautement stratégique que constitue la qualité devops.
Elle constitue une référence des propriétaires de produit dont le rôle est central.
Elle concerne plus largement tous les professionnels directement concernés par
l’adaptation rapide d’applications, qu’ils soient du côté du développement, des tests ou
de la gestion des environnements.
8 © Yphise
Elle s’adresse au delà aux architectes, aux concepteurs et aux différents centres de
compétences qui ont à intervenir de manière adaptée dans les fonctions devops.
Elle s’adresse en particulier aux professionnels des méthodes de l’informatique qui
doivent apporter la formalisation et le support utiles à la montée en compétences.
9 © Yphise
1. Comprendre la situation
1.1 L’enjeu
1.2 La solution de base
1.3 Les fragilités
Banc
d’essai
Propriétaire de produit
Production
Sprint
demandes de
changement
SprintProduct
backlog
2. Absence derecette
1. Maitrise dubanc d’essai
3. Pilotage desévolutions
Mode produit
La solution de base et ses fragilités
L’adaptationrapide d’applications
10 © Yphise
1. Comprendre la situation
1.1 L’enjeu
1
On est sur une logique d’adaptation rapide d’applications (1) amenant la mise en production
fréquente de changements d’envergure limitée (2).
Cette haute fréquence contraint les tests : elle contrarie la qualité au sens de la satisfaction de
l’utilisateur ; alors même que les applications concernées adressent souvent un large public sans
compétence ou formation spécifique.
2
Production
changements
fréquents
L’adaptationrapide d’applications
! La qualité devops = comment réussir un très haut niveau de qualité dans la durée
Le mot devops désigne une problématique : permettre des mises en production
fréquentes ou très fréquentes de changements d’envergure limitée sur des applications.
Le cœur du sujet est donc d’industrialisation des tests : il faut savoir tester les
changements et leur non régression, avec une durée et une prédictibilité de cette durée
adaptées2.
Nous rappelons que ce problème dérange les savoir-faire traditionnels relatifs à la
maitrise d’une production informatique, avec ses mises en production de releases et ses
campagnes de test longues, selon des processus précis de phases de test et de montées
d’environnement. C’est donc une rupture par rapport à toute la culture ITIL traditionnelle
qui garde par ailleurs sa pertinence. Le sujet est donc intrinsèquement difficile : on
introduit une autre logique qui remet en cause des principes forts, ayant mis longtemps
pour être acceptés, concrétisés et maitrisés.
On a ainsi aujourd’hui des systèmes qui fonctionnent avec des mises à jour fréquentes,
pouvant être quotidiennes ; mais on a un problème de maitrise opérationnelle de ce
mode de fonctionnement.
L’effet immédiat est une qualité insuffisante, au sens de la satisfaction de l’utilisateur.
Tout le monde a ainsi l’expérience de désagréments à l’utilisation de webs donnant
l’impression que l’application n’a pas été testée tant le point est évident. Ces
désagréments peuvent être des dysfonctionnements (des fonctions qui ne fonctionnent
pas), mais aussi des choses qui paraissent compliquées ou en dépit du bon sens. Le
problème est que le résultat est le même : une insatisfaction de l’utilisateur.
2 Chapitre ‘4. Complément : devops’.
11 © Yphise
Cette qualité insuffisante est d’autant plus grave que les applications concernent des
utilisateurs en grand nombre, non formés et non supportés (clients, collaborateurs ou
autres). Il est utile de noter ici un point aberrant : on avait dans le passé des processus
de test systématiques et longs pour mettre en production des applications utilisées par
un nombre limité de salariés formés et supportés ; on est passé à des modes opératoires
beaucoup plus frustres alors que le besoin de qualité a monté sur des applications
s’adressant à un large public, sans compétence ou formation spécifique.
Le manque de maitrise amène également un vieillissement accéléré des applications, qui
se traduit par une difficulté croissante pour assurer la non régression.
Au final, tout cela amène des frustrations et des conflits au niveau des équipes
informatiques. Ils sont d’autant plus profonds que la culture ITIL traditionnelle a été bien
assimilée.
Mais la logique d’adaptation rapide d’applications amenant la mise en production
fréquente de changements d’envergure limitée est devenue incontournable (ce qui ne
signifie pas qu’elle soit partout pertinente). Il faut donc monter en compétences pour
atteindre la qualité voulue. Nous allons voir que cette montée en compétences ne
s’improvise pas : la bonne volonté des équipes ne suffit pas ; il faut des dispositifs précis
constituant une fonction devops.
Commençons par regarder la solution de base qui a été en général mise en œuvre...
12 © Yphise
1. Comprendre la situation
1.2 La solution de base
1
La solution de base considère l’application comme un produit à adapter sous l’autorité d’un
propriétaire de produit.
Le point critique est la capacité à automatiser les tests ; c’est-à-dire à concevoir un banc d’essai,
ce que l’on ne sait faire que dans des situations précises : des types de changement sur un
périmètre applicatif précis. Un produit se définit par des situations sur lesquelles ont sait monter
un banc d’essai.
2
On adapte une application considérée comme un produit (éventuellement une partie d’une
application ou un regroupement d’applications).
1. Propriétaire de produit (product owner) qui a autorité sur les demandes de changement
(product backlog) pour adapter le produit à la fréquence utile.
2. Sprint : réalisation rapide des développements, selon un mode opératoire pouvant aller de
la modification ponctuelle (à la volée) à l’organisation d’un ou plusieurs sprints.
3. Banc d’essai (ou de test - test factory) automatisant les tests unitaires (sur le périmètre de
développement) et d’intégration (au delà du périmètre de développement), qu’ils soient
fonctionnels ou techniques, sur les nouveaux développements ou la non régression.
Banc
d’essai
Propriétaire de produit
Production
Sprint
demandes de
changement
SprintProduct
backlog
3
Mode produit
La solution de base pour traiter la problématique devops reprend les notions de
propriétaire de produit et de product backlog introduites par Scrum3.
Le propriétaire de produit est un rôle centré sur la gestion des changements à apporter à
l’application ; celle-ci étant considérée comme un produit à adapter avec l’agilité voulue.
Les changements sont définis, calibrés et ordonnés par le propriétaire de produit dans un
product backlog.
La réalisation des développements se fait selon un mode opératoire adapté à leur
envergure : il peut varier d’une petite modification par une personne compétente à
l’organisation d’un ou plusieurs sprints.
3 Etude « Le bon usage de Scrum ».
13 © Yphise
La spécificité liée à devops est l’automatisation des tests vérifiant que le produit
fonctionne correctement avec les modifications apportées. Il s’agit donc de mettre en
place un banc d’essai permettant les tests unitaires et d’intégration utiles, qu’ils soient
fonctionnels ou techniques, sur les nouveaux développements ou la non régression.
La capacité à monter un banc d’essai ayant la couverture nécessaire, avec une durée des
tests et une prédictibilité de cette durée adaptées, conditionne la faisabilité.
C’est précisément la difficulté de cette faisabilité qui amène la notion de produit. On ne
sait pas automatiser les différents types de test sur un système d’information un peu
complexe, pour tout changement quelle qu’en soit la nature ou la profondeur. On est
obligé de restreindre l’ambition à des situations précises : des types de changement sur
un périmètre applicatif précis. Un produit se définit par des situations sur lesquelles on
sait monter un banc d’essai.
Cette solution de base est valable : c’est un bon point de départ, mais elle comporte des
fragilités qu’il faut corriger. Voyons ces fragilités...
14 © Yphise
1. Comprendre la situation
1.3 Les fragilités
Trois fragilités.
1. La maitrise du banc d’essai : on a une problématique d’excellence opérationnelle difficile à
atteindre et à tenir dans la durée.
2. L’absence de recette, alors qu’on est en général dans un contexte où elle s’impose pour
sécuriser la qualité du résultat.
3. L’absence de dispositifs de pilotage et de contrôle : les dérives d’utilisation sont inévitables
amenant une baisse de la qualité.
Banc
d’essai
Propriétaire de produit
Production
Sprint
demandes de
changement
SprintProduct
backlog
2. Absence derecette
1. Maitrise dubanc d’essai
3. Pilotage desévolutions
Mode produit
Il y a toujours une fragilité sur la maitrise du banc d’essai : l’automatisation des tests est
un sujet sur lequel l’informatique bute depuis toujours. Il n’y a aucune percée permettant
sa simplification ou sa résolution de manière générale : on est toujours sur une
problématique d’excellence opérationnelle restreinte à des situations précises.
La solution de base se caractérise par une absence de recette détaillée par des
utilisateurs (user acceptance test), pouvant refuser le résultat jusqu'à obtenir satisfaction
point par point d’une liste de modifications. On perd l’œil de l’utilisateur permettant de
voir des points qui ne sont pas satisfaisants4.
Nous rappelons que les tests unitaires et d’intégration automatisés du banc d’essai
constituent une vérification, à distinguer de la recette qui est une validation : la
4 Ces points ne sont pas forcément des dysfonctionnements, ils peuvent être des désagréments qui amènent
une insatisfaction de l’utilisateur aussi dangereuse : chapitre ‘1.1 L’enjeu’.
15 © Yphise
vérification et la validation sont deux choses distinctes, ce qui est souvent mal compris 5.
Nous insistons sur le côté paradoxal de cette situation. Le développement par sprint est
fait pour donner une liberté d’appréciation à l’équipe de développement sur le résultat à
obtenir6 ; alors que les utilisateurs sont souvent en grand nombre, non formés et non
supportés7. La capacité d’appropriation des utilisateurs est essentielle mais limitée, tandis
qu’on n’a aucune garantie que l’équipe de développement mette précisément l’accent sur
ce qui leur convient : on est dans un contexte où une recette s’impose pour sécuriser la
qualité du résultat.
L’absence de recette constitue donc une fragilité sérieuse.
Enfin, la solution de base ne comporte pas de garde-fou empêchant les dérives dans son
utilisation. Les contraintes de développement et de banc d’essai font qu’on ne peut pas
traiter de cette manière tout changement, quelle qu’en soit la nature ou la profondeur.
Mais la tentation est grande de forcer son utilisation du fait de sa réactivité : les dérives
sont en pratique inévitables.
Ces dérives amènent en outre un vieillissement prématuré du code, qui devient
rapidement compliqué à faire évoluer et à tester en non régression : la qualité diminue.
Il y a donc une fragilité fondamentale liée à l’absence de dispositifs de pilotage et de
contrôle.
Ces fragilités font qu’il faut corriger cette solution de base, amenant l’introduction de la
notion de fonction devops. Voyons comment s’y prendre...
5 La distinction entre vérification et validation est fondamentale et ancienne (notamment ISO 9001). La
vérification se fait par rapport à une spécification du résultat ; la validation se fait sur un besoin : elle adresse
la qualité du résultat au sens de la satisfaction des exigences explicites ou implicites. Les exigences implicites
signifient une absence de spécification du résultat ou un certain flou sur cette spécification ; ce qui est la
situation courante du développement d’applications : il est en particulier habituel que la spécification ne détaille
pas totalement l’interface utilisateur.
6 Un principe fondamental d’un mode de travail agile est de donner une certaine liberté d’appréciation sur ce
qu’il faut obtenir. C’est pourquoi le résultat d’un sprint est défini par un objectif de valeur ; les items du
backlog sont à un niveau d’expression suffisant pour que l’équipe de développement puisse faire preuve
d’initiative au regard des contraintes, de son expérience et de la valeur attendue.
7 Chapitre ‘1.1 L’enjeu’.
16 © Yphise
17 © Yphise
2. Comprendre la solution
2.1 Préalable
2.2 Une fonction devops
2.3 Les fonctions devops
Gouvernance
Système opérationnelGouvernance
Système opérationnelGouvernance
Système opérationnel
Produit X
Produit Y
Produit Z
Les fonctions devops
18 © Yphise
2. Comprendre la solution
2.1 Préalable
La maitrise est affaire d’excellence opérationnelle, donc d’une fonction (un système) robuste
distinguant un niveau opérationnel et une gouvernance.
Gouvernance
Système opérationnel
Fonction
Nous attirons l’attention sur un point clé avant d’entrer dans la correction de la solution
de base.
La maitrise de l’adaptation rapide d’applications ne supporte pas l’à-peu-près. Elle est
affaire d’excellence opérationnelle, donc d’un système de management (au sens ISO
9001) robuste distinguant un niveau opérationnel ( factory) et une gouvernance.
Nous appelons un tel système une fonction d’entreprise : la maitrise consiste donc à
construire une fonction devops reprenant les forces de la solution de base et corrigeant
ses fragilités.
Nous insistons : l’agilité sur de l’excellence opérationnelle nécessite une fonction
d’entreprise solide. Nous savons que cette affirmation est mal perçue des personnes
ayant une compréhension succincte des modes de travail permettant l’agilité8. L’erreur
courante est de considérer que cette agilité est affaire de bonne volonté de
collaboration ; un symptôme est de faire appel à cette bonne volonté de manière
incantatoire à chaque fois qu’une difficulté opérationnelle est rencontrée. Certains parlent
ainsi de culture devops en considérant que l’essentiel se joue sur la bonne volonté ; ce
qui ne permet pas d’atteindre le niveau de qualité nécessaire et de le tenir dans la durée.
Attention : nous ne sommes pas en train de négliger les compétences de collaboration.
Elles forment le socle indispensable lorsque différentes parties prenantes doivent trouver
rapidement des solutions amenant des compromis ou des équilibres : nous insistons
ailleurs sur ce socle9. Mais ces compétences ne sont pas la clé de l’excellence
8 Etude « Le défi de l’informatique agile ».
9 Etude « Pizza team ».
19 © Yphise
opérationnelle : celle-ci nécessite toujours une fonction d’entreprise10.
Voyons donc comment passer de la solution de base à une fonction devops...
10 Pour bien comprendre, prenons l’exemple de l’industrie automobile : deux logiques, l’une d’agilité de
conception d’un nouveau modèle, l’autre d’excellence opérationnelle du processus de fabrication qui doit tenir
une productivité avec une qualité parfaite. Ces deux logiques amènent des modes de travail différents.
L’adaptation rapide d’applications se situe du côté de l’excellence opérationnelle d’un processus de fabrication,
par différence avec la maitrise de changements complexes menés en mode projet se situant du côté de l’agilité
de conception.
20 © Yphise
2. Comprendre la solution
2.2 Une fonction devops
Le bon mode opératoire pour gouverner le système opérationnel d’adaptation rapide est son
insertion dans un business case (1).
Le système opérationnel reprend la solution de base, mais avec deux grandes différences à ne pas
rater.
La première concerne le propriétaire de produit (2) : son rôle est centré différemment. Le
propriétaire de produit répond de la qualité au sens de la satisfaction de l’utilisateur : il doit voir le
produit selon l’œil de l’utilisateur.
La seconde définit une recette devops fondée sur une boucle d’amélioration rapide qui vise à
obtenir les bons signaux d’insatisfaction de l’utilisateur, afin de réaliser à temps les modifications
utiles (3). Ces signaux peuvent en particulier amener à modifier le banc d’essai, ce qui se
concrétise par un test backlog.
GouvernanceLa fonction devops de CE produit
Système opérationnel
Banc
d’essai
Propriétaire de produit
Production
Sprint
demandes de
changement
SprintProduct
& test
backlog
Analyse
signaux
situation client
Resp business case
temps
scénario
action action actionaction
Contrôle de maitrise
action Evolutions nécessaires ou inaccessibles au système opérationnel
délégation
2
1
3
On retrouve dans une fonction devops la solution de base, mais avec des différences qu’il
ne faut pas rater.
21 © Yphise
La plus importante, même si elle n’est pas spectaculaire, concerne le propriétaire de
produit. Dans la solution de base, son rôle est centré sur la gestion des changements à
apporter au produit : il recueille, ordonne et calibre les demandes de changement ; il
gère concrètement le product backlog. Dans une fonction devops, son rôle est centré sur
la qualité au sens de la satisfaction de l’utilisateur : il doit voir le produit selon l’œil de
l’utilisateur.
Cet œil de l’utilisateur amène la mise en place de dispositifs permettant de pallier autant
que faire se peut l’absence de recette. Ceci amène une boucle d’amélioration rapide qui
vise à obtenir les bons signaux d’insatisfaction de l’utilisateur, afin de réaliser à temps les
modifications utiles. Ces signaux peuvent en particulier amener à modifier le banc
d’essai, ce qui se concrétise par un test backlog d’amélioration de sa pertinence au
regard de la satisfaction de l’utilisateur.
Une fonction devops vient en outre compléter le système opérationnel par une
gouvernance appropriée. Le système opérationnel réalise ainsi des adaptations rapides du
produit par délégation d’un dispositif qui donne un objectif, contrôle ce qui est fait, et
réalise les évolutions nécessaires à ce système. Le dispositif approprié est l’insertion du
système opérationnel dans un business case.
Avant de descendre dans chaque composante d’une fonction devops11, il est important de
noter qu’on n’a pas une mais DES fonctions devops. Voyons ce point...
11 Chapitre ‘3. Réussir une fonction devops’.
22 © Yphise
2. Comprendre la solution
2.3 Les fonctions devops
Gouvernance
Système opérationnel
Une fonction devops correspond à un produit : il y a autant de fonctions devops que de produits.
Un produit est un morceau du système d’information pour des types de changement sur lesquels
on sait monter un banc d’essai : un produit se définit par un périmètre de validité du banc d’essai.
On est ici très loin d’ITIL qui a une approche par processus transverses au système d’information.
Gouvernance
Système opérationnelGouvernance
Système opérationnel
Produit X
Produit Y
Produit Z
Les fonctions devops
Nous insistons sur le fait qu’il n’y a pas UNE mais DES fonctions devops. Il y a une
fonction devops par morceau du système d’information considéré comme un PRODUIT
devant évoluer selon une logique d’adaptation rapide.
La nécessité de distinguer des fonctions devops est liée à la problématique
d’industrialisation des tests. On ne sait pas traiter de manière générale l’automatisation
des tests sur un système d’information : il faut se restreindre à des types de changement
sur un morceau précis. Le produit qui définit une fonction devops correspond au
périmètre de validité de son banc d’essai.
Notons qu’on est très loin d’ITIL qui a une approche par processus transverses au
système d’information : processus de test, de gestion des environnements, de mise en
production, etc. ; alors qu’une fonction devops prend les différents sujets pour en faire
une boite (une factory) dédiée à un produit.
Attention : il ne faut pas considérer que l’approche par processus transverses (ITIL) est
remplacée par des fonctions sur des produits (devops). Les deux modes ont leur utilité.
On ne peut pas traiter des évolutions du système d’information nécessitant un ou des
projets pouvant être complexes et intégrés en releases, par une fonction conçue pour
l’adaptation rapide d’un produit. Ceci est une évidence, mais elle est bonne à rappeler car
de nombreuses erreurs sont liées à son oubli.
Reprenons les différentes composantes d’une fonction devops ; voyons ce qu’il faut bien
comprendre sur chacune...
23 © Yphise
3. Réussir une fonction devops
3.1 Le business case
3.2 Le propriétaire de produit
3.3 La recette devops
3.4 Le banc d’essai
GouvernanceLa fonction devops de CE produit
Système opérationnel
Banc
d’essai
Propriétaire de produit
Production
Sprint
demandes de
changement
SprintProduct
& test
backlog
Analyse
signaux
situation client
Resp business case
temps
scénario
action action actionaction
Contrôle de maitrise
action Evolutions nécessaires ou inaccessibles au système opérationnel
délégation
24 © Yphise
3. Réussir une fonction devops
3.1 Le business case
Le bon mode opératoire pour gouverner le système opérationnel d’adaptation rapide est son
insertion dans un business case.
Ce business case permet de réaliser les évolutions dont l’envergure ou la complexité amène des
projets hors de portée de l’adaptation rapide. On y trouve notamment des évolutions d’architecture
du système d’information ou de conception des applications permettant de donner de la puissance
au banc d’essai.
Ce business case est également le moyen d’une prise de recul sur l’évolution de la qualité afin
d’empêcher sa dégradation dans le temps et d’en gérer une dynamique d’excellence
opérationnelle.
Action
− Evolutions d’architecture, de conception ou de fonctions nécessaires au banc d’essai (en
particulier pour limiter les flux des tests d’intégration ou simplifier les scénarios de test).
− Evolutions techniques ou fonctionnelles permettant de sécuriser ou d’élargir les évolutions
passant par le système opérationnel.
− Evolutions trop lourdes ou complexes pour passer par le système opérationnel (nécessitant
notamment un projet).
Contrôle
− Recul sur la qualité et la pertinence de ce que fait le système opérationnel (revue des
éléments de satisfaction ou d’insatisfaction des utilisateurs, revue des incidents et
problèmes) ; réflexion sur ces opportunités ou les contraintes pour la suite du business
case.
Resp business case
temps
scénario
action action actionaction
Contrôle de maitrise
action Evolutions nécessaires ou inaccessibles au système opérationnel
GouvernanceLa fonction devops de CE produit
On est sur la gouvernance de la fonction : on a un niveau opérationnel qui est fait pour
réaliser des adaptations rapides du produit, il faut une gouvernance qui permette de
cadrer et contrôler cette délégation de responsabilité. C’est le garde-fou empêchant les
dérives dans son utilisation.
25 © Yphise
Cette gouvernance a en outre un rôle spécifique aux fonctions devops qu’il faut bien
comprendre. LA contrainte d’une fonction devops est la faisabilité de l’automatisation des
tests. Cette faisabilité dépend de considérations d’architecture du système d’information
et de conception fonctionnelle ou technique des applications, notamment pour limiter les
flux des tests d’intégration ou simplifier les scénarios de test12. Ces considérations
amènent des évolutions dont l’envergure ou la complexité nécessitent des projets : on ne
peut pas les réaliser par l’adaptation rapide. La gouvernance de la fonction devops doit
prendre en charge la réalisation des évolutions nécessaires ou inaccessibles au système
opérationnel.
Une fonction devops manque en général de puissance lorsque cette gouvernance est
faible : elle bricole des applications avec une tendance à la dégradation de la qualité dans
le temps, alors qu’il faut au contraire travailler la puissance et la sécurisation des
évolutions menées par l’adaptation rapide. Il faut notamment se poser la question
lorsqu’on a des changements à répétition (ex. sur chaque nouveau produit d’un
catalogue) de fonctions qui automatisent ou sécurisent (ex. fonction de publication) : le
contrôle du système opérationnel par la gouvernance amène alors à identifier des
évolutions à réaliser par celle-ci.
Un sujet important de ce contrôle est le recul sur la satisfaction de l’utilisateur. Il doit en
particulier regarder les signaux d’insatisfaction sur les types de changement ou leur
fréquence afin de préciser les changements licites ou à prohiber, ou de trouver les
moyens adaptés de leur sécurisation.
La bonne manière de s’y prendre pour mettre en place cette gouvernance est de
considérer qu’elle constitue un business case : la gouvernance applique le mode business
case, qui constitue par ailleurs un dispositif de base de la maitrise de l’investissement sur
les systèmes d’information. Il s’agit donc de mettre en œuvre des savoir-faire existants,
sans chercher à inventer quelque chose de spécifique : nous renvoyons aux études
correspondantes13.
Entrons maintenant dans le système opérationnel...
12 Chapitre ‘3.4 Le banc d’essai’.
13 Etude « Responsable de business case ». Egalement étude « Des projets rigides à l’agilité de
l’investissement ».
26 © Yphise
3. Réussir une fonction devops
3.2 Le propriétaire de produit
L’évolution la plus importante est le centrage du propriétaire de produit sur la qualité au sens de la
satisfaction de l’utilisateur ; par différence avec un centrage de ce rôle sur la gestion des
changements à apporter à l’application.
Le propriétaire de produit est ainsi l’œil de l’utilisateur : il se met en situation de recetteur ; il
développe le banc d’essai de sorte à expliciter progressivement les points qui traduisent cet œil de
l’utilisateur, ce qui se concrétise par la notion de test backlog.
Le propriétaire de produit en situation client = il est responsable de la qualité au sens de la
satisfaction de l’utilisateur : il doit voir l’application selon l’œil de l’utilisateur (1).
Ceci amène la notion d’évolution du banc d’essai pour expliciter progressivement les points de
satisfaction de l’utilisateur auparavant implicites : le propriétaire de produit est responsable
d’un test backlog (2).
La fonction devops de CE produit
Système opérationnel
Product
& test
backlog
Propriétaire de produit
situation client1
2
L’évolution la plus importante par rapport à la solution de base concerne le propriétaire
de produit : une fonction devops centre ce rôle sur la satisfaction de l’utilisateur, alors
qu’il est souvent restreint à celui de gestionnaire des changements.
La bonne nouvelle est que cette évolution est simple à mettre en œuvre : ce n’est pas
une transformation coûteuse ou compliquée. Elle fait bouger le centrage d’un rôle sans
remise en question de fond.
Le propriétaire de produit devient ainsi l’œil de l’utilisateur sur l’application, dans une
situation où il est en général impossible de mener une recette détaillée par des
utilisateurs. Nous insistons à nouveau sur ce point : la logique d’adaptation rapide
d’applications empêche la conduite d’une recette ; alors même qu’on vise souvent un
grand nombre d’utilisateurs non formés et non supportés (grand public), c’est-à-dire un
contexte où mettre l’utilisateur au centre du détail de la manipulation de l’application est
indispensable pour garantir qu’elle correspond bien à l’attente (implicite ou explicite).
Dit autrement, le propriétaire de produit doit d’abord être un recetteur de l’application : il
se met en situation de l’utilisateur sur l’application. Cette recette est forcément
imparfaite car il n’est pas un utilisateur, mais un professionnel connaissant parfaitement
l’application : c’est pourquoi il lui faut un dispositif lui permettant d’obtenir rapidement
27 © Yphise
les bons signaux d’insatisfaction, ce qui est appelé la recette devops présentée au
chapitre suivant14.
Mais attention à ne pas mélanger l’essentiel et le secondaire. Le dispositif de remontée
des bons signaux est un moyen pour aider le propriétaire de produit : il peut être plus ou
moins performant, il n’est de toute façon jamais parfait. La clé de succès est que le
propriétaire de produit réponde de la qualité au sens de la satisfaction de l’utilisateur : il
doit voir l’application selon l’œil de l’utilisateur.
L’œil de l’utilisateur est d’abord affaire de bon sens : il s’agit de voir ce qu’on ne prend
pas la peine d’expliciter tellement cela paraît évident ou aller de soi ; mais il n’y a rien
d’évident ou qui va de soi pour un algorithme15.
Nous insistons : ce positionnement du propriétaire de produit est fondamental ; et il n’est
pas une évidence car ce rôle n’a pas été introduit ainsi par Scrum16. Scrum considère en
effet que c’est un gestionnaire de changements ; et Scrum ne définit pas de recette. L’œil
de l’utilisateur dans Scrum est vu comme étant l’expérience de l’équipe de
développement17. C’est précisément une des raisons de la qualité médiocre de nombreux
webs ou applications mobiles, et de la tendance à la dégradation de cette qualité dans le
temps.
Cette mise en situation client du propriétaire de produit amène concrètement la notion de
test backlog, c’est-à-dire de modifications à apporter aux tests automatisés du banc
d’essai. Ces modifications vont au delà de la correction des défauts de couverture des
tests : elles explicitent progressivement des points de satisfaction des utilisateurs qui
étaient auparavant implicites18.
Dit autrement, ces modifications contribuent à spécifier le produit : les nouveaux points à
tester amènent des changements sur l’application. C’est pourquoi le test backlog n’est
pas forcément un document à distinguer du product backlog : on peut garder la
14 Chapitre ‘3.3 La recette devops’.
15 Reproduire le sens commun est aujourd’hui un défi très compliqué pour l’intelligence artificielle, alors qu’on
est sur des perceptions ordinaires pour l’humain.
16 Etude « Le bon usage de Scrum ».
17 D’où l’insistance fréquente sur les software craftmanships (lit. les compétences de l’artisan du logiciel) dans
les développements menés en règle du jeu agile (Scrum ou autres). Mais c’est fumeux : un bon développeur
est un professionnel très différent d’un utilisateur grand public dans sa manière d’aborder une application ;
c’est inévitable (en plus le développeur connaît parfaitement l’application, ce qui lui rend impossible une mise
en situation de l’utilisateur).
18 Dit en terme de qualité : il s’agit de passer d’exigences implicites à explicites ; c’est-à-dire d’une validation
à une vérification : note chapitre ‘1.3 Les fragilités’.
28 © Yphise
dénomination de product backlog ou parler de product & test backlog19. Notons qu’on voit
bien ici que l’adaptation rapide d’applications est dans une logique de développement qui
met les problématiques de test au cœur du travail de l’équipe de développement20.
19 L’option de Scrum est de considérer que le product backlog est le lieu d’enregistrement qualifié de tous les
types de changement, ce qui est excellent ; mais on constate souvent une dérive qui est de restreindre le
product backlog à une spécification des nouvelles fonctions, ce qui est mauvais.
20 Par différence avec le développement traditionnel où l’équipe de développement livre un code qui est
ensuite recetté en détail, les modifications demandées par les utilisateurs étant vues comme des corrections.
L’absence de recette détaillée change en profondeur la manière de travailler de l’équipe de développement ; ce
qui n’est pas toujours bien compris, et qui nécessite toujours un propriétaire de produit correctement centré
sur la satisfaction de l’utilisateur. Chapitre ‘4.3 Les composantes du banc d’essai’.
29 © Yphise
3. Réussir une fonction devops
3.3 La recette devops
La recette devops est un outil pour aider le propriétaire de produit dans sa responsabilité de
satisfaction de l’utilisateur. C’est un palliatif à l’absence de recette détaillée par des utilisateurs.
Il s’agit de trouver les bons signaux d’insatisfaction en regardant l’utilisation opérationnelle de
l’application, et les variations de cette utilisation opérationnelle au fur et à mesure des mises en
production.
La recette devops est un dispositif indispensable, mais il faut faire attention à ne pas lui en
demander plus qu’il ne peut fournir : l’erreur est de vouloir faire trop compliqué.
Remonter de l’utilisation opérationnelle les bons signaux d’évolution de l’application ou du banc
d’essai pour maintenir et améliorer la qualité.
Les signaux recherchés répondent à trois objectifs.
− La détection immédiate des bogues amenés par une mise en production.
− L’évitement de la dégradation de la qualité dans le temps intrinsèque à l’accumulation de
petites évolutions, qui amène toujours des complexités inutiles, des manipulations
contraires au bon sens ou des exceptions mal gérées.
− L’amélioration de la satisfaction de l’utilisateur en trouvant ce qui lui déplaît, n’est pas
conforme à ses attentes ou à ses manières de faire.
La fonction devops de CE produit
Système opérationnel
Production
Product
& test
backlog
Analyse
signaux
Propriétaire de produit
situation client
La recette devops est un outil à l’attention du propriétaire de produit pour l’aider à
détecter rapidement les insatisfactions ou les risques de dégradation de la satisfaction
des utilisateurs.
Le principe est simple : on regarde les évolutions de l’utilisation de l’application dans le
temps en cherchant à comprendre si elles expriment une satisfaction ou une
insatisfaction de l’utilisateur. Les différences d’utilisation de versions successives d’une
application permettent d’identifier de bons signaux pour réaliser à temps les
modifications utiles.
Attention : cette recette devops est un mode opératoire de recette détaillée qui est
30 © Yphise
dégradé : c’est un mode correctif puisqu’il s’agit de détecter les problèmes après mise en
production ; alors qu’une recette a pour finalité d’empêcher leur mise en production,
c’est-à-dire de constituer un mode préventif. La recette devops est ainsi un palliatif à la
présence d’utilisateurs : ce n’est pas un remplacement pur et simple d’une ancienne
manière de faire par une nouvelle plus performante ; c’est une solution empirique qui
répond aux contraintes de l’adaptation rapide d’applications.
Nous insistons : sa pertinence repose sur le propriétaire de produit. La clé de succès n’est
pas dans la multiplication des données recueillies, mais dans la capacité du propriétaire
de produit à identifier les bons signaux en ayant l’œil de l’utilisateur. C’est pourquoi nous
avons considéré qu’il doit être lui-même un recetteur de l’application21.
Les signaux recherchés répondent à trois objectifs.
Le premier objectif est la détection immédiate des bogues amenés par une mise en
production : c’est du correctif urgent. Un signal simple et efficace est le nombre
d’affichage de pages d’erreur sur l’indisponibilité d’une fonction, un lien manquant ou le
dépassement d’un temps. La base est également de regarder les points de passage dans
l’application qui en caractérisent le bon fonctionnement.
Le second objectif est d’éviter la dégradation de la qualité dans le temps : la
multiplication de petites évolutions sur une application finit toujours par amener des
complexités inutiles, des manipulations contraires au bon sens ou des exceptions mal
gérées. C’est intrinsèque à la rapidité qui s’oppose à une conception propre au regard
d’une bonne analyse : l’adaptation rapide part du code à modifier sans chercher à
remonter sur des niveaux de conception ou d’analyse qui demanderaient beaucoup trop
de temps et de moyens.
Cet objectif de non dégradation s’intéresse aux tendances : les différences de
comportement d’une version à l’autre peuvent être négligeables, mais devenir
significatives en tendance sur plusieurs jours, semaines ou mois. Il s’agit donc de suivre
des indicateurs d’utilisation des différentes fonctions et d’investiguer précisément sur les
périodes d’apparition ou d’accélération des changements de comportement.
Enfin, le troisième objectif est d’amélioration. Il s’agit de trouver ce qui déplaît à
l’utilisateur, n’est pas conforme à ses attentes ou à ses manières de faire. L’application
fonctionne et son utilisation ne semble pas se dégrader, mais on sent qu’elle ne satisfait
pas pleinement l’utilisateur : dit en des termes traditionnels, elle ne couvre pas
parfaitement son besoin22.
C’est sur cet objectif d’amélioration qu’il est le plus difficile de trouver les bons signaux.
On se situe dans une démarche d’excellence opérationnelle donc d’amélioration
21 Chapitre ‘3.2 Le propriétaire de produit’.
22 Nous rappelons qu’une recette est une validation, c’est-à-dire l’appréciation d’un résultat au regard du
besoin qui le détermine, qu’il soit implicite ou explicite. Une recette détaillée par des utilisateurs vise à
remonter au besoin, c’est-à-dire un cran au-dessus de la spécification du résultat. La vérification du résultat
sur sa spécification peut se faire sans utilisateur. Note chapitre ‘1.3 Les fragilités’.
31 © Yphise
progressive : on cherche à identifier ce qui gêne, fragilise, ralentit ou bloque l’utilisateur
pour lever ces points d’insatisfaction. Une bonne approche est de regarder les abandons,
retours arrière ou répétitions de fonctions faits par l’utilisateur, qui signifient toujours que
quelque chose ne va pas. Il est parfois possible de descendre plus précisément encore
dans la compréhension de la situation par la trace des erreurs de manipulation ou la
consultation d’aides en ligne.
L’erreur à éviter dans tout cela est de vouloir faire trop compliqué : la clé de succès est
bien le recul du propriétaire de produit, pas de prétendre sortir automatiquement des
modifications à apporter.
32 © Yphise
3. Réussir une fonction devops
3.4 Le banc d’essai
Les deux points essentiels.
− Un banc d’essai n’est jamais parfait et a tendance à se dégrader au fur et à mesure des
évolutions. LA clé de succès est l’attention du propriétaire de produit qui se concrétise par la
rigueur de gestion du test backlog.
− L’automatisation des tests en adaptation rapide nécessite de remonter à des considérations
d’architecture du système d’information ou de conception des applications ; ce qui amène des
projets. LA clé de succès est la solidité du business case gouvernant la fonction devops.
L’automatisation des tests en adaptation rapide nécessite de remonter à des considérations
d’architecture du système d’information ou de conception des applications.
En particulier pour couper les flux des tests d’intégration
− empêchant l’écriture de scripts d’automatisation,
− ou amenant des complexités de mise à disposition ou d’exploitation des environnements
incompatibles avec les enjeux de durée des tests et de prédictibilité de cette durée.
La fonction devops de CE produit
Système opérationnel
Banc
d’essai
Production
Sprint
SprintProduct
& test
backlog
Analyse
signaux
Propriétaire de produit
situation client
La qualité devops nécessite un excellent banc d’essai. Hors le banc d’essai est un sujet
complexe sur lequel l’informatique bute depuis toujours. La faisabilité d’un bon banc
d’essai contraint donc l’adaptation rapide d’applications23. On ne sait faire de bons bancs
d’essai que spécialisés sur des situations précises : des types de changement sur un
périmètre applicatif précis, c’est-à-dire sur un produit24. En outre, un banc d’essai n’est
jamais parfait et il a tendance à se dégrader dans le temps.
LA conséquence fondamentale est la nécessité d’avoir un propriétaire de produit en
situation client et gérant à cette fin un test backlog25. Nous insistons : l’attention portée
23 Chapitre ‘4.3 Les composantes du banc d’essai’.
24 Chapitre ‘2.3 Les fonctions devops’.
25 Chapitre ‘3.2 Le propriétaire de produit’.
33 © Yphise
par le propriétaire de produit à la couverture des tests automatisés et à son amélioration
au fil du temps, est essentielle ; toutes les bonnes pratiques de conception technique du
banc d’essai sont insuffisantes sans cet œil du propriétaire de produit.
L’automatisation des tests dans une finalité d’adaptation rapide amène comme principe
une spécialisation des environnements par produit, en visant la réalisation de tous les
tests pour ce produit dans un environnement unique26. On est donc très loin de
l’approche traditionnelle distinguant des environnements par phase de test d’un
processus de test d’un système d’information.
Cette spécialisation par produit multiplie le nombre d’environnements. Mais il ne s’agit
pas comme dans l’approche traditionnelle d’avoir des environnements stables dont
l’usage est régulier selon des campagnes de test longues. Les environnements pour
l’adaptation rapide ont souvent (pas toujours) des périodes d’utilisation ou une durée de
vie limitées. On cherche donc à les virtualiser pour une mise à disposition à la volée et
optimiser les coûts27.
Enfin, il est essentiel de bien voir que l’automatisation des tests dans une finalité
d’adaptation rapide nécessite de remonter à des considérations d’architecture du système
d’information ou de conception fonctionnelle ou technique des applications. Il faut en
particulier couper les flux des tests d’intégration qui empêchent l’écriture de scripts
d’automatisation, ou qui amènent des complexités de mise à disposition ou d’exploitation
des environnements incompatibles avec les enjeux de durée et de prédictibilité de la
durée des tests28. Ceci amène des projets informatiques gérés par le business case
gouvernant la fonction devops29.
Nous insistons sur ce besoin de remonter à des considérations d’architecture ou de
conception des applications au regard des contraintes de faisabilité du banc d’essai. Ce
besoin n’est pas toujours bien compris car les tests sont traditionnellement vus comme
étant une problématique en aval de la conception fonctionnelle et technique des
applications, alors qu’ils structurent cette conception dans une fonction devops. En outre,
ce besoin amène toujours un risque de conflit car il conduit souvent à des choix
contraires aux bonnes pratiques d’architecture (duplication de données, asynchronismes,
hétérogénéité de solutions) : LA clé est la solidité de définition et de pilotage du business
case gouvernant la fonction devops30.
26 Chapitre ‘4.3 Les composantes du banc d’essai’.
27 Id.
28 Id.
29 Chapitre ‘3.1 Le business case’.
30 Id.
34 © Yphise
35 © Yphise
4. Complément : devops
4.1 Un mot valise
4.2 Les principes devops
4.3 Les composantes du banc d’essai
Le mot devops désigne une problématique : permettre des mises en production fréquentes ou
très fréquentes de changements d’envergure limitée sur des applications.
Le cœur du sujet est donc d’industrialisation des tests : il faut savoir tester les changements et
leur non régression, avec une durée et une prédictibilité de cette durée adaptées.
! Devops = un mot valise
36 © Yphise
4. Complément : devops
4.1 Un mot valise
Devops ne se caractérise pas par un contenu précis ; c’est un contenant dans lequel chacun peut y
mettre ce qu’il juge pertinent selon sa situation.
! Devops = un mot valise
Le mot devops a été introduit pour désigner une problématique :
« On a atteint une certaine agilité sur le développement, en utilisant notamment Scrum ;
comment faire pour être agile jusqu’en production ? Concrètement sur la réalisation des tests,
la mise à disposition et l’exploitation des environnements, et les montées d’environnement ».
Dire « je suis agile : je fais du Scrum et du devops »
est comparable à dire « je fais du sport : je fais du foot et du sport ».
− deux natures différentes : Scrum est une règle du jeu agile précise (que l’on applique ou
pas) ; devops désigne une problématique globale d’agilité ;
− une tautologie : agile et devops disent à peu près la même chose.
Le mot devops désigne une problématique : « on a atteint une certaine agilité sur le
développement (en utilisant notamment Scrum mais sans que cela soit une obligation) :
comment faire pour être agile jusqu’en production ? »31.
Devops n’est pas le nom d’une solution : ce n’est pas un référentiel (ex ITIL), une norme
(ex ISO 9001), une méthode ou une règle du jeu (ex Scrum), ou un savoir-faire. Le mot
devops est un nom commun : il s’utilise donc sans majuscule32.
Devops est un mot valise : c’est la désignation d’une enveloppe dans laquelle chacun
peut y mettre ce qu’il veux : les pratiques qu’il trouve adaptées à sa situation. Mais il faut
faire attention à ce que ces pratiques ne soient pas vues comme une recette :
« j’applique devops » est une phrase qui n’a pas de sens, par différence avec « j’applique
Scrum » qui est un mode de travail parfaitement défini33.
31 Le mot devops est un barbarisme commode : la concaténation de dev pour développement et ops pour
opérations. Il a été introduit en 2009 (Patrick Debois) à l’occasion d’une conférence peu fréquentée.
32 Nous disons « devops » plutôt que « le devops ». Certains disent « le devops » ce qui est pertinent ;
supprimer l’article facilite la rédaction et la lecture.
33 Scrum est défini par un document précis : The Scrum guide.
37 © Yphise
4. Complément : devops
4.2 Les principes devops
Attention : pas de liste unique ni de définition précise de ces principes.
Ces principes ne sont pas fermement établis : ils évoluent et sont considérés de manière variable
selon l’intérêt de l’acteur qui s’y réfère.
! Devops = un mot valise
− Déploiement fréquent, selon des processus établis et fiables.
− Tests au plus tôt.
− Tests sur un environnement similaire à la production.
− Intégration continue.
− Métriques de surveillance de la qualité en production.
− Boucle d’amélioration courte.
Devops a rapidement été caractérisé par des principes. Ces principes sont pertinents,
mais attention, il ne faut pas trop les serrer : ils ne sont pas d’un même niveau
d’expression ; ils ne caractérisent ni une problématique ni une solution ; ils ne sont pas
tous de la même importance ni suffisants. C’est un cadrage utile à la réflexion, mais il ne
faut pas vouloir en faire l’exposé d’une solution ou d’un mode d’action pour atteindre une
solution.
En particulier, ces principes n’introduisent pas les notions fondamentales à la réussite : la
notion de fonction (ou système) distinguant un niveau opérationnel (factory) et une
gouvernance34 ; la spécialisation des fonctions par produit caractérisé par un périmètre
de validité du banc d’essai35. Ces principes passent également à côté des responsabilités
à identifier et à organiser, ce qui est toujours un sujet critique de la réussite
opérationnelle dans la durée : le rôle du propriétaire de produit centré sur la qualité au
sens de la satisfaction de l’utilisateur ; l’insertion dans un business case de gouvernance
de la fonction36.
Le mode d’action que nous recommandons est la gestion de fonctions devops.
34 Chapitre ‘2.1 Préalable’.
35 Chapitre ‘2.3 Les fonctions devops’.
36 Chapitre ‘2.2 Une fonction devops’.
38 © Yphise
4. Complément : devops
4.3 Les composantes du banc d’essai
Développement rapide
Industrialisation automatisée
Industrialisation automatisée
Tests unitaires et d’intégration automatisés
Gestion automatisée des environnements
Gestion automatisée des montées d’environnement
Banc
d’essai
Production
changements
Architecture Gestion des services
Mise sous automate des tests unitaires et d’intégration : fonctionnels ou techniques ; nouveaux
développements et non régression.
Tests unitaires = sur le périmètre de développement (tests unitaires à proprement parler +
tests d’assemblage). Tests d’intégration = au delà du périmètre de développement (tests
d’intégration du développement + tests du produit et du système d’information).
Les tests
Gestion des configurations logicielles (SCM software configuration management), mise à
disposition des infrastructures (provisioning), gestion des données de test (dont
anonymisation), gestion et exploitation adaptées de chaque environnement.
En particulier, travail sur la virtualisation permettant une mise à disposition à la volée des
infrastructures (provisioning on demand) : cloud (infrastructure as a service) et infrastructure
programmable (infrastructure as code).
Les environnements
Automatisation des montées d’environnement (DM deployment management) : code, scripts,
paramètres (middleware, bases de données, progiciels, applications internes) ; avec une
cohérence transverse aux infrastructures (des serveurs aux mobiles) ; avec une gestion fine
des retours arrière.
En continuous deployment = montées automatisées jusqu’en prod, ou en continuous delivery =
montées automatisées jusqu’en préprod, la montée en prod étant sous contrôle manuel.
Les montées d’environnement
Mise des livrables relatifs aux tests (scénarios, scripts d’automatisation, jeux d’essai, exécution
OK) au même niveau d’importance que le code pour l’équipe de développement ; ce qui peut
aller jusqu’au développement par les tests (test-driven development), c’est-à-dire l’écriture des
scénarios de test avant celle du code.
Le développement
39 © Yphise
Interventions d’architecture du système d’information ou de conception fonctionnelle ou
technique des applications permettant l’industrialisation automatisée, notamment pour limiter
les flux des tests d’intégration ou simplifier les scénarios de test.
En particulier, travail sur la flexibilité de l’architecture (couplage faible) : architecture de
services ou micro services, interfaces et APIs propres.
Attention : ceci peut amener des actions contraires aux bonnes pratiques d’architecture ou qui
compliquent sa bonne gestion : duplication de données, asynchronisme, hétérogénéité des
solutions.
Architecture
Interventions fluides (just in time) des centres de compétences qui ne peuvent pas donner lieu
à une automatisation.
Gestion des services
Le banc d’essai est un sujet compliqué parce qu’il nécessite des équilibres ou compromis faisant
intervenir des parties prenantes dont les responsabilités sont potentiellement conflictuelles (plus ou
moins).
Point le plus difficile : le banc d’essai touche le développement, l’architecture du système
d’information et la conception des applications : ce n’est pas un sujet aval transparent pour ces
parties prenantes.
Le banc d’essai amène une approche de spécialisation d’environnements pour tester des types de
changement sur un morceau du système d’information ; par différence avec la gestion d’un
environnement générique par phase de test d’un processus sur un système d’information.
Un banc d’essai réalise des tests unitaires et d’intégration de manière automatisée.
C’est un sujet complexe : il comporte différentes composantes à bien organiser.
La première clé de succès est de considérer correctement sa dimension sur le
développement : l’automatisation des tests nécessite des livrables relatifs aux tests au
même niveau d’importance que le code pour l’équipe de développement. L’automatisation
est un objectif irréaliste sans des scripts permettant la couverture de test voulue au
moyen de jeux d’essai adaptés.
La capacité à réaliser les scripts d’automatisation détermine concrètement la faisabilité
d’un banc d’essai, c’est-à-dire son périmètre de validité. On ne sait en effet pas réaliser
un banc d’essai capable de tester tout changement sur un système d’information : un
banc d’essai se conçoit toujours pour des types de changement sur un morceau du
système d’information permettant l’automatisation.
La conception d’un banc d’essai nécessite pour cela de remonter à des considérations
d’architecture du système d’information ou de conception des applications : il s’agit de
limiter les flux des tests d’intégration ou de simplifier les scénarios de test. La difficulté
est que la prise en compte des contraintes du banc d’essai peut contrarier les bonnes
pratiques d’architecture : ces contraintes peuvent amener des duplications de données,
des asynchronismes ou des hétérogénéités de solutions qui compliquent l’architecture. Il
faut donc trouver des équilibres ou compromis amenant souvent des risques de conflit
entre des intérêts divergeants.
40 © Yphise
Le socle opérationnel du banc d’essai est constitué du ou des environnements d’exécution
des tests, avec l’ensemble des dispositifs pour sécuriser leur alimentation, leur
exploitation et les montées d’environnement. Les outils de base sont de gestion des
configurations logicielles (SCM software configuration management) et de montées
d’environnement (DM deployment management). La difficulté est la cohérence des
environnements transverses au système d’information, reposant sur des infrastructures
complexes et hétérogènes, des serveurs aux mobiles. C’est pourquoi la conception d’un
banc d’essai cherche à organiser les environnements par niveau d’infrastructure, ce qui
amène notamment à penser l’architecture du système d’information et la conception des
applications de manière à éviter les flux des tests d’intégration intervenant sur différents
niveaux d’infrastructure.
La bonne automatisation de la mise à disposition et de l’exploitation des environnements
est la dernière clé de succès. Il faut éviter les interventions manuelles de centres de
compétences qui constituent autant de points de fragilité sur la durée des tests :
l’intervention à temps de centres de compétences est un sujet d’organisation toujours
difficile37. C’est pourquoi il faut rechercher la simplicité des environnements, c’est-à-dire
leur suffisance au regard des tests à réaliser sur le morceau du système d’information
considéré : ceci conduit à leur spécialisation pour tester des types de changement sur un
morceau du système d’information, par différence avec des environnements génériques
au système d’information par phase de test d’un processus de test.
Cette spécialisation des environnements a pour conséquence de multiplier le nombre
d’environnements ayant des périodes d’utilisation ou une durée de vie limitées. On
cherche alors à les virtualiser pour permettre leur mise à disposition à la volée et
optimiser les coûts ; par différence avec les environnements stables par phase de test
d’un processus de test d’un système d’information, dont l’usage est régulier selon des
campagnes de test longues justifiant leur existence en dur. La gestion des
environnements d’un banc d’essai fait ainsi un large usage des techniques de
virtualisation d’infrastructure : cloud (infrastructure as a service) et infrastructure
programmable (infrastructure as code).
37 Etude « L’agilité des centres de compétences ».
