Module 1 : Exploring DevOps

Définir DevOps
DevOps est une méthodologie et une culture qui vise à intégrer les équipes de
développement (Dev) et d'exploitation (Ops) pour collaborer de manière plus
efficace et agile.
 Objectif principal : Assurer un flux rapide et constant de travail planifié
vers la production tout en maintenant la stabilité, la fiabilité et la sécurité.
 DevOps est :
o Un "pipeline de livraison de valeur" rationalisé, minimisant le
gaspillage.
o Basé sur des pratiques émergentes et un corpus de connaissances
collectives (CBoK).

Pourquoi DevOps est-il important maintenant ?

Les changements rapides dans le paysage technologique et les attentes des
consommateurs poussent les entreprises à adopter des pratiques DevOps pour
rester compétitives.
 Raisons principales :
o Les start-ups agiles et concurrentes obligent les grandes entreprises
à réagir plus rapidement.
o L'essor du développement logiciel Agile et de l'infrastructure cloud.

o L'adoption croissante de la mentalité des applications par les

consommateurs.
o Besoin d'accélérer le "time-to-value".

o IT doit sortir de sa culture en silos.

Les Valeurs et Objectifs de DevOps

 Valeurs fondamentales : CALMS (Culture, Automation, Lean,
Measurement, Sharing).
 Objectifs :
o Versions plus petites et fréquentes.

o Réduction des coûts, des risques et des efforts liés aux itérations
produit.
 o Amélioration de la communication et de la collaboration entre
équipes.
o Amélioration de la productivité, de la qualité du code et de la
visibilité.

Ce que DevOps n'est pas :

DevOps ne se limite pas à un titre, une équipe, un outil, une culture ou une
automatisation uniquement. C'est une combinaison de plusieurs pratiques qui
créent une réelle valeur ajoutée.

Éléments Uniques de DevOps

Meilleures pratiques :
o Combiner des approches comme Agile, Lean et ITIL.

o Appliquer une pensée systémique pour aligner la culture, les

processus, l'automatisation et les flux de valeur.

DevOps et la pensée systémique

La pensée systémique consiste à considérer l'IT comme un ensemble
interconnecté de systèmes, où chaque composant (processus, équipes, outils,
pratiques) influence les autres. DevOps applique cette approche pour optimiser
l'ensemble de l'écosystème IT et améliorer à la fois la livraison et la gestion des
services.

Composants clés de l'écosystème IT dans DevOps

1. Flux de valeur (Value Stream) :
o Représente la séquence d'activités nécessaires pour concevoir,
produire et livrer un produit ou service.
o DevOps vise à éliminer les gaspillages dans ce flux, réduisant les
délais et augmentant la valeur pour le client.
2. Agilité organisationnelle (Agile & Scrum) :
o La méthodologie Agile et ses pratiques (Scrum, Kanban, etc.) sont
au cœur de DevOps.
o Elles permettent une adaptation rapide aux changements tout en
maintenant un rythme de livraison constant.
3. Culture et personnes (Culture & People) :
o Une collaboration ouverte entre les équipes est essentielle.
 o DevOps favorise une culture de confiance, de transparence et de
responsabilité partagée.
4. IT Service Management (ITSM) :
o Inclut des processus tels que la gestion des incidents, des
problèmes, des changements, et de la configuration.
o Ces pratiques, combinées à l'agilité de DevOps, permettent une
livraison plus rapide et fiable des services IT.
5. Automatisation (Automation) :
o L'automatisation est essentielle pour atteindre la cohérence, la
vitesse et la fiabilité.
o Des pipelines CI/CD (Continuous Integration/Continuous
Deployment) automatisent les tests, les déploiements et les
configurations.

IT comme un "Système de systèmes"

L'IT est composée de plusieurs sous-systèmes interconnectés. Voici un aperçu
des principaux éléments de ce système :
1. Livraison continue (Continuous Delivery/Deployment) :
o Assure que les logiciels sont toujours prêts pour le déploiement en
production.
o Cela réduit les risques et les coûts associés aux versions logicielles.

2. Tests et intégration continue (Test & Continuous Integration) :

o Les tests automatisés et l'intégration régulière du code permettent
de détecter et de résoudre rapidement les problèmes.
3. Gestion des changements et configuration (Change &
Configuration Management) :
o Garantit que toutes les modifications sont suivies, documentées et
alignées avec les objectifs de l'organisation.
4. Stratégie et design des services (Service Strategy & Design) :
o Inclut la planification stratégique et la conception des services pour
répondre aux besoins actuels et futurs.
5. Opérations et transition des services (Service Operation &
Transition) :
o Gestion des événements, des incidents, et des problèmes pour
assurer la continuité et la disponibilité des services.
6. Ingénierie de la fiabilité du site (Site Reliability Engineering) :
 o Combine les pratiques d'ingénierie et d'opérations pour créer des
systèmes hautement fiables et évolutifs.

Alignement des processus et de l'automatisation

Pour obtenir une agilité organisationnelle, il est crucial d'aligner les processus
(ITSM, Agile) avec l'automatisation. Cet alignement garantit :
 Une meilleure visibilité des flux de travail.
 Une réduction des erreurs humaines grâce à des processus automatisés.
 Une collaboration accrue entre les équipes grâce à des outils partagés.

Discussion : Mythes vs Réalités

 Objectif : Éclaircir les idées fausses courantes sur DevOps en expliquant
ce qu'il représente réellement. Par exemple :
o Mythe : DevOps est uniquement une question d'outils ou
d'automatisation.
o Réalité : DevOps est avant tout une culture et une méthodologie
combinant collaboration humaine et techniques pour améliorer les
performances organisationnelles.

Objectifs de DevOps
1. Livraisons plus fréquentes et plus petites :
o Les itérations plus courtes permettent de déployer rapidement des
fonctionnalités ou des correctifs.
2. Réduction des efforts et des risques :
o L'automatisation et les tests continus réduisent les erreurs humaines
et les problèmes liés aux changements.
3. Diminution des coûts liés aux itérations et aux retards :
o Une meilleure gestion des processus et des outils réduit les
gaspillages.
4. Culture de communication et de collaboration :
o L'accent est mis sur une communication ouverte entre les équipes
de développement, d'exploitation, et autres parties prenantes.
5. Améliorations spécifiques grâce à DevOps :
o Réduction du "Time-to-Market" et amélioration de la "Time-
to-Value" : livraison rapide et création de valeur immédiate.
 o Qualité et productivité accrues : grâce à des tests automatisés
et des processus intégrés.
o Visibilité et agilité augmentées : tout le monde a une vue claire
sur le pipeline, ce qui facilite l'adaptation rapide.

Valeurs fondamentales de DevOps (CALMS)

1. Culture : Développer un environnement basé sur la collaboration, la
transparence et la confiance.
2. Automatisation : Automatiser les tâches répétitives pour améliorer la
rapidité et la fiabilité.
3. Lean (Gestion optimisée) : Réduire les gaspillages et maximiser la
valeur pour les clients.
4. Measurement (Mesure) : Évaluer constamment les performances pour
apporter des améliorations continues.
5. Sharing (Partage) : Favoriser le partage des connaissances et des
pratiques.

Automatisation : Élément essentiel

 L’automatisation joue un rôle clé pour assurer :
o Agilité : Réagir rapidement aux changements.

o Cohérence : Maintenir la qualité des livraisons.

o Fiabilité : Réduire les erreurs humaines dans les déploiements.

 Les outils partagés, comme les chaînes d'outils (toolchains), permettent

d'accélérer les livraisons tout en maintenant un haut niveau de
collaboration.

Les parties prenantes de DevOps

 Développement (Dev) : Inclut les architectes, les chefs de projet, les QA,
les gestionnaires de produit, et plus encore.
 Opérations (Ops) : Comprend les ingénieurs systèmes, les
administrateurs de bases de données (DBA), les professionnels de la
sécurité, etc.
 DevOps : Étend cette collaboration au-delà des développeurs et des
opérations, incluant également les équipes de sécurité, de marketing, et
les clients.

Pourquoi DevOps est important

 1. Cadence et rythme de travail :
o Historiquement, les projets étaient gérés selon une approche rigide
(comme la méthode Waterfall), ce qui entraînait des délais et des
inefficacités.
o DevOps harmonise la cadence entre le développement, les
opérations et les besoins métiers.
2. Amélioration de la vélocité et de la stabilité :
o Rapport 2019 sur DevOps :

 Déploiements de code 208 fois plus fréquents.

 Temps d'intégration/déploiement 106 fois plus rapide.
 Temps de récupération après incident 2604 fois plus court.
 Taux d'échec des changements 7 fois plus faible.

