OCTO WP DevOps Vol1 Web

CULTURE
DEV PS VOL •
O1
LES INGRÉDIENTS SECRETS D’UNE ORGANISATION

DEVOPS ÉQUITABLE ET DURABLE
Notre Manifeste DevOps
1. Nous savons qu’il existe des pratiques et des technologies

qui donnent du sens à notre quotidien.
2. Nous avons du plaisir à travailler ensemble pour atteindre
un objectif qui soit commun à l’entreprise, à l’équipe et au
collaborateur.
3. Nous contribuons avec fierté à la performance des
organisations et à leur capacité à apporter de la valeur plus
rapidement.
4.
Nous sommes convaincus qu’un meilleur usage des
infrastructures est toujours possible.
5. Nous sommes en permanence à la recherche de nouvelles
pratiques et technologies pour anticiper la croissance et les
enjeux de demain.
6. Tel l’Artisan, nous avons le goût du travail de qualité et de la
transmission des savoir-faire.
7.
Tel le Magicien, nous masquons la complexité de nos
systèmes pour offrir de la simplicité à la demande.
8. Nous libérons le temps, esclave des tâches répétitives ou
sans valeur ajoutée.
9. Nous embrassons le changement, nous transformons l’IT
pour atteindre l’excellence.
10. Nous sommes DevOps.
O C T O > C U LT U R E D E V O P S V O L . 1
INTRODUCTION À LA TRILOGIE
Les trois histoires de DevOps :

Organisation, Qualité et Technologie
Si vous êtes resté caché dans une caverne ces huit dernières années, vous êtes peut-être
passé à côté de la mouvance DevOps. Aujourd’hui, c’est un fait : le mot est sur toutes les
3 lèvres de notre milieu IT. Mais le terme est souvent galvaudé, chacun y allant de sa définition,
et il devient urgent de converger sur un concept partagé pour éviter que DevOps ne demeure
qu’un buzzword de plus. Ainsi, il est de notre devoir d’apporter une pierre à l’édifice de
cette convergence en vous livrant, en toute humilité, notre vision1 de DevOps : celle qui nous
passionne et qui berce notre quotidien.
Nous définissons DevOps comme un ensemble de pratiques qui visent à réduire le 2 et à
améliorer la qualité des produits logiciels, en réinventant la coopération entre DEV et OPS.
DevOps, c’est un modèle d’organisation, une culture, un assemblage de processus, d’outils
et de patterns3 d’architecture. Pour nous, c’est aussi un métier, une passion. Et c’est la nature
même de cette passion que nous désirons vous partager ici.
Nous avons pour habitude de regrouper ces pratiques DevOps en quatre piliers :
1. Culture, méthodes et organisation : on y retrouve les ingrédients secrets d’une organisation
IT équitable et durable.
2. Infrastructure as Code et les pratiques de qualité qui l’accompagnent : ce pilier détaille
les techniques d’automatisation du déploiement des applications et des infrastructures
(réseaux, stockages, serveurs). Il vise à appliquer au monde des opérations informatiques,
des outils et des pratiques issus du monde de l’ingénierie logicielle (gestion de versions du
code source, tests automatisés, répétabilité des opérations, etc.)
3. P
atterns d’architecture Cloud Ready Apps4 : on regroupe ici les modèles d’architectures
techniques qui permettent de tirer parti du Cloud Computing pour offrir davantage de
résilience, de sécurité, d’exploitabilité et de scalabilité5 aux applications.
4. P
rocessus d’intégration et de déploiement continus : dans ce pilier, on industrialise la
production logicielle et son processus de validation de la qualité. En se reposant sur l’usine
d’intégration et de déploiement continus (CI/CD6), on automatise toutes les étapes de la
chaîne de production : tests fonctionnels, tests de performance, tests de sécurité, tests de
recette, déploiement de l’application sur un environnement, etc.
Quatre piliers donc, avec le choix éditorial de les traiter en trois volumes. C’est bien à
vous que cette trilogie s’adresse, vous qui êtes informaticien, développeur, administrateur
système, architecte, responsable des études ou de la production, CTO, CIO, CDO, CEO,
CxO, DevOps amateur ou confirmé, ou juste curieux. Vous y trouverez notre vision, certes
optimiste, de cette discipline sous trois angles complémentaires et indissociables :
• la culture et les modèles d’organisation équitables,
• la passion pour les technologies ouvertes,
• l’amour du travail de qualité et le software craftsmanship7 appliqué à DevOps.
L’ouvrage que vous tenez entre les mains constitue le premier volet. Il présentera les courants
4
de pensée qui donnent naissance aux traits culturels et aux modèles d’organisation propices
à DevOps. Ce premier volume a pour objectif de balayer les fondements d’une organisation
DevOps saine et équitable. Il donne des pistes pour transformer en profondeur son
organisation dans ce sens. On y abordera également les origines dont s’inspire le mouvement,
les objectifs de la méthode, la constitution, le fonctionnement et le passage à l’échelle des
équipes DevOps, les principaux écueils à éviter, la méthodologie de transformation et les
résultats que l’on peut espérer.
Asseyez-vous confortablement et commencez la dégustation par le chapitre qui vous plaira.
 Notre vision est celle d’OCTO Technology et de sa Tribu OPS qui œuvre depuis plus de cinq ans à la transformation DevOps de belles et grandes entreprises de
France et de Navarre.
 Time to Market est le temps moyen écoulé entre l’émergence d’une idée et sa commercialisation. Dans cet ouvrage, on utilisera cette notion dans un sens plus
large de Time to Value : le temps écoulé entre l’idée et sa mise à disposition pour l’utilisateur (dans notre contexte, il s’agira du temps de mise à disposition d’une
fonctionnalité logicielle).
 Un pattern est une solution répétable et réutilisable pour un problème identifié.
 Voir notre publication sur ces architectures : https://www.octo.com/fr/publications/23-cloud-ready-applications
 “La scalabilité (scalability, en anglais) désigne la capacité d’un logiciel à s’adapter à la montée en charge, en particulier sa capacité à maintenir ses fonctionnalités
et ses performances en cas de forte demande” - source : Wikipedia.
 CI/CD : Continuous Integration / Continuous Delivery.
 Voir le manifeste Software Craftsmanship : http://manifesto.softwarecraftsmanship.org/
“La vocation, c’est le bonheur

d’avoir pour métier sa passion.”
5 Stendhal
Au menu
Introduction 07-14
O1 Pourquoi parler d’organisation dans DevOps ? 08
L’organisation comme fondation de DevOps 11
Disclaimer : on vous aura prévenu... 14
L’organisation au service des objectifs

O2
de l’entreprise et du collaborateur 15-27
BIZ, DEV et OPS partagent les mêmes objectifs 17
Tous les contextes sont-ils favorables au DevOps ? 19
Retour sur Investissement de DevOps (ROI) 21
Alignement des objectifs : impacts sur l’épanouissement personnel 25
DevOps : vers l’autonomie

O3 et la responsabilisation des équipes 28-46
Pourquoi l’autonomie-responsable contribue-t-elle aux objectifs de DevOps 31
6 Un seul corps et un seul esprit pour le produit 33
Le passage à l’échelle de l’équipe produit 43
Pratiques méthodologiques
O4
& traits culturels propices à DevOps 47-57
Traits culturels facilitateurs 49
Rythmes & rituels 53
Management par les pairs et compagnonnage 56
Les anti-patterns organisationnels

O5
les plus courants 58-79
Dépendance de compétences clés en dehors de l’équipe 60
Les ennemis de l’autonomie : les trois anti-patterns 64
Isolation : la distance géographique comme frein à la collaboration 69
Les limites de l’externalisation 71
L’équipe DevOps comme proxy entre DEV et OPS 75
Implémentation rigide d’ITIL 77
Doggy bag 80-89

O6 Par où commencer sa transformation ? 82
DevOps : vivre le bonheur d’avoir pour métier sa passion 88
Introduction
Pourquoi parler d’organisation dans leurs manières de travailler et leur organisation,

DevOps ? ils ne récolteront pas les fruits qu’ils peuvent
espérer de DevOps.
Nous avons la mission de partager avec vous
l’essence, la substance et la philosophie qui Depuis 5 ans, nous accompagnons des
font du mouvement DevOps quelque chose moyennes et grandes entreprises françaises
de Grand. Plus grand que dans leurs transformations
le buzzword, plus grand "Le succès d’une vers DevOps. Ces expé-
que les intérêts propres des riences nous ont aidés à nous
8
industries qui en font un
démarche DevOps forger la conviction suivante :
business, plus grand que les repose d’abord sur la le succès d’une démarche
tendances éphémères qui
culture, l’organisation DevOps repose d’abord sur
la culture, l’organisation et la
bercent notre métier depuis
ses débuts. et la méthodologie." méthodologie.
Cette mission est délicate

et ambitieuse. Nous lisons encore trop de
papiers et entendons trop de discours qui
n’abordent DevOps qu’à travers le petit
bout de la lorgnette. Trop nombreux sont
ceux qui limitent DevOps au sujet de
l’automatisation. Ce sont les mêmes acteurs
qui, dans nos entreprises, prennent le sujet de
la transformation DevOps par le seul spectre
de l’outillage, et qui occultent de facto les
autres piliers de la discipline.
Ceux-là pourront adopter les meilleurs outils

d’Infrastructure as Code, de Cloud Computing,
de conteneurisation ou de déploiement
continu ; s’ils ne transforment pas en profondeur
La volonté de mettre un terme au "mur de selon nous, les seuls outils permettant de
la confusion8", qui sépare les études (DEV) briser ce mur.
de la production (OPS), apparaît assez tôt
dans la genèse du mouvement DevOps. En tant que pratiquants de DevOps, nous
C’est la prise de conscience qu’il existe un partageons intimement la croyance que
conflit, alors latent, entre DEV et OPS. Celui-ci le plaisir à travailler ensemble y est pour
impacte la productivité de l’entreprise et nuit beaucoup. Nous trouvons du sens dans le
sérieusement au climat de collaboration, voire "faire ensemble", dans le partage, dans les
au bien-être des collaborateurs. relations humaines de qualité et par dessus
tout, dans le plaisir que nous en retirons
La culture DEV est davantage tournée vers quotidiennement. Ce regain de sens, cette
le changement et l’innovation. Elle se base dynamique collaborative, cet entrain qui nous
sur l’envie de livrer rapidement de nouvelles met en mouvement sont à votre portée, mais
fonctionnalités et s’arme pour cela des derniers pour cela, prenez soin des volets Organisation
frameworks et outils de productivité du marché. et Culture lors de votre transformation DevOps.
A contrario, la culture OPS est orientée service
9 (notamment SLA9). Elle est garante de la
stabilité des systèmes en production. Souvent
considérés comme un centre de coûts, les
OPS doivent vivre avec des budgets en baisse Le mur de la confusion matérialise
tout en faisant plus. Pour cela, ils cherchent à généralement une incompréhension
rationaliser les ressources et les technologies profonde entre DEV et OPS. Elle peut
supportées. Le "mur de la confusion" naît de se concrétiser par un éloignement
ces conflits d’objectifs opposant innovation
physique des équipes (parfois un mur
à rationalisation, changement à stabilité et
les sépare, mais bien souvent une rue
culture DEV à culture OPS.
voire des kilomètres) mais aussi dans
Si le constat du "mur de la confusion" des différences de langage, de termi-
est largement partagé, il n’est que trop nologie, de culture, de rituels ou de
inégalement traité par ceux qui s’intéressent à rythmes de fonctionnement.
DevOps. La transformation de l’organisation,
la mise en œuvre de méthodologies et
l’introduction de nouveaux traits culturels sont,
 L’expression "mur de la confusion" a été rendue populaire en 2010 par Andrew Shafer et Lee Thompson dans l’article de blog fondateur intitulé What is DevOps?
http://dev2ops.org/2010/02/what-is-devops/
"Le service-level agreement (SLA) ou "accord de niveau de service" est un document qui définit la qualité de service, prestation prescrite entre un fournisseur de
service et un client. Autrement dit, il s’agit de clauses basées sur un contrat définissant les objectifs précis attendus et le niveau de service que souhaite obtenir un
client de la part du prestataire et fixe les responsabilités." - source : Wikipedia
Des points de vue différents...
10
DEV (Les développeurs) BIZ (Le métier) OPS (La production)

RAPIDITÉ RAPIDITÉ QUALITÉ STABILITÉ QUALITÉ
STABILITÉ COÛT COÛT
Livrer le plus rapidement Fournir le plus rapidement Garantir la stabilité.
de nouvelles possible des services de
fonctionnalités. qualité au client final. Contrôler la qualité des
changements.
Chercher à innover. Obtenir une qualité de
service sans faille. Chercher à rationaliser.
Culture du changement.
Contrôler les budgets IT. Culture du service (SLA).
L’organisation comme fondation de et les rapports sociaux qui régissent le quotidien

DevOps dans nos équipes informatiques.
DevOps sans le volet organisation n’est pas