Adoption de DevOps
1. Statistiques du rapport GitLab 2019 :
o 89 % des entreprises ayant adopté DevOps ont une meilleure
visibilité sur le travail de leurs collègues.
o 45 % pratiquent des déploiements de code continus.

o Les entreprises les plus avancées intègrent pleinement les pratiques

de sécurité dans leur pipeline DevOps.
2. Avantages clés :
o Alignement des objectifs IT et métiers.

o Élimination des goulets d'étranglement et des inefficacités.

Pourquoi les entreprises adoptent DevOps

Les motivations principales
1. Chaque entreprise devient une entreprise technologique :
o Avec l'essor des technologies numériques, presque toutes les
entreprises, quel que soit leur secteur, doivent s'appuyer sur des
solutions IT pour rester compétitives.
2. Croissance rapide de l’IoT (Internet of Things) :
o L'augmentation des dispositifs connectés génère une grande
quantité de données et de besoins technologiques, nécessitant des
déploiements rapides et efficaces.
3. Mentalité des applications ("App Mentality") :
 o Les consommateurs s’attendent à des expériences utilisateurs
simples, rapides et accessibles via des applications modernes.
4. Importance des résultats pour les clients :
o Les clients ne recherchent plus uniquement des produits, mais les
bénéfices qu’ils apportent. Ils valorisent davantage les résultats
concrets (ex. : économies de temps, facilitation d’une tâche).
5. Remplacement du "Time to Market" par le "Time to Value" :
o Les entreprises ne se contentent plus de lancer rapidement des
produits, mais doivent offrir de la valeur dès les premières
interactions avec le client.
6. Nécessité d’utiliser des données intelligentes pour façonner la
stratégie :
o Les données doivent être analysées et utilisées en temps réel pour
prendre des décisions stratégiques éclairées.
7. Priorité à la satisfaction et à l’émerveillement des clients :
o La satisfaction client est importante, mais créer une expérience
mémorable pour surpasser les attentes des clients est devenu
essentiel.
8. Concurrence accrue des start-ups :
o Les start-ups, agiles et innovantes, constituent une menace pour les
entreprises établies. Adopter des pratiques comme DevOps permet
de rivaliser en termes de rapidité et de créativité.

La valeur commerciale de DevOps

DevOps aide les entreprises à atteindre des objectifs variés, qu'ils soient
financiers, stratégiques ou organisationnels.
1. Objectifs commerciaux clés :
o Profitabilité : Réduction des coûts opérationnels grâce à
l'automatisation et aux processus rationalisés.
o Productivité : Meilleure utilisation des ressources humaines et
techniques.
o Part de marché : Gain de compétitivité grâce à des solutions
rapides et fiables.
o Nombre de clients : Capacité à attirer et fidéliser davantage de
consommateurs.
2. Améliorations spécifiques grâce à DevOps :
o Efficacité opérationnelle : Moins de redondances et une livraison
continue.
 o Satisfaction client : Une expérience utilisateur de meilleure
qualité.
o Qualité des produits/services : Tests continus et déploiements
fiables.
o Objectifs stratégiques : Alignement des priorités IT avec celles de
l’entreprise.

Commencer par le "Pourquoi" – Le cercle d’or (Golden Circle)

L'approche du cercle d’or, popularisée par Simon Sinek, met en avant
l'importance de définir le "pourquoi" avant le "quoi" ou le "comment".
1. Pourquoi (Why) :
o Quelle est la raison d’être de votre entreprise ?

o Quelles sont vos croyances fondamentales ?

o Qu'est-ce qui différencie votre organisation des autres ?

2. Comment (How) :
o Quelles méthodes ou processus utilisez-vous pour atteindre vos
objectifs ?
3. Quoi (What) :
o Quels produits ou services proposez-vous pour répondre aux besoins
des clients ?
En appliquant cette philosophie à DevOps, les entreprises peuvent définir leurs
priorités organisationnelles, aligner leurs équipes et se concentrer sur des
résultats tangibles.

Perspectives IT dans DevOps : Défis et Enjeux

Pourquoi l'IT adopte DevOps ?

1. L'IT est au cœur de toutes les entreprises modernes :
o L'évolution technologique oblige les entreprises à devenir des
entreprises technologiques. Cela inclut des secteurs
traditionnellement non technologiques comme la finance, la santé et
la distribution.
2. Croissance rapide de l'IoT (Internet of Things) :
o L'augmentation des appareils connectés crée des besoins accrus en
termes de traitement des données et d'infrastructures agiles.
3. "Mentalité des applications" des consommateurs :
 o Les consommateurs exigent des expériences fluides, rapides et
personnalisées via des applications modernes, ce qui met la
pression sur les équipes IT pour livrer rapidement des solutions
fiables.
4. Importance des résultats par rapport aux produits :
o Les clients valorisent davantage les résultats tangibles que les
produits eux-mêmes. Cela implique un IT capable de fournir des
solutions rapides et évolutives.
5. Remplacement de "Time to Market" par "Time to Value" :
o L'objectif n'est pas seulement de lancer rapidement des produits,
mais de créer de la valeur immédiatement pour les utilisateurs.
6. Rôle des données intelligentes :
o L'IT doit intégrer les analyses de données en temps réel pour
orienter rapidement les décisions stratégiques.
7. Focus sur l’émerveillement des clients :
o Aller au-delà de la simple satisfaction client en offrant des
expériences exceptionnelles devient un facteur clé de
différenciation.

Défis de l’IT dans l’adoption de DevOps

1. Accélérer sans compromettre la qualité :
o Les entreprises doivent augmenter leur cadence tout en maintenant
la fiabilité et la stabilité de leurs services IT.
2. Investissements limités en valeur de bout en bout :
o Bien que des ressources soient souvent allouées à l'Agile, l'ITSM (IT
Service Management) et l'automatisation, elles ne maximisent pas
toujours leur potentiel dans une chaîne de valeur complète.
3. Limitations de la culture en silos :
o Les équipes (Dev, Ops, QA, sécurité) travaillent souvent en isolation,
ce qui limite la collaboration et la fluidité des processus.
4. Adoption partielle de nouvelles pratiques :
o L'agilité, l'automatisation et les processus ITSM sont utiles mais ne
suffisent pas à eux seuls sans une intégration et une collaboration
holistiques.
5. L'IT comme entité autonome :
o DevOps redéfinit le rôle de l'IT. Ce dernier ne se contente plus de
s'aligner sur les besoins de l'entreprise : l'IT est désormais le
cœur de l'entreprise.
Le Mur de la Confusion (Wall of Confusion)
Un concept clé en DevOps, le "mur de la confusion", symbolise les conflits et
malentendus fréquents entre les équipes :
1. Les développeurs (Dev) :
o Veulent introduire rapidement des changements pour répondre aux
besoins métiers.
o Poussent pour l'innovation et des cycles de livraison rapides.

2. Les opérations (Ops) :

o Se concentrent sur la stabilité, la sécurité et la conformité.

o Peuvent percevoir les changements fréquents comme une menace

pour la fiabilité.
3. Résultat :
o Ces visions contradictoires créent des blocages, des frustrations et
ralentissent le processus global.

Culture des Silos IT

1. Effets des silos :
o Les équipes isolées favorisent les stéréotypes et les
incompréhensions.
o Cette séparation entrave l'innovation continue et la capacité à livrer
des solutions fluides.
2. Impact sur l'innovation :
o La culture des silos limite le partage d'informations et ralentit les
flux de travail.
3. Solution DevOps :
o Encourage une collaboration interfonctionnelle.

o Supprime les barrières organisationnelles pour optimiser la chaîne

de valeur.

Module 2 : Core DeVops Principles

Les Trois Ways constituent la base des principes fondamentaux de DevOps,
définis par Gene Kim dans The Phoenix Project. Ces principes guident la mise en
œuvre des pratiques DevOps dans une organisation.

1. Le Premier Way : Le Flux (Flow)

Comprendre et optimiser le flux de travail de gauche à droite (du développement
à la production).
Objectifs principaux :

 Comprendre le flux de travail :

o Identifier toutes les étapes du processus de développement et de
livraison.
o Repérer les goulots d’étranglement (bottlenecks) qui ralentissent le
flux.
 Optimiser et augmenter le flux :