Lean, Kanban, "Juste à temps"
DevOps. Le corollaire n’est pourtant pas vrai :
l’organisation sans DevOps se porte très bien, C’est dans les usines de Toyota que sont nées
merci. ces méthodes visant à améliorer la performance
des flux de production et à réduire le Time to
Le mouvement DevOps n’a pour ainsi dire
Market. La philosophie Lean s’inscrit également
aucune antériorité sur ces sujets organisation-
dans une vision long terme privilégiant
nels. Nombreux courants
le développement des
de pensée se sont penchés,
bien avant DevOps, sur des
"DevOps sans personnes plutôt que les
questions comme la pro- le volet organisation objectifs financiers à court
terme. DevOps transpose
ductivité des organisations
n’est pas DevOps." bon nombre de ces principes
ou le bien-être au travail,
au monde de la production
11
par exemple.
logicielle.
Le mouvement DevOps n’a certainement pas
l’ambition de révolutionner les disciplines Les méthodes et pratiques Agiles
traitant de l’organisation. Mais il s’inspire de
modèles pragmatiques qui tirent leurs origines Elles-mêmes très inspirées du courant Lean,
dans des courants divers. elles sont fondatrices pour DevOps. Ainsi,
les valeurs de l’agilité telles que décrites
dans l’Agile Manifesto10, sont parfaitement
La psychosociologie, la théorie des
transposables à DevOps :
organisations, la dynamique de groupe
• Les individus et leurs interactions plus que les
Ces sciences humaines et sociales apportent processus et les outils.
un éclairage anthropologique sur les • Du logiciel qui fonctionne plus qu’une
comportements d’une organisation lorsque cette documentation exhaustive.
dernière est mise sous contrainte. Elles nous • La collaboration avec les clients plus que la
apprennent à décrypter les enjeux du pouvoir, négociation contractuelle.
les motivations, les relations de communication • L’adaptation au changement plus que le suivi
d’un plan.
 Agile Manifesto : http://agilemanifesto.org/iso/fr/manifesto.html.  Scaling Agile Framework : http://www.scaledagileframework.com.  The Unproject

Culture : https://files.app.net/2zwhkjS3J.pdf.  Henrik Kniberg, coach Agile et Lean chez Spotify® et LEGO®.  Site Reliability Engineering: How Google
Runs Production Systems : http://shop.oreilly.com/product/0636920041528.do
Toutefois, ces méthodes et pratiques se

focalisent uniquement sur les phases de
design et de build logiciel et n'abordent pas
les phases de déploiement et d’exploitation
(sur lesquelles DevOps trouve sa légitimité).
Les méthodes de passage à l’échelle de

l’agilité (Scaling Agile)
Les méthodes Agiles s’intéressent au

fonctionnement intérieur de l’équipe alors
que des frameworks comme SAFe (Scaling
Agile Framework11) décrivent une organisation
permettant un déploiement des pratiques
Agiles à l’ensemble de l’entreprise. DevOps
s’inspire de ces modèles pour son passage
12
à l’échelle. Un célèbre cas d’école intitulé
The Unproject Culture12 réalisé par Henrik
Kniberg13, décrit le cheminement réalisé par
Spotify pour se transformer en ce sens.
En complément de ces courants fondateurs,

DevOps trouve des sources d’inspiration dans
les modèles organisationnels de startups
dont certaines sont devenues des Géants
du Web. On peut citer l’exemple de Google
avec la création du métier de "Site Reliability
Engineer14" (SRE). Il s’agit d’une discipline
visant à créer des systèmes ultra-évolutifs et
hautement disponibles en transposant des
pratiques issues de l’ingénierie logicielle au
monde des opérations. Autrement formulé par
ses pionniers, SRE c’est : "ce qui se passe quand
un ingénieur logiciel Google est en charge de
ce qui s’appelait autrefois l’exploitation".
De manière générale, nous préconisons le déploiement

de DevOps en commençant par des applications pas trop
grosses, mais importantes et différenciantes.
PLUS
RAPIDE
Actifs stratégiques SPÉCIFIQUE
et innovations
Unique et différenciant
(perçu comme un atout concurrentiel)
PROGICIEL
13
Commun à toutes
les entreprises du secteur
(perçu comme un atout de production)
SaaS BPO
Commun à toutes
les entreprises
(perçu comme une ressource)
MOINS
CHER
Ressources
Disclaimer : on vous aura prévenu...

Les pratiques DevOps s’appliquent aux petites
et moyennes structures comme les startups,
mais pas exclusivement. De grands groupes
ont déjà franchi le cap et commencent à
adopter – avec succès – tout ou une partie
des pratiques que nous présentons dans les
différents volumes de ce livre.
À ce stade, nous vous mettons en garde

contre une application trop dogmatique ou
systématique qui pourrait être faite de ces
pratiques. L’implémentation, voire la pertinence
de ces dernières dépendent fortement des
enjeux et du contexte dans lesquels vous les
14 appliquez. En effet, DevOps et ses pratiques
ne sont pas la solution unique à appliquer
lorsqu’on est à la recherche d’améliorations.
Prenons l’exemple d’une grande entreprise
disposant d’un progiciel RH pour gérer la
carrière de ses salariés (GPEC) et d’une autre
application développée spécifiquement pour
offrir de nouveaux services différenciants à
ses clients. Le premier système d’information
dispose de faibles enjeux de Time to Market
en comparaison du second. On peut ainsi
aisément décider de n’appliquer en priorité
une organisation DevOps qu’au cas de
l’application différenciante.
L’organisation
au service
des bjectifs
de l’en+reprise
et du collab rateur
Les modèles d’organisation ne sont que des moyens. Ils servent
parfois des objectifs de réduction de coûts, d’autres fois de croissance
ou encore contribuent à la résilience de la structure. Ces modèles
d’organisation fusionnent ou découpent, grossissent ou maigrissent,
rapprochent ou éloignent les groupes d’individus qui forment
l’entreprise. Certains de ces modèles sont équitables car ils sont à
la fois au service des objectifs de l’entreprise et du collaborateur.
DevOps, par exemple, propose des modèles qui permettent de
redonner au collaborateur de l’autonomie, de la responsabilité et de
la clarté dans la finalité son travail.
BIZ, DEV et OPS
partagent les mêmes objectifs
BIZ, DEV et OPS

partagent les mêmes
objectifs
Il n’est pas rare de voir plusieurs mois se un volume complet de notre trilogie au sujet
passer entre le moment où le métier pense des pratiques de qualité dans DevOps.
une innovation et son arrivée effective sur
le marché. DevOps apporte une réponse • L’organisation pour la rendre plus réactive,
intéressante aux entreprises ayant pour enjeu adaptable et autonome. C’est alors que se
18 d’accélérer la mise à disposition de produits brise le "mur de la confusion", réunifiant au
logiciels stratégiques sur le marché. Pour sein d’une même équipe tous les acteurs
arriver à cet objectif, la méthode propose de concourant au succès du produit logiciel.
repenser à la fois : Le travail devient porteur de sens, l’équipe
• Les processus d’ingénierie logicielle et d’in- a désormais un cap, les objectifs sont clairs,
frastructure pour améliorer leur productivité et mesurables et partagés : il faut fournir
ainsi réduire le Time to Market (TTM) et le Time rapidement aux clients un produit logiciel de
to Repair15 (TTR). Livrer plus vite du logiciel en qualité, qui soit testé, stable en production,
production ne doit pas se faire au détriment de maintenable et évolutif. L’entreprise n’en
la qualité au risque d’accroître dangereuse- est que plus compétitive et les membres de
ment le nombre de bugs et d’incidents livrés l’équipe y trouvent également leur compte.
en production. C’est pourquoi nous dédions
 Time to repair : il s’agit du temps moyen pour réparer le composant défaillant d’un système.
Tous les contextes sont-ils favorables
au DevOps ?
Tous les contextes

sont-ils favorables
au DevOps ?
Pragmatisme. C’est le maître-mot lorsqu’il un moment de notre histoire où ont convergé
faudra décider du périmètre de sa transformation des assemblages de pratiques variées –
DevOps. Certaines technologies d’une nouvelles et anciennes – servant la cause
autre époque (mainframe, z/OS, AIX, par d’une même idée : réinventer notre manière
exemple) ou encore certaines applications non de concevoir et opérer un produit logiciel de
20 stratégiques (comme la gestion de la cantine) qualité. Dans DevOps, il est question d’équité,
peuvent assez naturellement être considérées de souplesse, mais aussi de pragmatisme
comme de mauvaises candidates à DevOps. (cette forme d’intelligence qui sait s’adapter
Pour autant, la frontière entre les applications aux dures réalités du terrain).
"DevOps-Ready" et celles qui ne le sont pas
n’est pas si marquée que cela. Alors, nous pourrions formuler ce premier
constat : tous les produits logiciels peuvent
DevOps n’est pas une norme. Ce n’est pas tirer parti d’au moins une pratique DevOps.
non plus une méthodologie ou un processus. Pour autant, il n’est pas souhaitable que tous
Il ne s’agit clairement pas d’une suite d’outils. les produits logiciels bénéficient de toutes les
DevOps, c’est à la fois un courant de pensée, pratiques DevOps.
un agglomérat d’opinions, de convictions et
d’expérience acquises. C’est aussi et surtout,
Retour sur investissement
de DevOps (ROI)
Retour sur
investissement
de DevOps (ROI)
La plupart des grandes entreprises sortent à DevOps sont ainsi utilisées comme des moyens
peine d’une époque considérant le système au service de cette quête de productivité.
d’information comme une entité support des
métiers, à faible valeur ajoutée. Autrement Pour autant DevOps peut-il servir des objectifs
22 dit, une époque où l’informatique était de réduction de coûts ?
uniquement perçue comme un centre de Nos expériences de transformations DevOps
coûts. Le modèle d’organisation alors appliqué nous permettent de faire les constats – parfois
dans ce contexte visait des objectifs de paradoxaux – suivants :
rationalisation et d’efficacité opérationnelle.
Concrètement, la mutualisation des ressources • Contre-intuitivement, DevOps (et l’automa-
et des expertises techniques dans une entité tisation que cela engendre) ne réduit pas la
centrale d’ingénierie d’infrastructure et de masse salariale, mais tend plutôt à l’augmenter
production permettait d’optimiser l’usage de en dédiant à chaque équipe les experts dont
ces ressources et d’espérer une réduction des elle a besoin. Ce point est détaillé plus tard
coûts d’investissement et d’exploitation. dans le chapitre.
Ce modèle rencontre des limites à l’heure de • La transformation vers un modèle DevOps a
la "digitalisation", où une prise de conscience un coût d’entrée non-négligeable (acquisition
collective accorde un nouveau potentiel de de compétences, investissement dans des
valeur dans la technologie. Le produit logiciel plateformes cloud et outils, changements
redevient stratégique pour l’entreprise qui le culturels et organisationnels).
conçoit comme un différenciant de marché.
• La multiplication des environnements de test
L’entreprise cherche alors à se doter des
peut engendrer une augmentation des coûts
moyens lui permettant de produire du logiciel
d’acquisition de licences logicielles et/ou de
plus rapidement et de meilleure qualité. Les
ressources d’infrastructure.
pratiques d’organisation de l’Agilité et de
• La productivité logicielle augmente : le software craftsmanship n’augmentent pas les

temps de fabrication d’une fonctionnalité est coûts sur les moyen et long termes (voir le
réduit, l’équipe DevOps produit davantage de schéma qui suit illustrant l’évolution du coût
fonctionnalités dans un temps identique. de la non-qualité).
• L’investissement dans la qualité logicielle,

l’augmentation de la couverture de test, le
23
MOINS
CHER
MEILLEURE PLUS
QUALITÉ RAPIDEMENT
DEVOPS
CHOISISSEZ-EN 2 MAXIMUM
Illustration du coût de la non-qualité

justifiant l’investissement en tests
(Applied software measurement, Capers Jones, 1996)
Pourcentage
de bugs $16,000
% de défauts
85%
introduits dans
cette phase
% de défauts
$1000 trouvés dans
cette phase
24
$250 Coûts pour

$25 $100 réparer les défauts
dans cette phase
Codage Test Test Test Après
Unitaire Fonctionnel Système Déploiement
En synthèse, lors d’une transformation vers

Insistons sur ce point : le modèle d’organisation
DevOps, l’investissement initial et les budgets
DevOps n’est pas un moyen approprié
de fonctionnement peuvent augmenter au
pour réduire les budgets de fonctionnement
profit d’une productivité logicielle accrue.
IT sur le court terme.
Nous avons la conviction que le calcul d’un ROI
plus détaillé est illusoire tant il est impossible
de calculer le gain d’un TTM accru et la Aucun modèle d’organisation n’est parfait.
valeur d’usage d’une fonctionnalité. Dans un Toutefois, certains modèles sont utiles pour
objectif de comparaison de coûts, cela impose servir un objectif tactique de l’organisation
également de connaître sa propre structure à un instant et un contexte particuliers. Dans
de coûts, ce qui n’est pas toujours acquis ou notre cas, le modèle d’organisation DevOps
évident à faire. se focalise sur le TTM et la qualité.
Alignement des objectifs :
impacts sur l’épanouissement personnel
Alignement des objectifs :