o Supprimer les contraintes identifiées pour accélérer la cadence.
o S’assurer que le travail passe rapidement et efficacement d’une étape
à l’autre.
 Éviter les erreurs en aval :
o Ne pas transmettre de défauts connus à l'étape suivante (principe de
responsabilité).
o Résoudre les problèmes dès qu’ils sont détectés pour réduire les coûts
de correction.
 Optimisation globale plutôt que locale :
o Une amélioration dans une équipe ou un processus ne doit pas nuire à
l’efficacité globale.

Théorie des contraintes :

 Proposée par Eliyahu M. Goldratt dans The Goal.
 Chaque système a un ou plusieurs goulots d’étranglement (bottleneck) qui
limitent sa capacité globale.
 La solution consiste à :
o Identifier ces contraintes.
o Les améliorer ou les éliminer.
o Répéter ce processus jusqu'à ce qu’un autre goulot apparaisse.

Exemples de contraintes courantes :

o Retards dans le développement.

o Environnements de test ou de production complexes à configurer.

o Déploiements lents ou bureaucratiques.

o Processus complexes ou rigides.

o Évaluations de sécurité ou de qualité trop longues.

Résultat attendu : Le travail doit "couler" rapidement et efficacement à
travers toutes les étapes du système, du développement à la livraison en
production, sans interruption inutile.

2. Le Deuxième Way : Les Boucles de Rétroaction (Feedback)

Le Deuxième Way se concentre sur la mise en place de boucles de rétroaction
courtes et continues entre toutes les parties prenantes (de droite à gauche).
L’objectif est de détecter rapidement les problèmes, d’y répondre efficacement,
et de partager les connaissances nécessaires.

bjectifs principaux :

 Comprendre les besoins de toutes les parties prenantes :

o Clients internes (développeurs, QA, support) et externes (utilisateurs
finaux).
o Assurer que leurs besoins sont bien compris et pris en compte.

 Réduire et amplifier les boucles de rétroaction :

o Fournir des retours d’information rapidement pour permettre des
corrections en continu.
o Par exemple : des tests automatisés qui signalent instantanément les
erreurs.

Créer et intégrer la connaissance là où elle est nécessaire :

o Les informations doivent être accessibles et compréhensibles pour
tous.
Exemples de boucles de rétroaction :
 Tests automatisés.
 Revues de code par les pairs.
 Données de surveillance et gestion des événements.
 Journaux de production et tableaux de bord.
 Analyses post-mortem pour apprendre des incidents.
 Données issues de la gestion des changements et des incidents.
Bénéfices :
 Les corrections peuvent être effectuées en continu.
 La collaboration entre équipes est renforcée.

Résultat attendu : Une meilleure réactivité face aux problèmes et une

amélioration continue des processus grâce à des retours d’information rapides.

3. Le Troisième Way : Expérimentation et Apprentissage Continu

Le Troisième Way vise à instaurer une culture organisationnelle qui encourage
l’innovation, la prise de risques, et l’apprentissage constant. Il s'agit de voir les
erreurs comme des opportunités de progression.
Objectifs principaux :
 Encourager l’expérimentation et la prise de risques :
o Tester de nouvelles idées et approches, même si cela implique des
échecs initiaux.
o Par exemple : Organiser des hackathons pour stimuler la créativité.

 Apprendre de ses erreurs :

o Introduire volontairement des pannes (ex. : Chaos Monkey de Netflix)
pour renforcer la résilience des systèmes.
o Documenter et partager les leçons tirées de chaque expérience.

 Pratiquer pour atteindre la maîtrise :

o Répéter les processus pour en améliorer l’efficacité et la précision.

 Améliorer le travail quotidien :

o Développer des rituels qui encouragent l’innovation, comme des
débriefings ou des récompenses pour les efforts innovants.
Exemple : Chaos Engineering
 Netflix utilise Chaos Monkey, un outil qui simule des pannes aléatoires en
production.
 Objectif : Tester la résilience des systèmes et s’assurer qu’ils peuvent
fonctionner sans interruption malgré des défaillances.
Résultat attendu :
Une organisation résiliente, innovante, et capable de s’adapter rapidement aux
changements tout en améliorant ses compétences.

Encourager une Culture d'Apprentissage

1. Éducation continue :
o Former les équipes avec des plans axés sur les compétences.

o Intégrer l’apprentissage dans les processus quotidiens.

2. Expérimentation :
o Utiliser les erreurs comme opportunités d’apprentissage.

o Expérimenter et résoudre des problèmes en équipe.

3. Apprentissage visible :
 o Publier les résultats des apprentissages et succès pour encourager
la progression collective.

Module3 : Key DevOps Practices

Les processus continus (Continuous) sont au cœur de la méthodologie DevOps.

Ils permettent d’automatiser et de rationaliser le cycle de vie du développement
logiciel pour améliorer la qualité, accélérer les livraisons et minimiser les risques.

1. Continuous Testing (Tests continus)

Définition :
Le test continu consiste à exécuter des tests automatisés tout au long du
pipeline de livraison pour fournir un retour immédiat sur les risques liés à une
version candidate.
Caractéristiques clés :
 Automatisation des tests :
o Les tests (unitaires, d'intégration, d'acceptation) sont exécutés
automatiquement dès qu’un changement est introduit dans le code.
 Approche "Shift Left" :
o L’accent est mis sur l’intégration de la qualité dès le début du
processus de développement.
o Cela signifie détecter et résoudre les problèmes avant qu'ils
n'atteignent la production, réduisant ainsi les coûts de correction et
les interruptions.
Avantages :
 Réduction des bugs en production.
 Accélération des retours sur la stabilité et la fonctionnalité du logiciel.
 Moins de travail manuel pour les équipes QA, leur permettant de se
concentrer sur des tâches plus complexes.

2. Continuous Integration (Intégration continue - CI)

Définition :
L’intégration continue (CI) est une pratique où les développeurs commettent
régulièrement (au moins une fois par jour) leur code dans un dépôt partagé.
Chaque commit déclenche un processus automatisé de build et de test.
Caractéristiques clés :
 Validation automatisée :