impacts sur l’épanouisse-
ment personnel
Avez-vous déjà fait la rencontre d’un "startuper" ? Penchons-nous sur ce dernier point : le Why16
de l’équipe.
Peut-être avez-vous croisé son regard pétillant
lorsque ce dernier faisait l’éloge de son Il s‘agit ici de faire émerger collectivement un
produit, de son architecture ou de son équipe. manifeste qui synthétise la mission de l’équipe.
26 Peut-être avez-vous eu le sentiment qu’une Parfois appelé Massive Transformation Purpose,
flamme imperceptible animait ce professionnel ce manifeste formalise les ambitions, l’audace
passionné et fier. et les aspirations collégiales de l’équipe. Ce
document qui est fondateur pour le groupe
Peut-être l’avez vous déjà ressentie, vous devient porteur de sens, source d’inspiration
aussi ? Il n’est pas rare de surprendre cette et renforce le sentiment d’appartenance.
forme d’énergie positive dans les organisations
produit de taille réduite, comme les startups
ou les équipes DevOps.
Quel est le mystère de ces équipes où l’on voit

naître et grandir une dynamique donnant Voici par exemple le Why
l’impression d’une osmose parfaite entre l’individu que partagent les Octos :
et l’équipe ? Cette cohésion, cette complicité,
"Nous croyons que l’informatique
voire cet esprit de corps viennent-ils d’une
recette que nous pourrions répliquer ailleurs ?
transforme nos sociétés. Nous savons
que les réalisations marquantes sont
Sans avoir la prétention de répondre à cette le fruit du partage des savoirs et du
question, nous vous proposons (dans un tableau plaisir à travailler ensemble.
page suivante) quelques pistes de réflexion Nous recherchons en permanence
non-exhaustives, issues du fruit de nos expériences. de meilleures façons de faire."
 Concept développé par Simon Sinek, Start with Why : https://startwithwhy.com/
Voici six ingrédients qui nous semblent contribuer

à l’épanouissement de notre équipe :
LES SIX INGRÉDIENTS

DE L’ÉPANOUISSEMENT ILLUSTRATION
D’ÉQUIPE
La boucle de feedback rapide entre

le moment de l’action de son travail "Je vois rapidement le fruit de mon
et le constat de l’impact de sa travail".
contribution sur l’objectif commun.
La satisfaction de contribuer à son "Je vois concrètement l’impact de mon

niveau au succès du produit, travail sur le produit, le chiffre d’affaires,
de l’équipe et de l’entreprise. etc.".
27
Le temps accordé aux relations
humaines de qualité : les espaces "Mes collègues ne sont pas des
de rencontre, les rituels extra- numéros, j’ai pris le temps de les
professionnels, la connaissance des connaître".
membres de l’équipe entre eux.
La culture managériale 3.0 :

"Je sais que je suis épaulé, même si je
la transparence, le droit à l’erreur et
me trompe. Je n’ai peur ni d’essayer,
la liberté d’entreprendre, le partage
ni de rater, ni de le raconter".
des savoirs.
"Je comprends mes camarades,

La culture d’équipe : les codes même ceux qui ne font pas exactement
sociaux de l’équipe, les rituels, le même métier que moi, je sais pour-
le vocabulaire partagé. quoi leur travail est important".
La formalisation de la raison d’être

de l’équipe (Le Why) qui donne le "Je sais à quoi je participe et
sens du travail commun. pourquoi je le fais".
Dev ps : vers
l’auton mie et la
resp nsabilisa+ion
des équipes
L’autonomie et la responsabilisation des équipes sont les secrets
d’une transformation organisationnelle réussie vers DevOps.
Le Larousse définit l’autonomie comme la On parlera par la suite d’ autonomie-

"capacité de quelqu’un à être autonome, à responsable pour désigner la convergence de
ne pas être dépendant d’autrui ; caractère la prise de décision, de la liberté d’action et
de quelque chose qui fonctionne ou évolue de la responsabilité du résultat au sein d’une
indépendamment d’autre chose". Le concept même entité.
d’autonomie repose en réalité sur 3 notions :
• L’auto-gouvernance : le droit et la légitimité

d’agir selon ses règles.
• L’autosuffisance : la capacité
"Donner l’autonomie sans la
d’agir avec ses ressources responsabilité ou la responsabilité
propres.
30
sans l’autonomie, c’est comme offrir
• L’indépendance : la liberté
du moment et du périmètre un hachoir à un bébé."
de l’action.
Ces 3 notions réunies forment pour l’équipe qui

les détient, une véritable liberté d’action.
Toutefois, l’autonomisation de l’équipe ne

suffit pas à l’atteinte des objectifs de DevOps.
L’autonomie sans en assumer les responsabilités
est vouée à l’échec, tout comme la responsabilité
seule, sans autonomie. La liberté d’action doit
s’accompagner du devoir de répondre de ses
actes afin d’éviter les dérives (comme les actes
individualistes ou pouvant desservir l’intérêt de
l’entreprise ou de l’équipe).
PRIMEUR
Pourquoi l’autonomie-responsable
contribue-t-elle aux objectifs de DevOps
Pourquoi l’autonomie-
responsable contribue-t-elle
aux objectifs de DevOps
La véritable ambition de DevOps c’est de vouloir cas, induits par le blocage d’une ressource
un produit logiciel qui soit à la fois de bonne mutualisée, la dépendance à la réalisation
qualité et disponible rapidement pour ses d’une action par une équipe tierce ou les délais
utilisateurs. de prise de décision. Sur ce dernier point, on
peut citer l’exemple des comités d’architecture
32
Alors, comment les modèles d’organisations ou de sécurité qui se positionnent comme
DevOps peuvent-ils nous aider à délivrer des instances centrales d’approbation sur le
plus rapidement du logiciel en production ? chemin critique de chaque nouveau projet.
Principalement en cherchant à supprimer les Ce type de comité est souvent perçu par les
temps d’attente inutiles et en minimisant l’effort équipes comme un frein au Time to Market.
de synchronisation entre équipes.
Ces "pertes de temps", couplées aux interruptions
Le manque d’autonomie des équipes dans fréquentes nécessaires à la synchronisation
une organisation informatique traditionnelle entre équipes, sont la source de nombreuses
est à l’origine d’un gaspillage de temps et frustrations pour les personnes au cœur de
d’énergie considérable. Au cours du cycle de l’action (comme la perte de concentration
vie d’un logiciel, on constate fréquemment, au due au changement fréquent de contexte,
cœur même de l’équipe projet, des phases où ou context switching). Ces irritants affectent
les personnes au cœur de l’action sont dans directement la qualité de l’expérience
l’impasse pour réaliser leur travail. Par exemple, collaborateur et in fine contribuent au climat
les développeurs peuvent être dans l’attente du de tension qui règne souvent entre les équipes
provisionnement d’un serveur par un OPS ou DEV et OPS.
encore de la validation du schéma de sa base
de données par un expert DBA partagé avec L’organisation DevOps, en cherchant à rendre
d’autres équipes. davantage autonomes les équipes, améliore
à la fois sa capacité à livrer rapidement en
Ces temps d’attente sont, dans la plupart des production et le bien-être de l’équipe.
Un seul corps et un seul esprit
pour le produit
Un seul corps
et un seul esprit
pour le produit
"You build it, you run it" (qualité, performance, sécurité, résilience, etc.).
Classique pour une équipe agile qui embarque
Concrètement dans DevOps, l’autonomie-
un Product Owner17 porteur de la vision, mais
responsable pourrait être résumée par la
cela reste bien entendu vrai dans un contexte
célèbre formule de Werner Vogels, VP et CTO
DevOps.
34 d’Amazon : "You build it, you
run it". En prolongeant une 2. La décision de Go/NoGo
dynamique de rapprochement "You build it, en production. L’équipe
déjà entamée par la mouvance
Agile, DevOps termine l’histoire you run it" identifie si elle souhaite partir
en production, quand, et
en créant l’union parfaite comment elle souhaite le
réunissant au sein d’une même équipe le faire. Elle assume collectivement ce choix et
Métier (Biz), les Études (Dev) et la Production surtout ses conséquences, même s’il y a un
(Ops). L’équipe BizDevOps devient autonome risque d’être réveillé la nuit par un incident en
et responsable sur l’ensemble du cycle de vie production.
du logiciel : du Design, du Build et du Run.
3. Les choix technologiques en début ou en
Qu’entend-on par autonomie ? Derrière cette cours de vie du projet (les chapitres suivants
simple réponse : design + build + run, citons traitent notamment des risques associés à
quelques exemples de décisions qui sont de une trop forte gouvernance technologique
la responsabilité entière et unique de l’équipe centralisée).
produit :
4. La liberté dans son auto-organisation, ses
1. La priorisation des fonctionnalités du produit, rituels, ses membres constituants.
mais également de ce qui est non-fonctionnel
 Le Product Owner est un des rôles clés d’une équipe travaillant en mode agile. Il est le représentant des clients et des utilisateurs. Il est autonome et
responsable en ce qui concerne les décisions liées au design du produit logiciel.
Evolution de l’organisation des équipes IT
Maîtrise d’ouvrage
DESIGN
Maîtrise d'œuvre
Équipe Équipe
Agile 1 Agile 2
Équipes
de développement
Équipe
BUILD
Équipe Équipe
DevOps
DevOps DevOps
Ingénierie Ingénierie Service
App. 1 App. 2
des infrastructures des infrastructures Infra. 1
35
Tierce Maintenance
Applicative
RUN
Exploitation
Exploitation
ORGANISATION ORGANISATION ORGANISATION

TRADITIONNELLE AGILE DEVOPS
De l’organisation projet à de faire passer l’organisation d’un modèle

l’organisation produit orienté projet et pools de compétences à un
modèle orienté produit.
DevOps, contrairement à ce que laisse penser
son nom, n’a donc pas seulement vocation à Dans les organisations informatiques tradition-
fluidifier la coopération entre les équipes de nelles, on distingue 2 types d’équipes :
développement et d’exploitation, mais bien
• Le pool de compétences est une équipe • L’équipe produit est proche, dans sa
hiérarchique organisée en silos par composition, de l’équipe projet. Elle a une
compétences ou expertises. Les membres sont durée de vie longue (la durée de vie du produit
interchangeables car ils ont des compétences logiciel). Elle peut être hiérarchique ou non. Les
similaires. Les membres de l’équipe sont membres de l’équipe sont complémentaires
autonomes, ils n’ont pas besoin de se en compétences. L’organisation en produits
synchroniser entre eux pour mener à bien leur logiciels requiert un effort important de
travail. L’objectif de ce mode d’organisation est synchronisation entre ses membres. Les
de rationaliser les compétences et d’optimiser membres sont dédiés à une équipe produit
le taux d’occupation des "ressources". Le à la fois. Ce mode d’organisation favorise
pilotage de ce type de pool de compétences l’autonomie et la responsabilité des équipes
se fait généralement au travers d’outils de au profit d’une productivité accrue sur la
ticketing pour tracer leur activité. réalisation et l’exploitation d’un produit.
Ce gain de productivité a un coût : le panel
• L’équipe projet est une équipe recomposée de compétences nécessaires pour atteindre
à durée de vie temporaire (en général l'autonomie de l'équipe, induit le renforcement
36 jusqu’à la livraison du projet en production, de l'équipe ou la recherche de profils multi-
rarement au-delà), souvent non-hiérarchique. compétents souvent rares sur le marché. Ce
Les membres de l’équipe sont complémentaires mode d’organisation est piloté par la capacité
en compétences. Le mode projet requiert à faire (de l’équipe) et la valeur délivrée pour
un effort important de synchronisation entre l’utilisateur final.
ses membres. Les membres peuvent être
partagés entre plusieurs projets au détriment • La communauté de pratiques est un
de l’autonomie (si besoin d’une même ensemble de personnes qui partagent une
personne dans plusieurs projets au même expertise technique ou méthodologique. Elle
moment). Ce mode d’organisation permet la se réunit régulièrement pour échanger sur ses
construction d’une réalisation complexe et pratiques, faire des revues de code ou de la
multi-compétences sans impact structurel sur veille technologique, par exemple. Elle vise
l’équilibre de l’organisation. Ce mode projet également à réduire l'entropie technologique
est compatible et complémentaire avec les en partageant des retours d’expérience et
équipes organisées en pool de compétences. assure ainsi une forme de cohérence entre
Ce mode d’organisation est piloté par le délai les produits. Une communauté de pratiques
et le budget. est animée par un leader qui prend en charge
l’organisation (rituels réguliers, salle, sujets à
Le passage en mode produit, recommandé aborder, etc.)
dans une organisation DevOps, induit l’arrivée
de deux nouveaux types d’équipes :
Organisation par équipes projets

& pools de compétences
CHEFS DEVELOPPEURS DEVELOPPEURS

ARCHITECTES
DE PROJET FRONT BACK
PROJET 1
PROJET 2
PROJET 3
37
Organisation par équipes feature ou component

& communautés de pratiques
PRODUIT PRODUIT PRODUIT PRODUIT