o Chaque commit est vérifié via un processus de build automatique et
des tests (unitaires, d'intégration).
 Environnements de test proches de la production :
o Les tests sont exécutés dans des environnements simulant la
production pour garantir la validité du code.
 Outils requis :
o Référentiels de contrôle de version (Git).

o Serveurs CI (exemple : Jenkins, GitLab CI/CD).

 Standards de codage cohérents :

o Nécessite une discipline dans l'écriture du code pour éviter les
conflits.
Avantages :
 Détection rapide des erreurs et corrections précoces.
 Réduction des conflits entre les branches de développement.
 Amélioration de la collaboration entre les développeurs.

3. Continuous Delivery (Livraison continue - CD)

Définition :
La livraison continue étend l’intégration continue en s’assurant que le logiciel est
toujours dans un état prêt à être déployé en production.
Caractéristiques clés :
 Pipeline de déploiement :
o Les changements passent automatiquement par un ensemble de
validations (tests, approbations).
 Feedback automatisé :
o Fournit une évaluation constante de l'état de préparation à la
production.
 Priorité à la disponibilité :
o La capacité à déployer en production est priorisée sur le
développement de nouvelles fonctionnalités.
 Déploiements à la demande :
o Les déploiements sont déclenchés par simple clic, minimisant les
délais et les risques.
Avantages :
 Réduction des coûts, du temps et des risques liés à la livraison de petites
mises à jour incrémentales.
 Permet une livraison rapide et fiable.

4. Continuous Deployment (Déploiement continu)

Définition :
Le déploiement continu va au-delà de la livraison continue en déployant
automatiquement chaque changement validé en production, sans intervention
manuelle.
Caractéristiques clés :
 Élimination de l'intervention humaine :
o Les processus entièrement automatisés garantissent des
déploiements immédiats après validation.
 Tests stricts :
o Des pipelines robustes de tests sont nécessaires pour garantir la
stabilité du code déployé.
Avantages :
 Livraison ultra-rapide des fonctionnalités et correctifs.
 Réduction des délais entre le développement et l’utilisation par l’utilisateur
final.

5. Lien entre les pratiques continues

Cycle d’intégration :
 L’intégration continue (CI) permet de construire et tester rapidement les
changements.
 Ces changements validés sont ensuite maintenus prêts pour le
déploiement grâce à la livraison continue (CD).
 Le déploiement continu pousse automatiquement ces changements en
production.

Site Reliability Engineering (SRE)

 Objectif : Créer des systèmes ultra-scalables et fiables en combinant les
tâches de développement et d’exploitation.
 Pratique chez Google :
 o Les ingénieurs SRE passent 50 % de leur temps sur des tâches liées
aux opérations (résolution de problèmes, maintenance) et 50 % sur
des tâches de développement (nouvelles fonctionnalités,
automatisation).

DevSecOps : Sécurité intégrée

 Concept : Tout le monde est responsable de la sécurité.
 Pratiques clés :
o Tests de sécurité intégrés tôt dans le pipeline ("Shift Left").

o Automatisation des audits, tests, et détections.

o Réduction des contraintes de sécurité tout en maintenant un niveau

élevé de protection.

Conclusion : Les bénéfices des pratiques continues

 Qualité accrue : Les tests précoces et fréquents garantissent un logiciel
plus stable.
 Vitesse de livraison : Les automatisations et pipelines rationalisés
accélèrent les livraisons.
 Réduction des risques : Les problèmes sont identifiés et corrigés avant
d’atteindre la production.
 Culture collaborative : Les équipes Dev, Ops et QA travaillent ensemble
dans un cadre transparent et orienté résultats.
Ces pratiques continues représentent le cœur de la méthodologie DevOps, aidant
les organisations à devenir plus agiles, efficaces et résilientes dans un
environnement compétitif.

Module 4 : Business & Technology

Frameworks

Le concept "DevOps Cannot Stand Alone" souligne que DevOps, bien

qu'important, ne peut pas fonctionner de manière isolée. Il doit être intégré avec
d'autres méthodologies et cadres, comme Agile, ITSM (Information Technology
Service Management), et Lean, pour obtenir des résultats réussis. Ces différentes
approches se complètent et permettent de créer un environnement de
développement plus cohérent et plus performant.
Agile et le Manifeste Agile
L'Agile est une approche de développement logiciel qui repose sur un ensemble
de valeurs et de principes qui ont été formulés dans le Manifeste Agile. Ce
manifeste met l'accent sur la flexibilité, la collaboration et la capacité à s'adapter
au changement, plutôt que sur des processus rigides et une documentation
lourde.
Les valeurs du Manifeste Agile :
Le manifeste Agile oppose les éléments suivants, en favorisant ceux de gauche
par rapport à ceux de droite :
1. Individus et interactions plutôt que processus et outils.
o Cela met l'accent sur l'importance des personnes dans le projet
(développeurs, clients, etc.), leur collaboration et leur
communication, plutôt que sur des outils ou des processus formels.
2. Logiciel fonctionnel plutôt que documentation exhaustive.
o L'objectif est de produire des logiciels qui fonctionnent et apportent
de la valeur au client, plutôt que de se concentrer sur la production
d'une documentation exhaustive qui peut être obsolète avant même
que le logiciel ne soit terminé.
3. Collaboration avec le client plutôt que négociation de contrats.
o Il est plus important de travailler avec le client pour répondre à ses
besoins réels, plutôt que de se concentrer sur des contrats stricts
qui peuvent être trop rigides pour s'adapter aux évolutions du
projet.
4. Répondre au changement plutôt que suivre un plan.
o Dans un environnement Agile, l'adaptabilité est essentielle. Plutôt
que de suivre un plan rigide, l'équipe doit être prête à s'ajuster en
fonction des retours du client ou des changements dans le marché
ou la technologie.
Les principes sous-jacents de l'Agile :
Au-delà de "faire Agile", il est plus important de "être Agile" en adoptant des
comportements et des mentalités qui incluent :
 Être centré sur le client.
 Être collaboratif et communicatif.
 Être adaptable face aux changements.
 Être mesurable en évaluant les progrès et les résultats régulièrement.
 Être orienté vers les résultats et réfléchir sur les pratiques pour
améliorer continuellement les processus.

Scrum : Un cadre Agile

Scrum est un des frameworks Agile les plus populaires, particulièrement adapté
pour la gestion de projets complexes et dynamiques.
Rôles dans Scrum :
1. Product Owner : Responsable de la gestion du backlog produit, c'est-à-
dire de définir et de prioriser les fonctionnalités à développer en fonction
des besoins du client.
2. ScrumMaster : Facilite l'application de Scrum, aide à lever les obstacles
et soutient l'équipe.
3. Équipe de développement : Composée de professionnels qui travaillent
ensemble pour livrer les fonctionnalités du produit.
Artéfacts Scrum :
1. Product Backlog : Une liste de toutes les fonctionnalités et exigences à
réaliser.
2. Sprint Backlog : Une liste de tâches que l’équipe doit accomplir durant
un sprint.
3. Increment : La version du produit qui est prête à être livrée à la fin du
sprint.
Événements Scrum :
1. Sprint Planning : Réunion pour planifier le travail à accomplir durant le
sprint.
2. Daily Scrum : Réunion quotidienne de 15 minutes pour suivre
l'avancement du sprint et identifier les obstacles.
3. Sprint Review : Réunion de revue à la fin du sprint pour présenter les
incréments réalisés.
4. Sprint Retrospective : Réunion pour réfléchir sur le sprint passé et
identifier des améliorations.

Scaled Agile Framework (SAFe)

Le Scaled Agile Framework (SAFe) est une méthode pour appliquer les
principes Lean et Agile à l'échelle de l'entreprise. Cela permet de gérer plusieurs
équipes Agile travaillant ensemble sur un même projet. Il repose sur une
approche incrémentale et itérative, tout en intégrant des pratiques Lean dans le
développement logiciel.
DevOps et son lien avec Agile
DevOps est un ensemble de pratiques qui vise à améliorer la collaboration entre
les équipes de développement (Dev) et d'opérations (Ops). Il étend les principes
Agile au-delà du développement logiciel pour inclure l'ensemble du processus de
livraison du service.
Comment DevOps augmente l'agilité :
  Briser les silos : DevOps facilite la collaboration entre les équipes de
développement et d'opérations, permettant une meilleure communication
et une livraison plus rapide.
 Améliorer les contraintes : En travaillant ensemble, les équipes
peuvent identifier et résoudre les problèmes plus efficacement.
 Appliquer les principes Agile à Dev et Ops : DevOps adapte les
principes de travail Agile aux processus d'exploitation, favorisant la
continuité et l'efficacité.
 Automatisation : L'automatisation des tests, des déploiements et des
processus réduit les erreurs humaines et permet des déploiements plus
rapides et fiables.

Gestion des Services Informatiques (ITSM)

IT Service Management (ITSM) désigne l'ensemble des pratiques, processus,
et outils visant à fournir des services informatiques de qualité pour répondre aux
besoins de l'entreprise. ITSM s'assure que les services informatiques soutiennent
et créent de la valeur pour l'organisation en fournissant une gestion structurée et
des processus efficaces pour la gestion des services tout au long de leur cycle de
vie.
Principes fondamentaux de ITSM :
 Objectif : Fournir des services IT qui répondent aux besoins des
utilisateurs et des clients, tout en gérant les coûts et les risques associés.
 Processus clés : ITSM englobe plusieurs processus fondamentaux comme
la gestion des changements (Change Management), la gestion des
incidents (Incident Management), la gestion des problèmes (Problem
Management), la gestion de la configuration (Configuration Management),
et la gestion des versions (Release Management).
 Cycle de vie des services : ITSM soutient le cycle de vie complet des
services, de la stratégie à la conception, la transition, l'exploitation,
l'amélioration continue et la création de valeur.
 Relation avec DevOps : ITSM et DevOps ne sont pas en contradiction
mais se complètent. ITSM permet d'appliquer des pratiques de gestion de
services IT tout en soutenant les objectifs de DevOps de déploiements plus
rapides sans perturbations majeures.

ITIL® : La bibliothèque des meilleures pratiques ITSM

ITIL® (IT Infrastructure Library) est un cadre de bonnes pratiques largement
adopté pour la gestion des services IT. ITIL 4, la dernière version d'ITIL lancée en
2019, met l'accent sur l'intégration des pratiques Agile, DevOps et de
transformation numérique dans la gestion des services IT.
Les composants principaux d'ITIL 4 :
 1. Les Quatre Dimensions : ITIL 4 repose sur un modèle en quatre