LOGICIEL 1 LOGICIEL 2 LOGICIEL 3 LOGICIEL N
Communauté de pratiques des Développeurs .NET
Communauté de pratiques des passionnés d’infrastructure
Communauté de pratiques XYZ

Feature Team et Component Team Ainsi une Component Team fournit un produit
logiciel de type "socle" qui est utilisé comme
Pour beaucoup d’entreprises, passer à une
fondation par les Feature Teams. Dans ce
organisation DevOps consiste à transformer
contexte, un composant peut être, par exemple,
les équipes projets Agile en équipes produits
un framework logiciel orienté microservices ou
autonomes sur l’ensemble du cycle de vie du
un service partagé de queuing de messages
produit logiciel. Dans notre vision, DevOps
applicatifs.
s’inspire des méthodologies de passage de
l’agilité à l’échelle (comme SAFe : Scaled Agile Les Feature Teams quant à elles, travaillent sur
Framework) pour proposer 2 types d’équipes des fonctionnalités à valeur cliente (au sens
produits : Agile). Cela peut prendre la forme d’un service
métier destiné aux clients de l’entreprise
• Les Feature Teams, ou équipes orientées
ou de services à destination des utilisateurs
fonctionnalités.
internes à la société. Par exemple, une Feature
• Les Component Teams, ou équipes orientées Team A peut travailler sur un produit de régie
composants. publicitaire sur un site de e-commerce et une
38 autre Feature Team B sur un service de Machine
Le mantra de Conway sur le lien fort entre Virtuelle à la demande (IaaS) à destination de
une organisation et son architecture illustre collaborateurs de l’entreprise.
parfaitement la résurgence de
ces concepts d’architecture
pour distinguer les 2 types "Organizations which design
d’équipes.
systems are constrained to
On retrouve dans SAFe le fait
que l’architecture d’un système
produce systems which are copies
se décline en composants of the communication structures
et en fonctionnalités. Une
fonctionnalité implémente un
of these organizations."
ensemble de comportements Conway’s Law18
du système qui répondent
directement à des besoins de l'utilisateur. Un
composant est un regroupement logique de
fonctions courantes et réutilisables nécessaires
à la mise en œuvre de fonctionnalités.
 Les organisations produisent des systèmes qui calquent les structures de communication de ces organisations.
ARCHITECTURE
Business Business Business

CONSUMER
Application Application
<···> Application
#1 #2 #N
39
WEB API CLI

CLOUD MANAGEMENT PLATFORM
(IAM, service catalog, quotas, tenant management)
API API
PRODUCER
INFRA INFRA INFRA

SERVICE SERVICE SERVICE
<···>
DBaaS CaaS Object
Storage
ORGANISATION
BIZ APP #1 BIZ APP #2 BIZ APP #N
Product Product Product

Owner Owner Owner
<···>
Dev Dev Feature Dev
teams
Ops Ops Ops
40
COMPONENT
SERVICE PORTFOLIO TEAM
Product Dev Ops TEAM

Owner
Service
Owner Service Service
Owner Owner
DBA-Dev
Dev-API Dev-API
DBA-API
Ops Ops
Ops
INFRA SERVICE INFRA SERVICE INFRA SERVICE

DBaaS CaaS Object Storage
Dean Leffingwell (auteur du framework SAFe)

présente ici cette différence entre
Feature et Component teams :
HAUTE
Spécificité technologique
COMPONENT TEAMS
41
MOYENNE
FEATURE TEAMS
FAIBLE
AUCUNE QUELQUES-UNES BEAUCOUP
Nombre d’équipes qui peuvent ré-utiliser le logiciel

Si les Component Teams sont bien nécessaires,

il est néanmoins souhaitable d’en limiter la
quantité. Comme évoqué précédemment, les
composants produits par ces équipes servent
En synthèse, DevOps propose
de bases aux fonctionnalités développées
par les Feature Teams. Bien que cela ait un
de passer d’un modèle
réel bénéfice en matière de réutilisabilité, ceci d’organisation traditionnel en
engendre un couplage technique plus ou moins projet, à un modèle orienté
fort entre le composant et la fonctionnalité. produit où chaque équipe est
Cette dépendance, en synchronisant les en autonomie-responsable
cycles de vie des sous-systèmes, dégrade pour développer un composant
l’autonomie de l’équipe. In fine, il convient de réutilisé ou une fonctionnalité
limiter la prolifération des Component Teams logicielle.
en conservant un ratio théorique idéal de 80 %
de Feature Teams et 20 % de Component
Teams.
42
Le choix de créer une équipe orientée composant
devra se restreindre aux sous-systèmes
hautement spécialisés technologiquement et
à forte réutilisabilité avérée. Pour autant, les
frameworks d’architecture d’entreprise ou les
méthodes d’urbanisation du SI ne semblent
pas avoir réussi à limiter la prolifération –
souvent injustifiée – de composants fortement
couplés et faiblement cohérents d’un point de
vue fonctionnel.
Le passage à l’échelle de l’équipe produit
Le passage à l’échelle
de l’équipe produit
L’équipe DevOps idéale est donc une équipe au monde des startups et des petites
produit. Nous l’avons vu, pour fonctionner, ce entreprises. Pour accompagner la croissance,
type d’équipe a un fort besoin de collaboration il convient d’ajouter autant de Feature Teams
impliquant des synchronisations fréquentes et de Component Teams que nécessaire en
entre les membres de l’équipe. Plus le s’assurant de leur autonomie les unes par
44
nombre de membres de rapport aux autres. Procéder
l’équipe est important, plus au découpage (voire au
cet effort de synchronisation Δ = N(N − 1)/2 redécoupage en cours de
devient chronophage. Les vie des produits) représente
travaux du psychologue par conséquent une activité
J. Richard Hackman sur la dynamique de stratégique à réaliser en continu.
groupe ont montré que le nombre de canaux
de communication interpersonnels croît
de manière exponentielle avec la taille de Two-pizza team : la taille idéale de
l’équipe, rendant la collaboration de plus en l’équipe DevOps
plus inefficace. Pour Jeff Bezos, le PDG d’Amazon, davantage
Ainsi, selon la formule suivante, il n’existe que de communication n’est pas toujours la bonne
15 canaux de communication dans une équipe solution aux problèmes de communication
de 6 de personnes, puis 66 dans une équipe dans les entreprises. En proposant de réduire
de 12 et jusqu’à 1 225 dans une équipe de 50 ! la taille standard des équipes au nombre
Δ = N(N − 1)/2 de personnes pouvant être nourries par
deux pizzas (de taille américaine, précisons),
Voilà pourquoi la collaboration ne passe pas Jeff Bezos réaffirme un fait que les psycho-
à l’échelle au sein d’une même équipe. Mais sociologues connaissent bien : la collaboration
bonne nouvelle, ce n’est pas pour autant est optimale dans des équipes de taille
que l’organisation DevOps doit se cantonner réduite, comprenant entre 5 et 12 personnes.
Mais construire une équipe autonome de taille des compétences pour maintenir l’usine
réduite est plus complexe qu’il n’y paraît... d’intégration et de déploiement continus
mise en place par l’Ops. Une autre stratégie,
Le premier défi consiste à réunir toutes les complémentaire de cette première, a pour
compétences dont a besoin l’équipe pour objectif d’améliorer la résilience des savoirs
être autonome et cela avec un nombre de grâce à des pratiques de binômage (telles que
personnes très réduit. Cela revient bien le pair-programming ou les peer-reviews par
souvent à chercher des moutons à cinq pattes : exemple).
les fameux profils pluridisciplinaires. Ainsi, les
développeurs seront aussi leader technique, Les communautés de pratiques
testeur, architecte logiciel full-stack et les profils
DevOps mixeront les casquettes d’architecte Faire passer DevOps à l’échelle revient à
technique, de développeur d’infrastructure multiplier les équipes produits autant que
as code, d’exploitant, d’ingénieur sécurité, nécessaire (Feature ou Component teams).
système, stockage et réseaux… Ajoutez à cela Toutefois, cela a pour impact de réduire la
une pénurie de ces deux profils sur la marché surface d’échange et de communication entre
45 de l’emploi et vous comprendrez la difficulté les personnes partageant un intérêt technique
pour construire ce type d’équipe. ou méthodologique, et n’appartenant pas à la
même équipe produit. Pour palier ce silotage,
La seconde difficulté commune de ces équipes il est recommandé de créer et d’animer des
réduites est la résilience des compétences. communautés de pratiques transverses aux
Le déséquilibre entre la grande quantité de équipes produits permettant :
compétences et le faible nombre de membres
dans l’équipe peut induire un silotage des • Le partage des bonnes pratiques du métier.
savoirs et savoir-faire entre les personnes. • Le travail sur des sujets transverses (choix
Prenons l’exemple du profil Ops. Dans une outillage, POC, etc.).
équipe de six personnes, il est courant que
ce profil ne soit représenté qu’une seule fois. •
La réalisation de veille technologique ou
Qu’advient-il si cette personne part en congés méthodologique organisée.
ou tombe malade ? Cela met-il le produit et
Les communautés de pratiques se réunissent
l’équipe en péril ?
habituellement lors d’un rituel hebdomadaire
La stratégie usuelle pour atténuer ce risque ou bihebdomadaire d’une demi-journée à date
consiste à "désiloter" les rôles. Il s’agit fixe. En dehors de ce rituel, la communauté
ici de créer des zones de recouvrement vit grâce à des espaces de collaboration
des savoir-faire sur les profils "rares" avec (comme Slack, par exemple). On peut dédier
d’autres membres de l’équipe. Par exemple, le classiquement 5 à 10 % du temps productif
développeur leader technique aura également de l’équipe aux activités de la communauté
de pratiques. Il est recommandé que la

communauté désigne un leader en charge
d’animer la vie du groupe (sans nécessairement
de lien hiérarchique).
Au final, les communautés de pratiques

participent à la maîtrise de l’entropie
technologique de l’entreprise. Si vous savez
qu’il existe une communauté dynamique avec
des compétences et des retours d’expérience
concrets sur une technologie, il y a fort à parier
que cela oriente vos choix techniques au
moment de démarrer un nouveau projet.
46
Pratiques
méthodol giques
& traits culturels
propices
47
à Dev ps
48
Certaines organisations ont un terreau plus fertile que d’autres lorsqu’il

s’agit d’y semer les graines du DevOps. Le modèle machiavélique de
J.P. Kotter sur la conduite du changement (et ses fameuses huit étapes19)
semble ignorer l’importance à accorder aux spécificités culturelles lors
d’une transformation d’organisation. Prendre en compte et agir sur la
culture – ou plutôt les cultures – de l’entreprise est fondamental lors du
déploiement de DevOps.
 Les huit étapes du changements de J.P. Kotter : créer un sentiment d'urgence. Former une coalition. Développer une vision. Communiquer
la vision. Inciter à l'action. Démontrer des résultats à court terme. Bâtir sur les premiers résultats pour accélérer le changement. Ancrer les
nouvelles pratiques dans la culture d'entreprise.
Traits culturels facilitateurs
Traits culturels
facilitateurs
Certaines pratiques managériales peuvent Le premier trait culturel que nous aborderons
faciliter l’adoption de DevOps. Dans ce chapitre, est la culture du partage. La transmission des
nous illustrerons ces éléments de culture par le savoirs entre le senior et le junior ou entre le
biais de trois paraboles : DEV et l’OPS, l’open-data, la transparence, le
management visuel ou encore la contribution
Le savoir, c’est le pouvoir20 au logiciel libre sont autant d’exemples
50 incarnant la culture du partage. A contrario,
"Au quatre coins du monde quatre chercheurs
il existe des pratiques culturelles allant à
travaillent séparément au même objectif :
son encontre, comme la culture du secret,
celui de créer un ordinateur quantique.
la paranoïa sécuritaire, les comportements
Chacun réalise des avancées scientifiques
individualistes ou politiques engendrant
remarquables et développe un savoir qui lui est
la rétention, la division ou le silotage de
propre. Au hasard d’un colloque scientifique,
l’information.
les quatre chercheurs se rencontrent. L’un des
chercheurs, attiré par l'appât du gain, décide
L’inertie du conditionnement
de garder le secret sur ses découvertes et
passe son chemin afin de se remettre au travail
culturel
le plus tôt possible. Les trois autres discutent “Une vingtaine de chimpanzés sont isolés
toute la journée et toute la nuit. C’est alors dans une pièce où est accrochée au plafond
qu’en assemblant – tel un puzzle – leurs savoirs une banane, et seule une échelle permet d'y
respectifs, ils résolvent ensemble les mystères accéder. La pièce est également dotée d'un
quantiques qui permettront la création du système qui permet de faire couler de l'eau
fameux ordinateur. La morale de cette histoire, glacée dans la chambre dès qu'un singe
c’est que les savoirs ne se divisent pas, ils ne tente d'escalader l'échelle. Rapidement, les
s’additionnent pas, mais ils se multiplient chimpanzés apprennent qu'ils ne doivent pas
lorsqu’on les partage." escalader l'échelle. Le système d'aspersion
20 On attribue cette formule au philosophe anglais Francis Bacon.

d'eau glacée est ensuite rendu inactif, mais les passé peut étouffer à feu doux la capacité
chimpanzés conservent l'expérience acquise d’adaptation de l’organisation. Cela explique
et ne tentent pas d'approcher de l'échelle. en partie l'émergence des paradigmes de
Un des singes est remplacé par un nouveau. DevOps chez les Géants du Web, jeunes
Lorsque ce dernier tente d'attraper la banane entreprises sans passif culturel.
en gravissant l'échelle, les autres singes
l'agressent violemment et le repoussent. Errare humanum est,
Lorsqu'un second chimpanzé est remplacé, sed perseverare diabolicum est 22
lui aussi se fait agresser en tentant d'escalader
“Un entrepreneur de travaux publics avait trois
l'échelle, y compris par le premier singe
architectes. Il demanda à chacun de construire
remplaçant. L'expérience est poursuivie jusqu'à
le pont le plus incroyable jamais connu.
ce que la totalité des premiers chimpanzés qui
avaient effectivement eu à subir les douches Le premier, réalisa une étude ambitieuse et
froides soient tous remplacés. Pourtant, les décida de valider la viabilité de son concept
singes ne tentent plus d'escalader l'échelle grâce à une maquette. L’assemblage des
pour atteindre la banane. Et si l'un d'entre eux poutrelles d’acier était trop lourd et fit s’écrouler
51
s'y essaye néanmoins, il est puni par les autres, la maquette. Malgré cela, l’architecte décida
sans savoir pourquoi cela est interdit et en de construire le pont, qui – sans surprise – subit
n'ayant jamais subi de douche glacée.” la même fin que la maquette. Culpabilisant de
cet échec, ce dernier démissionna.
Le théorème du Singe21 illustre l’impact des
décisions du passé sur les comportements Le second architecte ayant eu écho du sort
du futur. En entreprise, certaines règles ou de son collègue ne prit aucun risque et
processus mis en place à juste titre sont à réalisa un pont en pierre commun, dont il
l’origine de situations absurdes, quelques maîtrisait parfaitement la conception. Mais
années plus tard, alors que le contexte a l’entrepreneur, voyant le manque d’audace de
changé. La remise en cause de cet "ordre l’ouvrage blâma l’architecte.
établi" ancré dans la culture d’entreprise,
peut engendrer d’importantes réticences. On Le troisième, attaché à la consigne de son chef,
observe ainsi dans certaines organisations décida de construire un incroyable pont en
un effet de vieillissement de la culture cristal. La fragilité du matériau et l’ambition folle
d’entreprise par le développement d’anticorps du projet ralentirent l’avancée de l’étude. A
au changement. Le poids des règles du chaque nouvelle maquette, le pont s’écroulait.
Sans se décourager, l’architecte documentait
21 Théorème du Singe, source Wikipédia : https://fr.wikipedia.org/wiki/Th%C3%A9or%C3%A8me_du_singe. 22 “Errare humanum est, sed perseverare
diabolicum est” est une locution latine qui signifie “L'erreur est humaine, l'entêtement [dans son erreur] est diabolique”. 23 The Unexpected Benefit
of Celebrating Failure : https://www.ted.com/talks/astro_teller_the_unexpected_benefit_of_celebrating_failure. 24 Voir l’ouvrage Management 3.0 par
Jurgen Appelo : https://management30.com/product/management30/. 25 Post Mortem public lors d'un incident sur GitLab.com :
https://about.gitlab.com/2017/02/01/gitlab-dot-com-database-incident/.
minutieusement les raisons de son échec et • À titre individuel : en se déculpabilisant lors
présentait chaque jour ses apprentissages à de l’échec et en cherchant à apprendre de ses
l’entrepreneur. Ce dernier, malgré les retards, erreurs.
l’encouragea, jusqu’au jour où la maquette
résista aux tests. L’architecte construisit le • Au niveau de l’équipe : en promouvant les
fabuleux pont de cristal et fût récompensé pratiques managériales 3.024, comme la culture
par l'entrepreneur. Le prestigieux prix Pritzker du feedback efficace, l’egoless management
d'architecture lui fut même décerné.” ou la bienveillance collective.
Il y a deux principales leçons à tirer de cette • À l’extérieur de l’organisation : en communi-