dimensions pour garantir que les services IT sont livrés de manière
cohérente et efficace.
o Organisations et personnes : L'importance de la structure
organisationnelle et des compétences des individus dans la
fourniture des services.
o Information et technologie : Les informations et les technologies
doivent être bien gérées et intégrées dans les processus de service.
o Partenaires et fournisseurs : Une gestion efficace des relations
avec les partenaires et fournisseurs est essentielle pour la réussite
des services.
o Flux de valeur et processus : Les processus et flux de valeur
permettent de créer des services qui apportent une réelle valeur
ajoutée au client.
2. Système de Valeur de Service (SVS - Service Value System) : Le
SVS d'ITIL 4 fournit un cadre pour la gestion du cycle de vie du service et
comprend :
o Principes directeurs : Des lignes directrices pour guider la prise
de décision et les comportements dans l'organisation.
o Gouvernance : La manière dont les actions et les décisions sont
surveillées et contrôlées.
o Chaîne de valeur des services : Les activités et processus
nécessaires pour créer de la valeur dans la fourniture des services.
o Amélioration continue : L'amélioration continue des services et
processus pour répondre aux besoins changeants du marché et des
clients.
o Pratiques : Un ensemble de pratiques à suivre pour garantir une
gestion optimale des services.
Pratiques ITIL 4 et leur lien avec DevOps
ITIL 4 identifie un large éventail de pratiques de gestion des services, chacune
ayant une importance particulière dans un environnement DevOps :
1. Pratiques de gestion générale :
o Gestion de la stratégie : Alignement de la stratégie des services
avec les objectifs commerciaux.
o Gestion des portefeuilles : Gestion des différents services
proposés et leur performance.
o Gestion des risques et de la sécurité de l'information :
Garantir la sécurité des services et des données.
o Gestion du changement : S'assurer que les changements sont
correctement gérés pour éviter les perturbations.
 2. Pratiques de gestion des services :
o Conception de service : Création de services qui répondent aux
besoins des utilisateurs tout en respectant les exigences de qualité.
o Gestion de la capacité et des performances : Assurer que les
services peuvent gérer les demandes de manière efficace.
o Gestion des niveaux de service : Suivi des accords de niveau de
service (SLA) pour garantir que les services sont livrés comme
prévu.
3. Pratiques de gestion technique :
o Déploiement et gestion des versions : Processus permettant de
déployer des versions de service tout en minimisant les risques et
les erreurs.
o Gestion des incidents et des problèmes : Résolution des
incidents rapidement et gestion proactive des problèmes sous-
jacents.
o Contrôle du changement : S'assurer que tous les changements
sont bien planifiés, testés et déployés sans affecter la stabilité des
services.

Comment DevOps et ITSM se complètent :

DevOps et ITSM ne sont pas incompatibles. Au contraire, ils peuvent se compléter
pour offrir des services plus rapides et plus fiables :
 DevOps favorise les déploiements rapides et fréquents, mais cela
nécessite des pratiques solides de gestion des services pour garantir la
stabilité et la performance des systèmes en production.
 ITSM fournit une structure solide pour gérer les services tout en
permettant à l'organisation de déployer de manière continue. Les
pratiques ITSM telles que la gestion du changement et la gestion des
incidents aident à assurer que les nouvelles versions déployées ne
perturbent pas l'expérience utilisateur.

Agility in IT Operations
Agile Service Management (Agile SM) Agile Service Management (Agile SM)
est l'application des principes Agile à la gestion des services IT (ITSM). Cela
garantit que les processus ITSM sont conçus de manière à être flexibles et
capables de livrer des services de manière efficace et rapide, en répondant aux
besoins des clients. Cela implique :
1. Adapting Agile practices to ITSM process design : Adapter les
pratiques Agile (comme Scrum, Kanban et Lean) aux processus ITSM pour
créer des processus capables de s'améliorer de manière itérative.
 2. Small, Integrated Increments : Implémenter les processus ITSM par
petites étapes plutôt que par des changements lourds et monolithiques.
Cela permet de recevoir des retours plus rapidement et de s'ajuster en
conséquence.
3. Reflecting Agile Values : Les processus ITSM doivent être conçus pour
refléter les valeurs Agile, telles que la collaboration, la flexibilité et la
rapidité dans la réponse aux besoins changeants des clients.
4. “Minimum Viable” and “Just Enough” Processes : L'objectif est
d'éviter la surcharge de processus. On met en place juste assez de
structure pour fournir de la valeur, sans compromettre la flexibilité ou la
vitesse.
Agile Service Management ne réinvente pas l'ITSM, il modernise l'approche
traditionnelle en se concentrant sur la rapidité, l'agilité et la réactivité.
Lean Thinking in IT Lean IT applique les principes de Lean manufacturing à la
gestion des opérations IT, avec pour objectif de minimiser les déchets et
maximiser la valeur pour le client avec moins de ressources. Le but est de
garantir que chaque action dans le processus ajoute de la valeur et que le travail
inutile soit éliminé.
Sources of Waste : Lean identifie plusieurs types de gaspillage (Downtime), y
compris :
1. Defects : Erreurs ou défauts dans le processus.
2. Overproduction : Produire plus que nécessaire.
3. Waiting : Retards dus à l'attente de l'étape précédente.
4. Non-use : Compétences ou connaissances inutilisées.
5. Transportation : Déplacement inutile des matériaux ou produits.
6. Inventory : Avoir plus de matériaux ou de ressources que nécessaires.
7. Motion : Déplacement inutile de personnes ou d'actifs.
8. Excessive Processing : Faire plus que nécessaire (ex : sur-ingénierie).
L'objectif de Lean est de réduire ces formes de gaspillage pour créer davantage
de valeur pour les clients avec moins de ressources.
Value Stream Mapping La cartographie des flux de valeur (Value Stream
Mapping) est un outil Lean utilisé pour visualiser et analyser le flux de travail et
d'information à travers les processus. Elle permet d'identifier les zones de
gaspillage et de les éliminer pour améliorer l'efficacité et augmenter la valeur
fournie aux clients.
1. Value Stream : Une séquence d'activités nécessaires pour concevoir,
produire et livrer un produit ou un service.
2. Mapping : Cela consiste à suivre le flux de travail et à identifier les étapes
qui n'ajoutent pas de valeur (gaspillage).
 3. Prioritizing Improvements : Une fois le gaspillage identifié, les équipes
peuvent prioriser et mesurer les améliorations pour renforcer la création
de valeur.
Improvement Kata L'Improvement Kata est une approche structurée pour
l'apprentissage et l'amélioration continue. Elle comprend quatre étapes :
1. Plan : Comprendre la vision ou les objectifs à long terme.
2. Do : Évaluer la situation actuelle et identifier ce qui doit être amélioré.
3. Check : Établir la condition cible (l'état futur idéal).
4. Act : Mettre en œuvre des expériences pour atteindre la condition cible
tout en itérant en fonction des retours.
Cette méthode favorise un apprentissage continu et un progrès constant vers les
objectifs à long terme, basé sur des données et des expérimentations.
Safety Culture La culture de sécurité fait référence aux attitudes, croyances et
perceptions partagées par les employés concernant la sécurité en entreprise.
Cela inclut des pratiques telles que :
1. Blameless Postmortems : Se concentrer sur l'apprentissage des
incidents plutôt que de chercher à assigner des responsabilités.
2. Valuing Incidents : Voir les incidents comme des occasions
d'amélioration.
3. Avoiding Single Points of Failure (SPOFs) : Assurer que les systèmes
et processus sont résilients.
La culture d'apprentissage à partir des erreurs est un élément clé pour parvenir à
une amélioration continue.
Learning Organizations Une organisation apprenante est une organisation qui
accorde une grande importance à l'apprentissage et à l'amélioration continue.
Ces organisations :
1. S'engagent à un apprentissage constant et au partage des connaissances.
2. Évitent la stagnation en embrassant de nouvelles idées.
3. Favorisent une culture où les individus peuvent maîtriser leurs
compétences et travailler de manière autonome, ce qui répond aux
motivations intrinsèques des employés.
Continuous Funding Contrairement aux modèles de financement traditionnels,
qui reposent sur des cycles annuels, les organisations Agile préfèrent un
financement continu, flexible et souvent révisé. Ce modèle permet :
1. Frequent Reviews : Une réévaluation régulière des besoins financiers en
fonction des progrès réalisés.
2. Product/Team-Based Funding : Attribuer les financements en fonction
des produits ou des équipes, plutôt que d'un budget fixe.
 3. Venture-Based Funding : Traiter les investissements comme des paris
sur le succès de certaines initiatives.
Cela permet aux organisations de s'adapter plus facilement aux besoins
changeants du marché et d'innover plus rapidement.
En résumé, ce module met l'accent sur l'intégration des principes Agile, Lean et
DevOps dans les opérations IT, en soulignant la nécessité de l'agilité, de
l'efficacité et de l'amélioration continue pour répondre aux besoins de
l'entreprise. En appliquant ces concepts, les organisations peuvent mieux aligner
leurs processus IT avec les besoins des clients et stimuler l'innovation.

Module 5 : Culture, Behaviors &

Operating Models

L'organisational culture (culture organisationnelle) désigne l'ensemble des

valeurs, des croyances et des comportements partagés qui définissent
l'environnement social et psychologique d'une organisation. Cette culture est
souvent invisible mais imprègne chaque aspect de l'organisation, influençant la
manière dont les employés interagissent entre eux, prennent des décisions,
collaborent, et accomplissent leur travail. Selon Lloyd Taylor, vice-président des
opérations IT chez LinkedIn, il est difficile de changer directement la culture d'une
organisation. En revanche, on peut changer les comportements, et à long terme,
ces changements de comportement forgeront une nouvelle culture.

La dette culturelle
Le terme de dette culturelle est utilisé pour décrire les conséquences négatives
résultant du fait d'ignorer ou de repousser les considérations culturelles au profit
d'une croissance rapide ou de l'innovation. Par exemple, dans le cas de
l'informatique, certaines entreprises peuvent accorder une priorité excessive à la
technologie, en mettant de côté des éléments essentiels liés à la culture
organisationnelle, comme la communication ou la collaboration. Cependant, cette
dette peut devenir coûteuse sur le long terme. Dharmesh Shah, le fondateur et
CTO d'une entreprise, explique que les intérêts sur la dette culturelle sont
souvent plus élevés que ceux sur la dette technique.
En d'autres termes, lorsque l'on ignore la culture d'une organisation pour se
concentrer uniquement sur la croissance technologique, cela peut entraîner des
comportements négatifs (par exemple, des silos dans les équipes, des conflits
internes, des inefficacités dans les processus) qui finiront par ralentir l'innovation
à long terme.
Les caractéristiques d'une culture DevOps
Une culture DevOps met l'accent sur des valeurs spécifiques qui favorisent la
collaboration, l'innovation, et l'amélioration continue. Voici quelques-unes
des caractéristiques clés d'une telle culture :
  Vision et objectifs partagés : Les membres de l'organisation ont une
vision commune et des objectifs clairs, ce qui favorise l'alignement et la
collaboration.
 Communication ouverte et honnête : La transparence est essentielle
dans une culture DevOps, où les informations sont partagées librement et
où la communication bilatérale est encouragée.
 Collaboration : L'accent est mis sur la coopération entre différentes
équipes et fonctions, avec une responsabilité partagée pour les résultats.
 Confiance et respect : La confiance mutuelle et le respect sont des
piliers pour encourager un environnement où les employés se sentent
valorisés.
 Prise de risque intelligente et expérimentation : Une culture DevOps
encourage à prendre des risques calculés et à expérimenter de nouvelles
idées pour améliorer les processus.
 Amélioration continue et apprentissage : Les membres de
l'organisation sont encouragés à apprendre de leurs erreurs et à
constamment chercher à s'améliorer.
 Reconnaissance : Les réussites sont célébrées et les employés sont
récompensés pour leur travail et leur engagement.

Le changement culturel : de l'IT à une culture centrée sur le client

Le passage d'une culture IT à une culture plus centrée sur le client constitue
un changement important dans la manière de penser. Dans une culture IT
traditionnelle :
 Les équipes travaillent en silos, avec une séparation claire entre les
différentes fonctions de l'organisation (par exemple, développement,
opérations, etc.).
 La gestion est souvent command and control (basée sur une structure
hiérarchique stricte), avec un contrôle centralisé des processus.
 Les employés sont principalement orientés tâches, se concentrant sur
l'exécution de leur propre travail sans beaucoup d'interaction avec d'autres
équipes.
En revanche, dans une culture centrée sur le client, les équipes sont plus
interfonctionnelles et collaboratives, et l'accent est mis sur les résultats
plutôt que sur les tâches individuelles. Cette transformation implique souvent
une gestion plus responsable et une prise de décision plus proactive, avec une
confiance élevée entre les membres de l'organisation.

Haute confiance vs. Basse confiance

La culture organisationnelle peut être définie par le niveau de confiance entre
les employés et la direction. Dans une organisation à haute confiance :
  Les informations sont ouvertes et accessibles, et la communication
fluide entre les équipes favorise une meilleure collaboration.
 Les erreurs et échecs sont perçus comme des opportunités
d'apprentissage, et les responsables sont ouverts aux feedbacks.
 Les décisions sont partagées et prises de manière collaborative, ce qui
renforce l'engagement des employés.
En revanche, dans une organisation à basse confiance :
 L'information est réservée ou cachée, et la communication est restreinte.
 Les erreurs sont cachées ou ignorées, et il y a souvent un climat de
culpabilité plutôt que de responsabilité partagée.
 Les décisions sont prises de manière top-down, sans véritable
collaboration entre les différentes équipes.

Le modèle Westrum
Le modèle de Westrum classe les organisations en trois types de cultures :
 Pathologique (axée sur le pouvoir) : Dans cette culture, les
informations sont cachées, la communication est réprimée et l'innovation
est découragée. Les responsables évitent les responsabilités et les échecs
sont souvent dissimulés.
 Bureaucratique (axée sur les règles) : Ici, les informations sont parfois
ignorées ou étouffées pour respecter les procédures. L'innovation crée des
problèmes, et les responsabilités sont compartimentées.
 Générative (axée sur la performance) : Ce type de culture encourage
la recherche active d'informations, l'innovation et la prise de risques
intelligents. Les responsabilités sont partagées, et les erreurs sont perçues
comme des occasions d'apprentissage.
Les organisations avec une culture générative sont les plus performantes, car
elles favorisent un environnement où l'information circule librement et où les
employés sont encouragés à collaborer pour résoudre des problèmes complexes.

Le changement et l'adoption
Le changement culturel, en particulier lorsqu'il est lié à l'adoption de pratiques
DevOps, peut être long et difficile. Les résistances au changement sont
normales, car les gens ont tendance à résister à l'idée de modifier leurs
habitudes. Cependant, l'implication des parties prenantes dans le processus de
changement est cruciale. Ceux qui participent activement à la définition des
changements sont plus susceptibles de les accepter.
Le modèle de diffusion des innovations de Rogers décrit comment les
différentes personnes adoptent de nouvelles idées à différents rythmes :
  Innovateurs (2,5%) et adoptants précoces (13,5%) : Ceux qui sont
toujours prêts à essayer de nouvelles idées.
 Majorité précoce (34%) et majorité tardive (34%) : Ceux qui
adoptent une nouvelle technologie ou idée lorsque les preuves de son
efficacité sont plus évidentes.
 Conservateurs (16%) : Ceux qui résistent le plus au changement.

La gestion de la fatigue du changement

La fatigue du changement survient lorsque les employés deviennent
apathiques ou démoralisés à cause des multiples initiatives de changement. Pour
la gérer, il est important de :
 Écouter les préoccupations des employés et les empêcher de se
sentir submergés.
 Communiquer clairement les objectifs des changements et les relier
aux stratégies de l'entreprise.
 Célébrer même les petites réussites, afin de maintenir l'engagement
des employés.
Encourager de nouveaux comportements
Pour installer une nouvelle culture, il est essentiel d'encourager de nouveaux
comportements :
 Utiliser des outils partagés pour faciliter la communication et la
collaboration.
 Organiser des événements internes comme des hackathons ou des
journées DevOps pour renforcer la cohésion des équipes.
 Créer des expériences immersives comme le job shadowing ou les
simulateurs pour favoriser l'apprentissage et la collaboration.

Module 6 : Automation & architecting

DevOps Toolchain

Avantages de l’automatisation
L’automatisation dans DevOps apporte des bénéfices tangibles pour les équipes
de développement et d’opérations :
Supports accélérés et fiables
  Temps de livraison réduits : Les tâches répétitives sont automatisées,
ce qui accélère les processus.
 Publications plus fréquentes et fluides : Permet de publier des
versions logicielles à un rythme soutenu.
 Moins d’erreurs et meilleure qualité : La standardisation des tâches
diminue les risques d’erreurs humaines et améliore la qualité des produits.
Meilleure sécurité et résilience
 Mitigation des risques : L’automatisation intègre des vérifications de