histoire : quant publiquement sur ses échecs et les ap-
prentissages qui en sont issus (exemple de
1. Si l’erreur est humaine, post mortem public de
l'entêtement dans son Gitlab25).
erreur est nuisible. Les "Toute personne qui Selon leur taille, leur an-
méthodes d’essai-erreur
sont couramment em-
n’a jamais commis cienneté, ou leur secteur
52
ployées dans la résolution d’erreurs n’a jamais d’activité, les organisations
développent un ADN cultu-
de problèmes complexes
(dans la recherche fonda-
tenté d’innover." rel qui leur est propre. En
mentale, les mathéma- Albert Einstein résumé, on peut citer 5
tiques et également dans traits culturels qui sont des
le développement logiciel). L’échec est donc catalyseurs à l’adoption de
une opportunité d’apprendre (empirisme ap- nouvelles pratiques comme DevOps :
prenant). Il convient dans ce contexte de ne • La transmission des savoirs.
pas sanctionner l’erreur, mais au contraire de la
célébrer (comme le fait Google23 par exemple). • La transparence sur les données.
2. Sans droit à l’erreur, il n’y a pas de prise •

La capacité à remettre en question des
de risque. La peur de l’échec peut être processus ou des règles établies.
naturellement paralysante. Inciter la prise
• Le droit à l’erreur d’apprentissage.
d'initiatives sans culture du "droit à l’erreur"
ne fonctionne pas. • La liberté et l’incitation à entreprendre.
Mieux vaut demander pardon que la
permission. La concrétisation du droit à l’erreur
peut se faire à trois niveaux :
Rythmes & rituels
Rythmes & rituels

Si toutes les organisations n’ont pas une culture mettre à danser. Transformer la culture est une
propice à DevOps, est-il quand même possible affaire de rythme.
de faire changer les choses ?
En sociologie, le rythme social26 est un élément
Transformer la culture d’une organisation n’est fondateur de la vie d’un groupe. Le rythme est
pas trivial. Décentralisée par nature, la culture comme le battement de cœur qui donne vie au
est lourdement enracinée dans l’organisation. groupe. Il synchronise pour chaque individu,
Chaque collaborateur est tel un coffres-forts le mouvement sinusoïdal où s’alternent les
défendant précieusement une sous-partie de phases où le groupe est réuni et celles où il est
54 cette culture. Il est impossible de modifier dispersé. Cette synchronisation pendulaire se
simultanément le contenu de tous les coffre- fait grâce à la mise en place de rituels.
forts. Le hacking de la culture doit se faire
sur un modèle de contagion virale, en faisant Ces rituels sont des espaces réguliers,
changer les comportements localement pour périodiques, normés où se retrouvent les
qu’ils se transmettent de proche en proche. individus d’un groupe pour y négocier les
Dans cette partie, nous nous intéresserons à règles sociales qui le régissent. Redéfinir le
l’impact des rituels, rythmes et cadences pour rythme par le biais de nouveaux rituels est un
injecter le virus du changement dans la culture. moyen efficace pour mettre en mouvement la
culture d’une organisation.
Faites danser l’hippopotame Ceux qui ont cherché à adopter la culture Agile
La culture est tel un hippopotame que l’on savent que la méthode consiste notamment à
voudrait faire bouger. Donnez-lui l’ordre de se redéfinir les rituels de l’équipe. Le découpage
déplacer, cela n’aura aucun effet. Tentez de le du temps de travail en itérations ou sprints,
pousser, c’est une cause perdue car l’animal est la mise en place de stand-up meetings, de
trop lourd. En revanche, donnez-lui à entendre rétrospectives, de backlog-grooming ou encore
le rythme endiablé d’un air de percussions de démonstrations27 sont autant de rituels
brésiliennes et vous verrez le pachyderme se fortement normés, au service d’un nouveau rythme.
26 Voir le courant de pensée du sociologue Emile Durkheim : http://rhuthmos.eu/spip.php?article511

27 Se reporter aux définitions des rituels Scrum : https://fr.wikipedia.org/wiki/Scrum_(Boite_à_outils)
De même que pour l’adoption de la culture

Agile, la transformation vers DevOps change "Imposer des rituels
le rythme, redéfinit les rituels de l’équipe. Pour
cela DevOps s’appuie sur un mouvement de
aux équipes n’est pas
convergence des rituels des deux mondes DEV souhaitable, il faut que
et OPS :
les collaborateurs soient
• Le prolongement des rituels Agiles à
l’ensemble de l’équipe produit DevOps
convaincus de leur
(BIZ+DEV ➔ BIZ+DEV+OPS) : itération, stand- utilité."
up, rétrospective, démonstration, etc.
• L’appropriation de rituels OPS par l’équipe

produit DevOps : post mortem, astreintes
tournantes, gestion des changements et des
problèmes, etc.
55
L’adoption d’une partie de ces rituels par
l’équipe DevOps permet d’optimiser la
qualité de la collaboration en réduisant
la quantité de documentation, en allant à
l'essentiel (timeboxing), en renforçant les
liens interpersonnels et en créant des repères
dans le travail pour qu’il soit plus prévisible,
moins stressant. Ces rituels sont également
de puissants médias pour promouvoir de
nouvelles conventions culturelles comme
l’amélioration continue (rétrospective), le droit
à l’erreur (post mortem), la transmission des
savoirs et la transparence (stand-ups, dojos,
meetups), par exemple. Imposer des rituels
aux équipes n’est pas souhaitable pour autant,
il faut que les collaborateurs soient convaincus
de leur utilité, qu'ils se les approprient et les
adaptent en continu (grâce à la rétrospective).
Ainsi, d’une équipe à l’autre, les rituels et
leurs formes pourront varier et cette diversité
globale s’imposera au profit de l'efficacité
locale.
Management par les pairs
et compagnonnage
Management
par les pairs
et compagnonnage
Pour garantir la résilience des compétences • Lorsque DEV et OPS sont réunis dans la
et des savoirs dans l’équipe, DevOps s’appuie même équipe : les pratiques de binômage
sur des pratiques de compagnonnage et de comme les "peer-reviews" ou encore le
management par les pairs. Elle met ainsi au "pair-working" mélangeant DEV et OPS.
57 centre du quotidien des équipes la transmission Elles consistent à travailler en binôme sur
des savoirs pour se faire grandir mutuellement une même unité de travail, soit de manière
et faire grandir la qualité du produit. synchrone (deux personnes travaillant sur un
même ordinateur) soit de manière séquentielle
Selon la phase de maturité DevOps de (l’un revoit après-coup le travail de l’autre et
l’organisation, on peut promouvoir les pratiques propose des améliorations).
suivantes :
C’est dans l’optique de faire grandir les autres,
• Lorsque les équipes DEV et OPS sont (encore) en leur transmettant le fruit de son expérience,
séparées28 : les pratiques de "Vis ma vie" ou que s’inscrivent ces pratiques DevOps de
de "Shadowing". Elles consistent à partager compagnonnage et de management par les
pendant quelques jours le quotidien d’un OPS pairs.
lorsqu’on appartient aux DEV et vice-versa. Ces
pratiques visent quatre principaux objectifs : la
création de relations interpersonnelles inter-
équipes, la compréhension empathique des
objectifs et contraintes de l’autre, le partage
d’un vocabulaire commun et la transmission
de compétences.
28 Cette étape de maturité a lieu avant que la transformation organisationnelle DevOps n’ait été opérée. Cela reste dans tous les cas une mauvaise pratique
de séparer DEV et OPS. Nous en reparlerons plus loin.

Les anti-patterns
rganisationnels
les plus c urants
Adopter une organisation et une culture DevOps est un processus
complexe qui requiert beaucoup de pragmatisme et de patience.
Toutefois, il existe des pièges récurrents qu’il est possible d’éviter. Dans
les paragraphes qui suivent, nous vous présenterons un petit recueil des
mauvaises pratiques les plus couramment constatées lors de la mise en
œuvre d’organisations DevOps et nous vous montrerons comment les
éviter.
Dépendance de compétences clés
en dehors de l’équipe
Dépendance
de compétences clés
en dehors de l’équipe
Ceci est une histoire vraie. Le directeur des L’autonomie d’une équipe est fragile. Elle peut
systèmes d’information d’un grand groupe aisément être abîmée par une dépendance vis-
industriel décide d’engager son organisation à-vis d’une expertise clé extérieure à l’équipe.
vers DevOps. À cette fin, il identifie 3 projets Ici, le profil OPS est partagé entre trois équipes
61 pilotes comme “cobayes”. Chaque équipe différentes. Compte-tenu des besoins propres
est constituée d’un Product Owner, de 3 à 6 à chaque équipe, il aurait été judicieux de
développeurs et d’un profil OPS. Ce dernier dédier cette expertise à chaque projet pilote.
profil étant difficilement mobilisable dans
l’organisation à cause des nombreux autres Pour éviter cet écueil, il peut être intéressant d’
sujets jugés plus prioritaires, il est partagé entre adopter une vision systémique et organique de
les trois projets pilotes. L’Ops passant d’équipe l’équipe DevOps. Elle est un organisme vivant.
en équipe, ne développe pas de sentiment Pour évoluer et s’adapter à son environnement,
d’appartenance, il ne participe pas aux rituels elle a besoin d’ingérer des ressources
et fait du mieux qu’il peut pour concilier les extérieures (comme des compétences, par
objectifs des différents projets. Malgré cela, il exemple). Ses besoins vitaux changent dans
devient rapidement un goulet d’étranglement, le temps, au gré des challenges techniques
saturé par les besoins des équipes. Il est un ou des nouveaux besoins des utilisateurs. Pour
point de passage obligatoire notamment pour survivre, l’équipe DevOps doit passer d’une
les déploiements en production. Un stock conception minérale, statique, à un modèle
de fonctionnalités s’accumule aux portes de organique et dynamique. En d’autres termes,
la production, sans qu’elles puissent y être la composition des membres de l’équipe doit
déployées – en autonomie – par les projets évoluer dans le temps, en fonction des besoins.
pilotes. La promesse d’amélioration du Time Pour cela, l’équipe a à sa disposition deux
to Market attendue par le DSI n’est pas à la outils simples mais puissants : l’ organigramme
hauteur des espérances. d’équipe et le sociogramme d’itération.
L’organigramme d’équipe est un instantané L'organigramme d’équipe (ci-dessous) est

modélisant une vue des membres à l’intérieur de complété par un sociogramme d’itération
l’équipe et les parties-prenantes, extérieures. (page droite). Ce sociogramme modélise
Rappelons-le, faire partie de l’équipe induit la quantité d'interactions sociales entre les
un engagement proche du temps plein pour membres de l’équipe et les parties-prenantes.
les activités de l’équipe et une participation
assidue aux rituels. L'organigramme est
largement partagé et souvent affiché sur les
murs des bureaux de l’équipe.
62
Organigramme d’équipe
KEHOLDERS
S TA
VOPS TEAM
DE
Brenda Kenny
BDA Manager
Alice Bob
Product Owner Tech Lead
John Eve Mallory

OPS Fullstack Dev OPS
Josh Dan
Security Architect
Brian
System Administrator
Sociogramme
KEHOLDERS
S TA
VOPS TEAM
DE
Brenda Kenny
BDA Manager
Alice Bob
Product Owner Tech Lead
John Eve Mallory

OPS Fullstack Dev OPS
Josh Dan
63 Security Architect
Brian
System Administrator
À chaque fois qu’un membre de l’équipe a ces dépendances sont-elles durables ? Pour
une interaction avec une personne extérieure combien d’itérations encore ?
à l’équipe (demande, requête, question,
échange), ce dernier ajoute une gommette sur • Est-il souhaitable de faire évoluer
le rôle correspondant dans le sociogramme. À l’organisation de l’équipe pour s’approprier
la fin de l'itération, lors de la rétrospective, on cette compétence, ou revoir son mode
identifie les rôles ayant le plus de gommettes d'interaction avec ces rôles ?
et, collectivement, on se pose les questions En ritualisant ainsi l’analyse de ses dépendances
suivantes : vis-à-vis de compétences externes, l’équipe
• Y a-t-il des dépendances fortes avec ces rôles se met en posture proactive pour protéger
extérieurs à l’équipe ? son autonomie, se protéger des interactions
parasites et anticiper l’évolution des compétences
• Au vu des prochaines user stories du backlog, clés nécessaires à sa survie.
Les ennemis de l’autonomie :
les trois anti-patterns
Les ennemis
de l’autonomie :
les trois anti-patterns
La dépendance à une expertise extérieure applications, produits, projets ou organisations
à l’équipe n’est malheureusement pas le sur une même instance. Ainsi, il est presque
seul écueil que l’on rencontre lorsque l’on impossible de garantir des quotas d'utilisation
65 s’intéresse à l’autonomie des équipes produits.sur les ressources partagées (processeur, mé-
On peut citer a minima trois autres pièges que moire, I/O disque, par exemple), de ségréguer
l’on rencontre fréquemment à ce sujet. les espaces logiques par équipe, par projet,
par environnement et d’en
Le premier piège assurer l’étanchéité et la ges-
"La mutualisation de tion appropriée des droits
Le premier piège porte sur
ressources a la fâcheuse d’accès.
la mutualisation de res-
sources clés entre plu-
tendance à lier les cycles Par ailleurs, la mutualisation
sieurs équipes DevOps. de vies des composants qui de ressources a la fâcheuse
Par exemple, il est courant reposent dessus. " tendance à lier les cycles
que pour des raisons de de vies des composants
rationalisation de coûts (de licences ou qui reposent dessus. Prenons l’exemple
d’infrastructure), certaines entreprises imposent de deux équipes DevOps qui partagent un
aux équipes de mettre en commun des res- serveur d’applications en cluster. Suite à une
sources, de cohabiter sur un serveur, de vulnérabilité de sécurité, l’éditeur publie un
partager un environnement de pré-production, patch qui doit être appliqué rapidement sur le
un outil d’intégration continue comme Jenkins cluster. La première équipe, qui dispose d’un
ou encore un cluster de base de données. Ces harnais de tests de non-régression automatisés,
types de ressources n’ont généralement pas valide immédiatement sur l’environnement
été conçues dans une optique multi-tenant – de test que ce patch n’impacte pas le bon
c’est-à-dire en capacité d’accueillir plusieurs fonctionnement de son application.
La seconde équipe, ne disposant pas de tests de leurs produits. Dans l’absolu, la présence
automatisés, mettra plusieurs semaines avant de standard n’est pas une mauvaise chose si
d’arriver à la même conclusion. Alors qu’il elle n’est pas utilisée comme un moyen de pal-
aurait été possible et souhaitable de protéger lier un défaut de compétence interne à l’équipe
l’application de la première équipe de cette ou d’imposer une solution unique comme une
vulnérabilité en installant le patch sur la réponse universelle à tous les besoins. Cette
production aussitôt les tests passés, il aura fallu approche one-size-fits-all trouve rapidement
attendre plusieurs semaines, que la seconde ses limites lorsque l’on cherche à faire des pro-
équipe ait également validé la non-régression. duits sur mesure, de qualité et ayant un Time
In fine, en raison de la mutualisation du cluster to Market véloce.
la seconde équipe a imposé à la première un
rythme qui n’est pas le sien, diminuant par Prenons l’exemple d’une DSI disposant d’un
la même occasion son catalogue de middlewares
autonomie. "sur étagère". Parmi ces
"Une approche one-size- standards, on retrouve deux
Pour éviter d'abîmer l’au-
fits-all trouve rapidement choix possibles en matière
66 tonomie des équipes par de base de données : Oracle
cette mutualisation de res-
ses limites lorsque
et PostgreSQL. Si pour
sources, il est important de l’on cherche à faire répondre à ses contraintes
s’assurer que ces dernières des produits sur mesure, d’architecture, une équipe
supportent parfaitement de qualité et ayant un DevOps souhaite se reposer
une approche multi-tenant Time to Market réduit. " sur une base de données
qui recrée une forme de type NoSQL, il est alors
d’étanchéité et d’autono- légitime que cette dernière
mie (comme le sont la plupart des plateformes puisse faire un choix en dehors du standard,
cloud du marché). comme une base de données Cassandra,
par exemple. En gardant la possibilité de ne
Le second piège
pas choisir le standard, l’équipe préserve son
Le second piège commun porte sur une gou- autonomie régalienne. Toutefois, il existe une
vernance technologique ou méthodologique contrepartie : en prenant cette décision l’équipe
trop assertive, voire dogmatique. L’édiction de doit assumer de nouvelles responsabilités. Elle
standards d’outillage, de normes méthodolo- doit s’assurer de disposer – à l’intérieur de
giques, de développement ou de qualité est l’équipe – de la compétence nécessaire pour
bien trop souvent imposée par des équipes déployer, opérer et maintenir dans le temps
transverses aux équipes DevOps et ceci au dé- la solution choisie. Par la même occasion, elle
triment de leur autonomie locale à faire des se prive de possibles économies d’échelle qui
choix éclairés et contextualisés aux spécificités peuvent exister lorsque l’on se repose sur les
standards (prix de licence négocié, expertise terrain. L’épanouissement individuel et le plaisir

DBA à proximité, réutilisation de scripts, etc.). à travailler n’en sont que boostés.
Rendre aux équipes la liberté de s’organiser, Malheureusement, dans certains grands

de choisir leurs outils ou leurs architectures groupes, il est encore fréquent que les
est nécessaire mais peut parfois poser choix technologiques soient imposés par le
des problèmes à l’échelle. La prolifération management pour des raisons politiques, en
technologique, la multiplication des langages dehors de toute considération pragmatique
de développement, l’hétérogénéité des sur la technologie.
pratiques méthodologiques peuvent limiter
la mobilité des compétences inter-équipe, Le troisième piège
augmenter les coûts (licences, contrats de Le troisième piège est le plus sournois, car
support, etc.) voire complexifier la collaboration il est presque impossible de s’en dépêtrer
entre les équipes. Une des solutions possibles lorsqu’on est tombé dedans. Il s’agit du
pour garder la maîtrise de son système couplage fort pouvant se créer entre les
d’information consiste à rendre attrayants ces architectures de deux produits créant ainsi
67 standards. Cela peut par exemple prendre des interdépendances. Prenons l’exemple
la forme d’une plateforme PaaS offrant des d’une société audiovisuelle qui édite des
services managés à la demande (comme une sites web d’actualités. Pour les besoins d’un
base de données MySQL managée sur AWS nouveau site, la société décide de s’organiser
Relational Database Service). En utilisant en deux équipes produits : l’une développant
ce service standard, l’équipe transfère une une application web de back-office permettant
partie de ses responsabilités d’exploitation aux journalistes de saisir le contenu éditorial et
à la plateforme et se dégage du temps l’autre développant le front-office qui expose
pour produire davantage de valeur pour ses le contenu sur Internet. Pour s’échanger
clients. Le standard devient alors attractif pour ce contenu éditorial, les deux applications
l’équipe. Il est perçu comme un catalyseur qui partagent la même base de données.
facilite le travail et augmente la productivité.
Entre ces deux applications, on constate alors :
Cette liberté retrouvée par l’équipe met fin à de
nombreuses frustrations et incompréhensions • Un couplage d’architecture fort – de niveau
ressenties par les individus et liées à des 629 – sur le composant partagé (l’instance de
choix souvent imposés par une gouvernance base de données) et sur la structure du modèle
centrale qui est parfois dogmatique et de données.
lointaine des réalités opérationnelles du
29 Voir les 7 niveaux de couplage de Pressman : https://fr.wikipedia.org/wiki/Couplage_(informatique).

• Une cohérence fonctionnelle faible (le fait de

devoir faire évoluer conjointement, de manière
synchrone, les deux systèmes pour implémenter
une même fonctionnalité utilisateur : comme
par exemple l’ajout d’images dans un article
par un journaliste).
En d’autres termes, ces deux applications

seront interdépendantes lorsqu’il s’agira
d’implémenter une fonctionnalité à cheval entre
les systèmes ou de faire évoluer le format de
données ou le composant de communication.
Le rythme de sortie d’une fonctionnalité sera
dicté par le plus lent des deux à réaliser sa part
du travail. Les roadmaps produits devenant
ainsi liées, elles imposeront un effort important
68 de synchronisation inter-équipes et finalement
une perte réelle d’autonomie.
Le découpage de son architecture en compo-

sants faiblement couplés, maîtres de leur don-
nées et hautement cohérents d’un point de
vue fonctionnel, est une pratique structurante
à prendre en compte dès la conception de
son système. Cela permet d’éviter par ce biais
d’endommager l’autonomie des équipes30
pour prioriser ses efforts sur ce qui apporte
réellement de la valeur à ses utilisateurs.
30 Corollaire à la loi de Conway : créons des architectures qui servent les objectifs d’autonomie-responsable de nos équipes.
?
Isolation : la distance géographique

comme frein à la collaboration
Isolation : la distance
géographique comme
frein à la collaboration
Dans les organisations traditionnelles, on Cette forme d’évidence appuie l’idée
constate fréquemment que le "mur de la d’une équipe produit qui soit co-localisée,
confusion" qui oppose culturellement les DEV dans un même espace, à portée de voix.
aux OPS peut incarner une réalité physique. Malheureusement, on constate encore
Une porte, une cloison, un étage, un bâtiment, fréquemment que cette réalité n’est pas prise
70
une ville, voire un pays séparent parfois les en compte – comme un facteur essentiel de
équipes. Il est difficile de discerner la causalité : la cohésion – lors de la création d’une équipe
la distance est-elle l’origine ou la conséquence DevOps.
de cette collaboration douloureuse ?
Allen a également démontré32 que la
Pour Thomas Allen , qui a étudié la probabilité
31
multiplication des outils collaboratifs (email,
de communication au sein d’une équipe en chats, etc.) ne résout pas le problème de la
fonction de la distance, le verdict est sans distance dans la probabilité de communication.
appel : ce qui est loin des yeux est loin du cœur. Le cas de certaines communautés open-
Au-delà de neuf mètres, il y a moins d’une source qui sont extrêmement distribuées et
chance sur dix pour que deux collaborateurs productives reste une exception à la règle tant
communiquent au cours de la semaine. le niveau de maturité requis est considérable.
0.25
Probabilité de
communication 0.20
hebdomadaire
0.15
0.10
M 0.05
Distance
20m 40m 60m 80m 100m
31 Thomas Allen, professeur au MIT et auteur de l’ouvrage de référence Managing the Flow of Technology :
https://blog.octo.com/ce-que-la-science-nous-dit-de-la-colocalisation/. 32 Dans son ouvrage The Organization and Architecture of Innovation :

https://www.amazon.com/Organization-Architecture-Innovation-Managing-Technology/dp/0750682361.
RESTAURANT
PRODUITS FRAIS - TOUS NOS PLATS SONT FAITS MAISON
Les limites de l’externalisation

Les limites
de l’externalisation
La plupart des entreprises ont recours Bien que l’externalisation ne soit pas un
à l’externalisation IT sous l’une de ses problème en elle-même, elle peut – dans
nombreuses formes. Que ce soit pour réduire certaines configurations – complexifier
les budgets de fonctionnement, faire face à un l’adoption d’une organisation DevOps.
pic d’activité, avoir un accès ponctuel à une Regardons le schéma ci-dessous qui détaille les
expertise rare ou encore pallier des savoir-faire différents modes d'externalisation traditionnels
72 absents, il est courant de se reposer sur un selon les couches du système d’information :
prestataire.
Les modes traditionnels d’externalisation
Modes d’externalisation par couches

du système d’information BUILD RUN
Applications ESN TMA
Serveur d’applications Base de données Middleware ESN ou Infogérant TMA et/ou Infogérant
Système d’exploitation ESN ou Infogérant Infogérant
Machine Virtuelle Volume disque Ressources Réseau ESN ou Infogérant Infogérant
Hyperviseurs Stockage virtuel Réseau virtuel (SDN) Hébergeur Hébergeur

ou Infogérant ou Infogérant
Serveurs Stockage Réseau d’infrastructure d’infrastructure
Datacenter Energie Climatisation Hébergeur Hébergeur

On constate ainsi qu’il existe un grand nombre traditionnelle et la TMA33, sont des modèles peu
d’acteurs possibles. Une même couche du SI compatibles avec une organisation en équipes
peut être gérée par des contrats de prestations DevOps en autonomie-responsable. Toutefois,
de natures diverses avec des niveaux de avec l'émergence des plateformes de Cloud
responsabilités variables sur le "build" et le et l’évolution des offres des infogérants
"run". spécialistes du Cloud et de certaines ESN34,
on voit se dessiner un nouveau paysage de
Les écueils les plus couramment constatés l’externalisation, davantage compatible avec
sont : DevOps. Ces offres s’appliquent que l’on soit
• Le manque de clarté sur les frontières de dans une stratégie Cloud IaaS (historique,
responsabilités avec le prestataire. basée sur des capacités basiques en réseau,
calcul ou stockage), ou PaaS (type services
• La crise de confiance due à la distance et managés ou conteneurs).
à une relation davantage contractuelle que
collaborative.
73 • La multiplication des acteurs de la chaîne de

valeur et la dissolution des responsabilités :
notamment sur le partage du "build" et du
"run".
• Le problème de souveraineté engendré par

la perte des savoir-faire opérationnels sur les
moyen et long termes.
• La perte de souplesse sur l’évolution de

l’organisation, des méthodes et des processus
(contrats de longue durée).
Les prestations de développements agiles au

forfait ou en centres de services, l’infogérance
33 TMA : Tierce Maintenance Applicative. 34 ESN : Entreprise de Services du Numérique, ou anciennement Société de Services en Ingénierie Informatique
(SSII), est une société de services experte dans le domaine des nouvelles technologies et de l'informatique - source : Wikipedia.
Les modes d’externalisation actuels orientés Cloud IaaS

Applications
ESN
Serveur d’applications Base de données Middleware
Système d’exploitation Infogérant Cloud
Machine Virtuelle Volume disque Ressources Réseau
Cloud Management Platform
Hyperviseurs Stockage virtuel Réseau virtuel (SDN)

Cloud provider (IaaS)
Serveurs Stockage Réseau
74
Datacenter Energie Climatisation
Les modes d’externalisation actuels orientés Cloud PaaS

Applications
ESN
Serveur d’applications Base de données Middleware
Infogérant Cloud
Système d’exploitation
Volume Réseau
Conteneur pour Conteneur pour Conteneur
Orchestrateur de Conteneurs
Cloud provider (PaaS)

Serveurs et OS Stockage Réseau
Datacenter Energie Climatisation

L’équipe DevOps comme proxy entre DEV et OPS
L’équipe DevOps
comme proxy entre
DEV et OPS
Un anti-pattern classique consiste à créer une jours une chose facile : conflits de pouvoir et
équipe DevOps à mi-chemin entre les DEV impacts RH peuvent parfois en résulter. Pour-
et les OPS. Cette équipe est en charge de tant, c’est bien la seule voie possible pour une
l’approvisionnement des environnements, de transformation durable vers DevOps.
l’intégration et des tests de non-régression
76
pour l’ensemble des applications. Il peut
s’agir d’un simple renommage des équipes
historiques QA35 ou Intégration en équipe
DevOps.
Bien que cette solution puisse paraître sédui-

sante au premier abord, car peu impactante Equipe
sur l’organisation, il n’est pas recommandé de Dev 1
s’en inspirer. En effet, ce modèle n’est pas
idéal36 en matière d’autonomie-responsable
des équipes. Ajouter une équipe de média-
tion augmente en réalité la difficulté de la si- Equipe Equipe Equipe
tuation : au lieu d'un problème de frontière OPS DevOps Dev 2
(entre DEV & OPS), nous en avons deux (entre
DEV & DevOps et entre DevOps & OPS). Chan-
ger en profondeur l’organisation n’est pas tou-
Equipe
Dev 3
35 QA : Quality Assurance. 36 Voir les anti-patterns détaillés dans les

paragraphes précédents.
FAR I NE
Implémentation rigide d’ITIL

Implémentation
rigide d’ITIL
Il est indéniable que la méthode ITIL37 a contri- (CAB) préconisé par ITIL. Il s’agit d’un comité
bué à structurer les processus d’exploitation et consultatif ayant pour objectif de valider
de support pour de nombreuses entreprises. l’éligibilité à la production d’un changement
Beaucoup des concepts assemblés dans ce re- ou d’une évolution du SI. En général, ce comité
cueil de pratiques ont apporté clarification et se réunit de manière hebdomadaire ou
rigueur dans des contextes où le run n’était bimensuelle et s’assure que les changements
78 pas toujours au niveau de maîtrise et de qualité candidats à la production sont suffisamment
requis. testés, documentés, conformes aux diverses
règles d’urbanisation du SI et qu’ils ne vont pas
À son origine, ITIL se veut comme un recense- se télescoper entre eux.
ment de bonnes pratiques qui sont connues
comme ayant donné des résultats (positifs) Lorsqu’il s’agit de réduire leur Time to Market,
dans certains contextes pour certaines organi- beaucoup d’entreprises se heurtent aux
sations. L’interprétation qui en est faite donne limites de ce processus. Il faut parfois attendre
régulièrement lieu à des implémentations trop plusieurs jours voire plusieurs semaines pour
rigides et bureaucratiques, ce qui a eu pour ef- autoriser la promotion d'une fonctionnalité en
fet d’enliser les équipes et brider leur capacité production. Un stock de fonctionnalités inutilisées
à livrer rapidement des fonctionnalités ou des s’accumule alors. Dans la vision Lean, le stock
correctifs en production. La version 3 d’ITIL a constitue de la valeur (business) qui n’arrive
pris un virage en intégrant une notion d’amé- pas en production et donc qui ne rapporte pas
lioration continue des processus, mais la mise (encore) d’argent.
en application de cette dernière thématique
reste très en retrait et très théorique. Une des implémentations possibles des
promesses du CAB dans un modèle DevOps
Prenons l’exemple du Change Advisory Board reposerait sur "l’usine d’intégration et de
37 ITIL (Information Technology Infrastructure Library pour “Bibliothèque pour l'infrastructure des technologies de l'information”) est un ensemble
d'ouvrages recensant les bonnes pratiques du management du système d'information - source : Wikipedia.
déploiement continus" ou CI/CD. Cette suite

d’outils permet d’automatiser toute la chaîne
de tests de non-régression intra et inter
applications et va jusqu’à déployer l’application
en production lorsque le niveau de qualité
minimum est atteint. La maîtrise du changement
est garantie (si la couverture de tests
automatiques est suffisante, mais nous aurons
l’occasion d’en reparler dans la suite de cette
trilogie) et il n’aura fallu que quelques minutes
entre le moment du commit du code par le
développeur et sa mise en production effective.
Victoire !
Comme l’adage le suggère, faisons attention

de "ne pas jeter le bébé avec l’eau du bain".
79 Tout n’est pas à jeter dans ITIL. Il faut juste
repenser la manière dont ces processus sont
mis en œuvre dans nos entreprises pour encore
plus d’agilité et de qualité. ITIL reste pour les
adeptes de DevOps un excellent recueil de
toutes les thématiques à adresser pour
préparer son application ou son pan de SI à
être production-ready. La démarche proposée
ici est de travailler à supprimer les opérations
humaines qui interviennent comme des garde-
fous lors de ces processus et de les remplacer
par des opérations automatisées qui
produisent les mêmes résultats avec un niveau
de confiance identique ou supérieur.
D ggy bag
On pourrait résumer les gènes d’une organisation DevOps mature comme un
écosystème d’équipes de taille réduite, colocalisées et en autonomie-responsable
sur l’ensemble du cycle de vie du produit logiciel : du “build” au “run”. Le découpage
de ces équipes est calqué sur celui de l’architecture du SI : en fonctionnalités et en
composants faiblement couplés et fortement cohérents d’un point de vue fonctionnel.
On retrouve au sein de chacune de ces équipes une culture forte, impliquant partage,
amour de la qualité, transparence, liberté d’entreprendre et droit à l’erreur. Les
interactions sociales sont cadencées au rythme des rituels issus des pratiques de
l’agile et du monde de la production.
Les objectifs du collaborateur, de l’équipe et de l’organisation sont alignés : l’équipe
et le produit ne font plus qu’un. L’appropriation individuelle du travail collectif se
fait grâce à des pratiques de binômage et de management par les pairs.
Atteindre ce niveau de maturité est complexe lorsque l’on ne part pas d’une feuille
blanche comme ont pu le faire les Géants du Web. Alors est-il possible de transformer
une entreprise traditionnelle vers ce modèle ? Et par où faut-il commencer ?
Menu
Velouté
de Sponsorship
Ballotine
de Fail Fast
Entremet
« Success Story »
Par où commencer sa transformation ?

Par où commencer
sa transformation ?
Il faut une forme d’humilité (ou de folie) pour humains, soyez-en certain : le jeu en vaut la
s'atteler à une telle transformation. Le chemin chandelle !
est périlleux et semé d'embûches pour un
résultat qui sera – à coup sûr – imparfait. Vous Ayez le bon mandat d’intervention
devrez déraciner les vieilles habitudes pour y Avant de partager avec vous les étapes clés
planter la fragile graine de la culture DevOps. d’une telle transformation, précisons ici qu’il
Vous aurez à l’arroser chaque jour, sans perdre est absolument indispensable de disposer du
83
patience. Vous lutterez sans répit contre les bon mandat dans l’organisation avant de se
anticorps de la résistance au changement, qui lancer.
vous assureront qu’il est urgent de ne rien faire.
Mais, même s’il vous incombera de relever des

dizaines de challenges technologiques et
DSI
Responsable Production Responsable Études

OPS DEV
Ingénierie Département Département Département

Exploitation d’infrastructure Architectes BL x BL y BL z
Serveurs
et Stockage Réseaux Projet x1 Projet x2 Projet y1 Projet z1
Il est malheureusement assez courant que le bition réaliste sur les pratiques que vous pour-
sujet de la transformation DevOps soit porté rez atteindre en cible.
par le responsable des études ou par celui de
la production. Ces derniers n’ont pas autorité Il est important par exemple, de sonder votre
pour transformer l’autre. Par exemple, le maturité sur l’adoption des pratiques agiles
responsable des études n’a pas de levier dans les projets. Si votre organisation est
exécutif pour mobiliser des collaborateurs majoritairement adepte du Cycle en V, il est
OPS dans ses équipes agiles. Une certainement nécessaire d’investir en priorité
transformation avec un tel mandat n’aura pour sur une transformation agile, comme un
conséquence que d’accentuer le fossé déjà prérequis à DevOps. La marche à gravir est
existant entre DEV et OPS. trop haute pour espérer passer directement à
un mode d’organisation DevOps.
Le niveau de mandat minimum se situe alors
auprès du Directeur du Système d’Information Commencez petit et échouez
(DSI) qui a autorité à la fois sur les DEV et sur rapidement
les OPS. Rappelons une évidence ;
84
Ayez conscience de une transformation de
vos forces et de vos "You can’t directly rupture ou en "big bang"
n’est pas souhaitable tant
faiblesses
change culture. ce genre d’approche se
Nous avons largement
insisté sur le risque d’une
But you can change porte mal aux sujets d’or-
ganisation. La culture ne
application trop littérale behavior, and behavior se décrète pas. Sa trans-
des pratiques organisa- formation passe par la
tionnelles. Une transpo-
becomes culture." mise en place de nou-
sition pragmatique doit Lloyd Taylor veaux comportements qui,
être réalisée, avec pour VP Infrastructure, Ngmoco de manière itérative et in-
éclairage, une prise de crémentale, deviendront
recul sur votre contexte, les habitudes de demain.
vos forces et vos faiblesses. Ainsi, avant de
vous lancer tête baissée dans l’action, nous Dès lors, il faut être patient. Vous commencerez
vous recommandons de prendre le temps de par une première équipe DevOps pilote qui
faire un état des lieux des accélérateurs et des vous permettra peut-être de vous offrir votre
freins à une telle transformation (sur les plans premier échec (ou votre premier succès). Dans
organisationnels, RH, culturels, architecturaux un cas comme dans l’autre, vous aurez peu
et technologiques). Ce constat de base vous investi, mais vous aurez appris beaucoup.
permettra par la suite de fixer un niveau d’am-
Créez un terrain de jeu avec vos (DEV et OPS). Dopez ce dispositif en y

propres règles injectant des catalyseurs extérieurs comme
de l’évangélisation aux pratiques DevOps,
Pour cette première équipe, mettez toutes les de la formation, du bootstrap hands-on et du
chances de succès de votre côté. Prenez le coaching méthodologique.
soin de créer un cocon douillet qui la protège
du reste de l'organisation et qui assure un Protégez l’équipe de l’entropie de l’organisation.
niveau élevé d’autonomie-responsable. Soyez Facilitez l’accès aux ressources dont elle
vigilants aux différents pièges énumérés a besoin et filtrez toute forme d'ingérence
précédemment dans les anti-patterns les pouvant perturber le focus ou l’autonomie de
plus courants. Assurez-vous de disposer dans l’équipe. Assurez-vous que l’équipe ritualise
l’équipe de personnes hautement motivées la collaboration et s'améliore en continu,
pour jouer ce rôle de "cobaye". Affinez notamment grâce aux rétrospectives.
l’équilibre des compétences de l’équipe
85
EV BO
ÉVANGÉLISATION
Disséminer largement
BOOTSTRAP
Acquérir les compétences
la vision DevOps pratiques par du binômage
FO CO
FORMATION
Acquérir les compétences
COACHING
Accompagner la montée en maturité
théoriques sur les pratiques méthodologiques
Passez à l’échelle viralement d’équipe DevOps, peuvent aller dans ce sens.

C’est ainsi, au gré des espaces de rencontre,
Au bout d’un certain nombre d’itérations, vous des recrutements, des rotations d’équipe que
aurez la chance de constater que l’équipe se diffusera – semaine après semaine – le virus
pilote a gagné en maturité sur les pratiques de la culture DevOps.
DevOps. Peut-être observerez-vous que
l’équipe atteint une certaine constance dans sa 2. La transformation opérationnelle sur le
capacité à livrer de nouvelles fonctionnalités court terme
en production dans un Time to Market que
Dans cette temporalité, on lancera les chan-
vous jugerez honorable. Alors, vous saurez qu’il
tiers permettant de faire évoluer les techno-
est peut-être le moment
logies (cloud computing),
de passer à l’échelle.
de refondre les processus
C’est sur la base de ce "In fine, pour réussir IT et d’acquérir les com-
pétences en vue de lan-
premier succès et du fruit
de l'expérience acquise
cette transformation, cer de nouvelles équipes
86 au fil des échecs que vous il vous faudra rester produits DevOps (sur le
bâtirez la légitimité de même modèle que celui
votre propre modèle d’or-
humble, penser grand, de l’équipe pilote).
ganisation DevOps. Celui commencer petit, 3. La transformation
qui fonctionne dans votre
contexte et que nous ne échouer vite et passer structurelle sur le moyen
terme
pourrions généraliser ici. à l’échelle viralement."
Maintenant, il nous faut Il s’agit ici de réformer
propager ce vent nouveau l’organisation pour l'aplanir.
au reste de l’organisation et cela se fait géné- On change la structure hiérarchique pour passer
ralement en trois temporalités : d’un modèle orienté silos de compétences
DEV / OPS et équipes projets, à un modèle
1. La transformation culturelle sur le long
orienté équipes produits et communautés
terme
de pratiques. Pour moins de rupture dans la
Un bon moyen d’arriver à cette fin est transformation, ce changement peut se faire
d'augmenter la surface de communication "à côté" de l’organisation existante, dans une
entre ceux qui sont porteurs du virus DevOps hiérarchie différente.
et ceux qui ont vocation à le devenir. La mise
en place de communautés d’échange comme
les Meetups, les Brown Bag Lunchs38 (BBL),
ou les immersions comme le "Vis ma vie"
BBL Brown Bag Lunchs
87
38 Les BBL visent à diffuser la connaissance lors d’une session courte sur la pause de midi.
Plus en détails : https://www.infoq.com/fr/articles/bbl-fr.

DevOps :
vivre le bonheur d’avoir pour métier sa passion
DevOps : vivre le
bonheur d’avoir pour
métier sa passion
Nous avons la conviction profonde que malgré auto-organisée, a bâti ses règles, ses rituels,
les difficultés d’une telle transformation, la son identité au profit de ce qui devient dans
promesse faite par DevOps de transformer le temps une véritable culture d’équipe. La
votre métier en passion justifie amplement ce responsabilité collective du succès du produit
qu’il vous en coûtera pour y parvenir. Car oui, la devient notre responsabilité individuelle
89
routine, le désengagement, l’absence de sens, tant nous sommes solidaires dans l’équipe.
la contradiction à nos valeurs, les tensions ou La portée de notre action technique devient
l’individualisme qui règnent parfois dans les directement visible dans sa contribution
équipes IT peuvent être abandonnés au profit aux objectifs de l’équipe, du produit et de
d’une organisation et d’une culture équitables l’entreprise. La boucle de feedback entre
pour chacun et épanouissantes pour tous. notre action et son impact en production
DevOps est une opportunité de prouver qu’il est plus courte. Nous avons donc accès plus
n’y a pas de fatalisme dans nos entreprises facilement à des pistes d'amélioration et
et que nous pouvons – peut-être – vivre le à de la reconnaissance pour ce que nous
bonheur d’avoir pour métier sa passion. réussissons. Nous retrouvons du sens dans
notre travail et dans le "faire ensemble". Nous
Les différents patterns d’organisation DevOps, ne nous épuisons plus dans le multitasking et
s’ils sont couplés aux traits culturels présentés le context-switching car nous sommes focalisés
dans ce livre, forment ensemble les fondations sur notre action et nous ne contribuons qu’à
d’un environnement de travail qui est sain, un seul produit à la fois. Nous avons le temps
bienveillant et sécurisant. de faire du travail de qualité et nous nous
L’appartenance à une petite équipe dont améliorons en permanence. Nous transmettons
nous connaissons personnellement chacun quotidiennement notre connaissance pour
des membres, redonne du poids aux relations faire grandir les autres. Nous sommes une
humaines de qualité. Notre sentiment équipe DevOps, et fiers de l’être.
d’appartenance est fort car notre équipe,
Le mot de la fin :
Remerciements :
Un grand merci à tous les contributeurs et relecteurs : Alban Dalle,
Alexandre Raoul, Arnaud Jacob-Mathon, Arnaud Mazin, Aurélien
Gabet, Christian Faure, Frédéric Petit, Joy Boswell, Ludovic Cinquin,
Nelly Grellier, Nicolas Bordier, Rémi Rey, Salim Boulkour, Victor Mignot
et Yohan Lascombe.
La réalisation de ce livre est le fruit d’une dynamique collective

incroyable qui dure depuis une année entière et qui perdure pour
donner vie aux deux prochains volumes de la trilogie. Ce projet n’aurait
pas pu voir le jour sans le soutien actif d’Eric Fredj, ni sans l’inspiration
et la solidarité dont font preuve chacun des membres de la Tribu OPS
d’OCTO Technology : ALR, AMZ, ARJA, ASI, AUG, BBR, BGA, CHL,
EDE, EFR, EPE, ETC, FRP, FXV, GLE, JGU, KSZ, LBO, MAT, MBO, MBU,
MCY, MDI, MHE, NBO, PYN, RRE, SBO, SCA, TPA, TWI, VMI et YOL.
À propos de l’auteur :
Ce premier volume de la trilogie a été écrit par Edouard Devouge,
consultant DevOps chez OCTO Technology.
La direction artistique et les illustrations sont l’œuvre de Caroline

Bretagne.
"DevOps is a human problem"

Patrick Debois
OCTO Technology
CABINET DE CONSEIL ET DE RÉALISATION IT
« Nous croyons que l’informatique transforme

nos sociétés. Nous savons que les réalisations
marquantes sont le fruit du partage des savoirs et
du plaisir à travailler ensemble. Nous recherchons
en permanence de meilleures façons de faire.
THERE IS A BETTER WAY ! »
– Manifeste OCTO Technology
430
2 PRODUITS
COLLABORATEURS
OCTO EN TÊTE 2 CONFÉRENCES
4x
DU PALMARÈS
IMPLANTATIONS
France
Maroc La conférence tech par OCTO
Suisse
FORMATION
Australie
Dépot légal : Février 2018
Conçu, réalisé et édité par OCTO Technology.
Imprimé par IMPRO
98 Rue Alexis Pesnon, 93100 Montreuil
© OCTO Technology 2018

Les informations contenues dans ce document présentent le point de vue actuel
d'OCTO Technology sur les sujets évoqués, à la date de publication. Tout
extrait ou diffusion partielle est interdit sans l'autorisation préalable d'OCTO
Technology.
Les noms de produits ou de sociétés cités dans ce document peuvent être les
marques déposées par leurs propriétaires respectifs.

OCTO WP DevOps Vol1 Web

Transféré par

Droits d'auteur :

Formats disponibles

OCTO WP DevOps Vol1 Web

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

OCTO WP DevOps Vol1 Web

Transféré par

Droits d'auteur :

Formats disponibles

CULTURE

LES INGRÉDIENTS SECRETS D’UNE ORGANISATION

1. Nous savons qu’il existe des pratiques et des technologies

Les trois histoires de DevOps :

“La vocation, c’est le bonheur

L’organisation au service des objectifs

DevOps : vers l’autonomie

Les anti-patterns organisationnels

Doggy bag 80-89

Pourquoi parler d’organisation dans leurs manières de travailler et leur organisation,

Cette mission est délicate

Ceux-là pourront adopter les meilleurs outils

Des points de vue différents...

DEV (Les développeurs) BIZ (Le métier) OPS (La production)

L’organisation comme fondation de et les rapports sociaux qui régissent le quotidien

DevOps sans le volet organisation n’est pas

 Agile Manifesto : http://agilemanifesto.org/iso/fr/manifesto.html.  Scaling Agile Framework : http://www.scaledagileframework.com.  The Unproject

Toutefois, ces méthodes et pratiques se

Les méthodes de passage à l’échelle de

Les méthodes Agiles s’intéressent au

En complément de ces courants fondateurs,

De manière générale, nous préconisons le déploiement

Disclaimer : on vous aura prévenu...

À ce stade, nous vous mettons en garde

BIZ, DEV et OPS

Tous les contextes

• La productivité logicielle augmente : le software craftsmanship n’augmentent pas les

• L’investissement dans la qualité logicielle,

Illustration du coût de la non-qualité

$250 Coûts pour

En synthèse, lors d’une transformation vers

Alignement des objectifs :

Quel est le mystère de ces équipes où l’on voit

Voici six ingrédients qui nous semblent contribuer

LES SIX INGRÉDIENTS

La boucle de feedback rapide entre

La satisfaction de contribuer à son "Je vois concrètement l’impact de mon

La culture managériale 3.0 :

"Je comprends mes camarades,

La formalisation de la raison d’être

Le Larousse définit l’autonomie comme la On parlera par la suite d’ autonomie-

• L’auto-gouvernance : le droit et la légitimité

Ces 3 notions réunies forment pour l’équipe qui

Toutefois, l’autonomisation de l’équipe ne

Evolution de l’organisation des équipes IT

ORGANISATION ORGANISATION ORGANISATION

De l’organisation projet à de faire passer l’organisation d’un modèle

Organisation par équipes projets

CHEFS DEVELOPPEURS DEVELOPPEURS

Organisation par équipes feature ou component

PRODUIT PRODUIT PRODUIT PRODUIT

Communauté de pratiques des Développeurs .NET

Communauté de pratiques des passionnés d’infrastructure

Communauté de pratiques XYZ

Business Business Business

WEB API CLI

INFRA INFRA INFRA

BIZ APP #1 BIZ APP #2 BIZ APP #N

Product Product Product

1. Nous savons qu’il existe des pratiques et des technologies