sécurité (scans, tests) tout au long du pipeline.
 Reprise rapide : En cas d’échec, les processus automatisés facilitent une
récupération plus rapide.
Satisfaction des parties prenantes
 Clients et entreprises satisfaits : Un cycle de livraison plus rapide et
des produits de meilleure qualité renforcent la satisfaction.
Déplacement des efforts humains
Les tâches routinières sont déléguées aux machines, permettant aux humains de
se concentrer sur :
 L’analyse des preuves.
 La résolution de problèmes complexes.
 La prise de décision basée sur l’expérience et le jugement.

Terminologies clés
 Artifact : Tout élément produit dans un projet logiciel, comme la
documentation, les fichiers de données ou les modules exécutables.
 API (Application Programming Interface) : Ensemble de protocoles
permettant l’interaction entre différents logiciels ou systèmes.
 Microservices : Une architecture logicielle composée de petits services
indépendants, qui communiquent via des API et qui peuvent être mis à jour
individuellement.
 Virtualisation de l’OS : Technique consistant à diviser un serveur en
environnements isolés (conteneurs) pour éviter les interférences entre
applications.
 Conteneurs : Paquets logiciels autonomes comprenant le code, les
bibliothèques nécessaires, et les configurations pour assurer leur exécution
cohérente.
 Open Source : Logiciels distribués avec leur code source, permettant des
modifications par les utilisateurs.
 Machine Learning : Analyse de données utilisant des algorithmes capables
d’apprendre à partir des données pour fournir des prédictions.
Cloud, Conteneurs et Microservices
 Cloud Computing : Utilisation de serveurs distants pour héberger des
applications, plutôt que des serveurs locaux.
 Microservices et conteneurs : Ces technologies facilitent le
développement, le déploiement et la gestion d'applications en divisant les
systèmes en modules légers et indépendants.
 Avantages pour les performances de DevOps : Les équipes
performantes tirent parti des caractéristiques essentielles du cloud, telles
que l’élasticité et l’automatisation.

Intelligence Artificielle et Machine Learning

L'IA et le Machine Learning sont utilisés pour :
 Analyser de grandes quantités de données et identifier des tendances
complexes.
 Automatiser les boucles de rétroaction.
 Fournir des analyses prédictives pour guider la prise de décision.
Ces technologies augmentent la productivité humaine et offrent une
perspective plus approfondie sur les données.

Pratiques d’Automatisation DevOps

Philosophie des chaînes d'outils (Toolchains) :
 Utiliser un ensemble intégré d'outils spécifiques pour automatiser les
processus de bout en bout, depuis le développement jusqu’au
déploiement.
 Caractéristiques clés :
o Outils partagés : Favorisent la collaboration.

o Auto-service : Les développeurs peuvent rapidement accéder aux

outils sans dépendre d'autres équipes.
o Automatisation intégrée : Facilite les tests, le monitoring, et
l'infrastructure en tant que code (Infrastructure as Code).
 Éviter les outils isolés :
o Les outils qui créent des silos entre les équipes ou les processus
limitent la collaboration et l'efficacité.

Automatisation de la Communication et Collaboration

Comment et pourquoi automatiser ?
 Avantages :
 o Réduction des temps de réponse avec des alertes et des mises à
jour automatiques.
o Amélioration des flux d'informations entre équipes.

o Favorisation de la collaboration entre des équipes fonctionnelles et

inter-fonctionnelles.
 Exemples d'outils :
o Tableaux Kanban : Gestion visuelle des projets.

o ChatOps : Plateformes de communication comme Slack ou

Microsoft Teams pour les alertes et discussions liées au
développement.
o Systèmes de gestion des connaissances : Wikis, outils de
partage de documents pour faciliter la transmission d'informations.
o Backlogs partagés : Favorisent la transparence et la collaboration
dans la gestion des tâches.

Premiers Pas pour Améliorer l’Automatisation DevOps

1. Architecturer avant d’automatiser : Planifiez vos processus et outils
avant de commencer.
2. Simplifier : Ne pas automatiser des processus inefficaces ou mal conçus.
3. Identifier les écarts critiques : Évaluer vos outils actuels et identifier les
domaines nécessitant une amélioration.
4. Automatiser les tâches répétitives et à haute valeur ajoutée :
Concentrez-vous sur les tâches sujettes aux erreurs humaines et
chronophages.
5. Optimiser les goulots d’étranglement : Identifier et résoudre les points
bloquants dans vos workflows.
6. Améliorer le monitoring et les notifications automatiques : Assurez
une visibilité constante sur l’état des applications et infrastructures.
7. Évolution continue : Acceptez que l’automatisation est un processus
itératif. Adaptez et améliorez vos chaînes d’outils au fil du temps.

Chaînes d'outils DevOps (DevOps Toolchains)

Une chaîne d'outils DevOps est un ensemble d'outils intégrés qui soutiennent
l'ensemble du cycle de vie du développement logiciel. Ces outils permettent
l'intégration continue, le déploiement, la livraison et les opérations en
automatisant les tâches et en favorisant la collaboration entre les équipes de
développement et d'exploitation.
Concepts clés des chaînes d'outils DevOps
 1. Pipeline de déploiement (Deployment Pipeline)
o C’est un processus automatisé qui gère les changements depuis
l'ajout de code jusqu'à la mise en production.
o Étapes du pipeline :

 Contrôle de version : Suivre et gérer les modifications de

code avec des outils comme Git.
 Build et tests unitaires : Vérifier que le nouveau code
s’intègre correctement avec l’existant.
 Tests d'acceptation : Valider que les fonctionnalités
répondent aux exigences.
 Tests d’acceptation utilisateur (UAT) : Vérifier que
l’application est prête pour les utilisateurs finaux.
 Approbation de la livraison : Dernière étape avant le
déploiement en production.
2. Automatisation à chaque étape
Chaque étape du pipeline s'appuie sur des outils pour :
o Effectuer des vérifications de qualité.

o Fournir des retours rapides aux développeurs.

o Donner une visibilité sur le flux des changements.

o Automatiser les tâches répétitives et sujettes aux erreurs.

3. Caractéristiques des chaînes d'outils

o Applications interconnectées : Les outils communiquent via des
APIs.
o Écosystèmes variés : Inclut des outils open-source et
propriétaires.
o Personnalisables : Adaptables selon les besoins spécifiques du
projet.
o Architecture pensée : Garantit l’interopérabilité et la cohérence
entre les outils.

Éléments typiques d'une chaîne d'outils DevOps

1. Gestion des exigences : Définir et suivre les besoins du projet.
2. Contrôle de version : Gérer les changements de code (ex. Git).
3. Intégration continue : Processus automatisé de build et de test.
4. Gestion des artefacts : Stocker et gérer les fichiers générés (artefacts).
 5. Conteneurs et virtualisation : Utiliser des outils comme Docker pour
empaqueter les applications avec leurs dépendances.
6. Automatisation des tests : Tests unitaires, d’intégration et
d'acceptation.
7. Déploiement automatisé : Configurer et déployer les systèmes et
serveurs automatiquement.
8. Surveillance : Observer les performances des applications et détecter les
problèmes.

Créer une chaîne d'outils DevOps

1. Modéliser la chaîne de valeur : Identifier les étapes clés du flux de
travail, du développement à la livraison.
2. Automatiser les processus clés : Prioriser les étapes comme la
construction, le déploiement, et les tests.
3. Adopter une approche itérative : Commencer par un petit ensemble
d’outils et ajouter progressivement d’autres fonctionnalités.
4. Personnalisation : Ne pas imposer une structure rigide, mais adapter les
outils aux besoins changeants du projet.
5. Collaboration : Assurer que chaque membre de l’équipe comprend le rôle
de chaque outil pour éviter les redondances ou les lacunes.

Gérer plusieurs applications et chaînes d'outils

 Chaque application peut nécessiter sa propre chaîne d'outils.
 Utiliser des paramètres par défaut raisonnables pour éviter la
duplication des pipelines.
 Adopter une approche architecturale d’entreprise pour coordonner
plusieurs chaînes d’outils.

Module 7 : Measurement, Metrics &

Reporting

a mesure est un pilier fondamental dans les pratiques DevOps, permettant

d'identifier les contraintes, de justifier leur suppression et de surveiller les
améliorations. Peter Drucker a résumé ce principe : "Si vous ne pouvez pas le
mesurer, vous ne pouvez pas l'améliorer." Les métriques DevOps permettent
non seulement de démontrer les avantages pour l'organisation, mais aussi
d'orienter les pratiques vers des résultats mesurables et bénéfiques.
Les Trois Voies et l'Importance de la Mesure
1. Première Voie : Le Flux
o Objectif : Maximiser la rapidité et l'efficacité dans la livraison de
valeur.
o Mesures clés :

 Lead Time : Temps écoulé depuis l'ajout d'une idée jusqu'à

sa livraison en production.
 Cycle Time : Temps de réalisation pour une tâche "En cours"
jusqu'à "Terminé".
 Time to Value : Temps nécessaire pour fournir de la valeur
aux utilisateurs.
 Value Realization : Valeur réellement perçue par les
utilisateurs.
2. Deuxième Voie : Le Feedback
o Objectif : Créer une boucle de rétroaction rapide et efficace pour
améliorer en continu.
o Mesures clés :

 Résultats des tests : Rapidité et fiabilité des tests

automatisés.
 Change Failure Rate : Taux d'échec des changements en
production.
 Monitoring et incidents : Capacité à détecter et résoudre
rapidement les incidents.
 Pourcentage de rework : Travail nécessaire pour corriger
ou compléter les livrables.
3. Troisième Voie : Expérimentation et Apprentissage Continu
o Objectif : Favoriser l'innovation par des cycles rapides
d'expérimentation et d'apprentissage.
o Mesures clés :

 Hypothesis Log : Enregistrement des hypothèses testées.

 Temps alloué et passé : Mesure du temps utilisé pour
expérimenter.
 Maîtrise atteinte : Niveau de compétences développé par
l'équipe.

Mesurer le Succès dans DevOps

Métriques de performance
1. Vitesse
o Lead Time et Cycle Time : Temps pour développer et livrer des
changements.
o Fréquence des déploiements : Fréquence des mises en
production.
o Vitesse de déploiement : Temps nécessaire pour déployer un
changement.
2. Qualité
o Taux d'échec des changements : Nombre de défaillances dues à
des mises en production.
o Succès des déploiements : Pourcentage de déploiements réussis.

o Incidents et défauts : Nombre de problèmes détectés en

production.
3. Stabilité
o MTTD (Mean Time to Detect) : Temps moyen pour détecter un
incident.
o MTTR (Mean Time to Recover) : Temps moyen pour récupérer
d'un incident.
o MTRS (Mean Time to Restore Service) : Temps pour restaurer un
service impacté.
4. Culture
o Rétention et engagement : Satisfaction et moral des équipes.

o Partage des connaissances : Collaboration et apprentissage au

sein des équipes.

Les Métriques à Favoriser et à Éviter

À éviter :
 Outputs et productivité : Par exemple, lignes de code ou vélocité.
 Mesures locales : Se concentrer uniquement sur des individus ou des
équipes spécifiques.
À favoriser :
 Outcomes et valeur : Par exemple, le délai de livraison ou la fréquence
des déploiements.
 Indicateurs globaux : Analyse à l'échelle de l'organisation.
 Module 8 : Sharing, shadowing &
Evolving

Le concept de DevOps encourage une culture de partage repose sur l’idée

que le succès de la méthodologie DevOps ne se limite pas uniquement à des
pratiques techniques ou outils, mais s’appuie également sur une culture
collaborative et d’apprentissage mutuel. Voici une explication plus détaillée
des points abordés dans le texte :

1. Culture de partage et apprentissage mutuel

DevOps favorise un environnement où les équipes de développement (Dev) et
d’opérations (Ops) partagent leurs connaissances, outils, et expériences. Cela
permet :
 Amélioration des compétences : Les équipes ont accès à des
opportunités d'immersion, comme les Dojos (internes à Target), les
Garages (IBM) ou les Lofts (Amazon). Ces espaces sont dédiés à
l'apprentissage de pratiques comme l'intégration continue (CI), le
déploiement continu (CD), les méthodes Lean, ou le design collaboratif.
 Simulations et gamification : Des jeux, hackathons et simulations
permettent de rendre l’apprentissage interactif et de renforcer la
collaboration. Par exemple, des simulations DevOps ou hackathons sont
des opportunités pour partager des outils, des découvertes, et des leçons
apprises.

2. Événements internes pour renforcer la collaboration

Certaines organisations reproduisent les événements publics de DevOps Days en
les adaptant en interne. Ces événements :
 Favorisent les échanges d’idées, la discussion, et l’apprentissage collectif.
 Incluent différents formats, comme des présentations classiques, des
sessions rapides (Ignite), et des discussions en petits groupes sur des
sujets précis (Open Space).

3. Rôles et compétences DevOps

Un professionnel DevOps se distingue par un mélange de compétences
techniques, d'affaires, et douces (soft skills) :
 Compétences techniques : Connaissances approfondies dans les
domaines de CI/CD, du cloud, de l'automatisation, et des architectures
modernes.
  Compétences d’affaires : Compréhension des priorités stratégiques et
des processus métier.
 Compétences douces : Collaboration, communication, gestion du temps
et du stress, et capacité à travailler en équipe.
Caractéristiques idéales :
 Curiosité, adaptabilité, esprit d’artisan (craftsman), transparence, et
engagement.

4. Importance du leadership transformationnel

Un leadership efficace dans le contexte DevOps ne repose pas sur une hiérarchie
rigide mais sur la capacité :
 À favoriser une auto-amélioration : Les leaders aident les équipes à
diagnostiquer leurs propres problèmes et à s’améliorer.
 À encourager l’expérimentation : L’erreur n’est pas punie mais
analysée pour générer des apprentissages.
 À casser les silos : Ils favorisent des objectifs communs entre équipes et
responsabilisent chaque membre.

5. Résultats concrets : Exemple de Disney

L’expérience de Disney illustre les bénéfices de DevOps :
 Réduction du temps de mise à jour : Une tâche qui nécessitait 8
heures (mise à jour de 100 serveurs) a été réduite à 30 minutes.
 Diminution des coûts : Les coûts ont été réduits de moitié tout en
produisant davantage, par exemple dans le domaine des films numériques.

6. Stratégies pour relever les défis DevOps

Les entreprises font face à plusieurs défis, notamment :
 Pénurie de talents : Les compétences DevOps sont très demandées,
rendant difficile le recrutement et la rétention.
 Adaptation rapide aux technologies évolutives : Les employés
doivent constamment se former pour rester pertinents.
 Changement culturel : Adopter DevOps nécessite un changement de
mentalité, passant d’une culture "eux et nous" à une culture collaborative.
Solutions :
 Investissement dans la formation et la certification.
 Programmes d’immersion et de coaching.
  Restructuration des salaires et de la culture d’entreprise.
 Externalisation ou complément de talents internes.

7. Collaboration et innovation
Les équipes DevOps peuvent être organisées de différentes manières, mais les
modèles les plus efficaces :
 Équipes interdisciplinaires : Dev et Ops travaillent ensemble dans une
même équipe pour éviter les silos.
 Responsabilité partagée : Chaque membre contribue aux normes
définies en matière de développement, automatisation, risques et
conformité.
 Engagement continu : La structure reste plate, avec des interactions
constantes et une balance entre compétences humaines et
automatisation.

8. Étapes pour démarrer avec DevOps

La mise en œuvre de DevOps est un processus itératif. Quelques principes clés :
 Commencer petit : Identifier un projet pilote pour maximiser les chances
de succès.
 Expérimenter et apprendre : Tester de nouvelles pratiques et
technologies.
 Renforcer les gains : Documenter les succès et les échecs pour
s'améliorer.
 Encourager le changement culturel : Faire en sorte que DevOps
devienne "la manière normale de travailler".

9. Challenges et facteurs critiques de succès

Adopter DevOps nécessite de surmonter des obstacles, comme :
 Manque de clarté ou d’engagement : Les dirigeants doivent s’investir
activement.
 Mauvaise communication : Les équipes doivent partager des objectifs,
une terminologie et des pratiques communes.
 Silos organisationnels : Déconstruire les barrières entre Dev et Ops.
Pour réussir, il faut :
 Mesurer les performances avec des indicateurs pertinents.
 Former les équipes aux méthodes Lean et Agile.
  Favoriser un équilibre entre automatisation et interaction humaine.

Conclusion
DevOps va au-delà des outils et des processus techniques. Il repose sur une
culture partagée, où les individus collaborent, partagent leurs apprentissages,
et évoluent ensemble. Cela permet non seulement d’améliorer les performances
techniques, mais aussi de transformer durablement l’organisation.