Easy Tech #33 - LE livre qui m'a le fait plus progresser sur les aspects tech
The DevOps Handbook, une référence sur le DevOps mais pas que...
Salut à tous,
Aujourd’hui on se retrouve pour parler d’un livre qui m’a beaucoup marqué : The DevOps Handbook.
Je trouve ça intéressant de vous résumer ce livre pour deux raisons :
D’une part, c’est un sujet très méconnu des PMs en général. De manière étonnante, les PMs maîtrisent bien l’agile mais peu le DevOps qui n’est qu’un prolongement de l’agile pour inclure également les aspects de mise en production et de déploiement.
D’autre part, ce livre aborde le DevOps de manière très holistique et poussée. Pour montrer en quoi cela peut permettre d’améliorer l’efficacité d’une DSI ou d’équipes produit. C’est donc une lecture très inspirante pour quiconque veut améliorer l’efficacité de ses actions côté tech.
Allez c’est parti 🔥
Synthèse
J’ai lu ce livre quand j’ai commencé à rentrer plus en profondeur sur les sujets tech lorsque j’étais consultant il y a quelques années. Il m’a beaucoup apporté en termes de compréhension des sujets tech.
Le livre structure de la manière suivante :
L’introduction explique en quoi le DevOps permet aux entreprises de rester agiles et compétitives dans un environnement très concurrentiel
La partie 1 présente les 3 voies ou 3 niveaux de mise en place du DevOps
La partie 2 explique comment mettre en place cette approche en priorisant d’abord des publics + matures et sensibilisés à ces sujets
Les parties 3, 4 et 5 détaillent les actions à implémenter pour mettre en oeuvre la 1ère voie (déployer plus vite) ; la 2ème voie (accélérer le feedback) ; la 3ème voie (apprendre et expérimenter en continu)
La partie 6 se focalise sur l’intégration des enjeux cyber à ces sujets dans une approche DevSecOps.
Anecdote perso - mon histoire par rapport au livre
Avant de rentrer dans la synthèse du DevOps Handbook, j’aimerais vous raconter très rapidement pourquoi ce livre est si important pour moi. Ça sera aussi l’occasion pour vous de voir ce qu’il peut vous apporter.
Quand est-ce que j’en ai entendu parler
En 2019, je travaille chez BearingPoint un cabinet de conseil généraliste et je suis spécialisé sur les sujets agile / product. Je travaille d’ailleurs sur ce sujet pour un client au sein du Ministère de l’Intérieur avec un double enjeu :
Aider sur la création des produits
Aider l’organisation à se transformer pour en créer plus efficacement
À cette époque, plusieurs prestataires de notre client travaillent en agile à l’échelle avec le framework SAFe. J’en ai déjà parlé dans l’édition dédiée au livre de Reinertsen sur le Lean Product Development.
Avec mon manager référent de l’époque, on s’est dits que ça serait intéressant que je me fasse former / certifier sur SAFe. Et dans le cadre de la formation, c’est la première fois que j’ai entendu parler de DevOps ! En particulier, c’est là qu’on m’a parlé de ce livre comme une référence en la matière.
Quand est-ce que je l’ai lu
Je l’ai acheté fin 2019. Puis j’ai commencé à prendre des notes et faire des fiches dessus pendant 2-3 mois.
À cette époque, j’étais obsédé par un sujet “les mises en production (MEP)”. Elles sont centrales quand on parle de DevOps puisqu’elles correspondent à l’installation d’une fonctionnalité qui vient d’être développée, afin que les utilisateurs y aient accès.
💡 Les MEPs et la différence entre MEPs et développements
En général pour améliorer ses processus de développement, on met en place l’agile. C’est l’approche à la mode et il y a beaucoup de documentation sur le sujet. Pour autant, le truc avec l’agile, c’est qu’il t’aide à organiser les développements de fonctionnalités, mais pas forcément le déploiement de ces fonctionnalités auprès des utilisateurs.
→ Développement : le développeur écrit des lignes de code pour créer la nouvelle fonctionnalité. Ensuite, il peut installer la nouvelle version du logiciel intégrant cette fonctionnalité sur un environnement pour que le PM la teste, pour que d’autres tests automatiques tournent. ⚠️ En général, on n’impose pas pour terminer le développement, que cette fonctionnalité soit accessible à l’utilisateur.
C’est l’objectif du déploiement d’ailleurs.
Déploiement : j’installe une nouvelle version de l’application sur un envrionnement donné. En particulier, on va parler de déploiement en production, lorsque cette nouvelle fonctionnalité est disponible sur l’environnement de production - celui auquel accède l’utilisateur final. C’est comme ça que la boucle est bouclée : on n’a pas juste développé la fonctionnalité, on a donné accès à l’utilisateur à celle-ci. Ce qui permet notamment de prendre un feedback de sa part sur cette fonctionnalité.
Donc avec un focus trop fort sur l’agile, sans DevOps, on risque de mettre l’accent sur la partie développement au détriment de la partie déploiement.
Bref, je ne sais pas si ça vous est déjà arrivé de lire un livre avec une mission de comprendre une notion. Mais en l’occurence, les rares fois où j’étais dans cet état d’esprit, ça a été extrêmement utile et précieux pour moi. En effet, le fait de vouloir comprendre un sujet oriente, contextualise l’apprentissage et motive pour avancer sur la suite du livre.
Qu’est-ce que ça m’a apporté depuis
Cela fait donc plus de 4 ans que j’ai fini de ficher ce livre et que j’ai donc compris la notion de MEP. Mais ce livre m’accompagne en pensée depuis.
En particulier, je pousse toujours pour aller vers des pratiques DevOps dans les entreprises dans lesquelles je bosse (en tant que prestataire ou avant, en CDI).
Je mets d’autant plus en avant ces pratiques, qu’elles sont en général assez méconnues des profils fonctionnels mais aussi parfois des profils techniques.
C’est d’ailleurs ce qui m’a motivé à écrire cette newsletter sur ce livre. Pour que cette thématique soit plus largement comprise puis adoptée.
Commençons maintenant le résumé !
Introduction : qu’est-ce que le DevOps ?
Le contexte digital
Le livre démarre par deux rappels fondamentaux de l’état de l’écosystème digital aujourd’hui :
La concurrence est plus forte que jamais avec de très nombreuses entreprises qui se lancent et essayent de devenir des leaders
Le seul moyen pour surnager et ne pas se faire écraser, c’est de coller le plus aux besoins du marché, et donc, de faire évoluer vite et bien nos logiciels
Le problème auquel le DevOps répond
À partir de ce constat, on voit qu’il est nécessaire d’être le plus réactif et agile possible. Or c’est bien là qu’est le problème que le DevOps essaye de résoudre.
On le résume souvent par ce genre de représentation :
Pour le dire simplement :
Les dévs essayent de développer le plus vite possible des fonctionnalités pour donner accès à celles-ci aux utilisateurs
Les opérations essayent de garder le système le plus stable possible pour éviter que ça impacte négativement les utilisateurs
Donc on ne peut pas être pleinement réactif et agile dans la mesure où une partie de l’organisation (les Ops) pourrait le voir comme étant contraire à ses objectifs.
La solution apportée par le DevOps
Le DevOps part du principe que la stabilité et la rapidité ne sont pas antinomiques. En d’autres termes, on peut réussir à avoir un système à la fois stable (pour plaire aux Opérations) et qui évolue rapidement (pour plaire aux Développeurs).
L’idée sous-jacente à tout ça, c’est de découper le plus petit les fonctionnalités.
Si mes fonctionnalités sont petites, en les déployant, je ne vais pas déstabiliser mon logiciel
Si mes fonctionnalités sont petites, alors je peux les développer rapidement et donc les pousser vite à mes utilisateurs
Pour y parvenir le DevOps s’appuie beaucoup sur la collaboration et l’automatisation.
Partie 1 : les trois voies
C’est de cette manière que l’ouvrage explique comment le DevOps se met en place pour permettre cette accélération des développements sans pour autant déstabiliser les systèmes.
→ La première voie vise à passer le plus vite possible du besoin utilisateur (pas forcément encore développé) à son déploiement (donc son accessibilité par l’utilisateur).
Comme évoqué plus tôt, la réduction de la taille des développements est un aspect crucial. Par ailleurs, l’automatisation aussi va nous aider.
→ La deuxième voie vise à accélérer le feedback et à s’assurer qu’on puisse savoir, le plus vite possible, si une action technique réalisée, a réussi ou non.
Il faut bien se rappeler que les logiciels sont des systèmes complexes dont on ne peut pas prédire à 100% le fonctionnement en amont. Réussir à mesurer de manière fiable et rapide comment ils se comportent nous permet de les maîtriser et de les comprendre de manière empirique. Petit à petit.
→ La troisième voie vise à pousser pour un maximum d’expérimentations et d’innovation au sein de l’organisation.
En effet, une fois qu’on sait lancer vite des choses auprès de son utilisateur. Et qu’on sait mesurer rapidement le succès ou l’échec de ce qu’on a testé. Il vient naturellement qu’on doit passer tout ça “à l’échelle” et augmenter le rythme et le nombre d’expérimentations.
Partie 2 : par où commencer ?
Car évidemment, même si on est convaincu que le DevOps c’est top ! Ça ne veut pas dire que ça va être facile à mettre en place.
Pour cela, le livre suggère de trouver “le bon value stream” (le bon flux de valeur).
Prenons un moment pour expliquer ce qu’il faut entendre par un flux de valeur. En quelques mots, toute entreprise possède un objectif qui est (de manière simplifiée) de satisfaire un utilisateur qui va la payer en retour.
La chaîne de valeur est le nom qu’on donne au process qui trace toutes les actions à réaliser par cet utilisateur pour finalement payer l’entreprise. Cela ressemble à une user journey dont on a déjà parlé ici (dans l’édition sur le Design Thinking). Mais ici on est vraiment focalisé sur l’acte d’achat.
Or, c’est une bonne manière de découper en flux de valeur une entreprise pour analyser celle-ci.
Par exemple, Amazon a :
son flux de valeur pour les entreprises ;
son flux de valeur pour les particuliers (ecommerce) ;
son flux de valeur pour les consommateurs AWS etc…
Ce que nous disent les auteurs du livre, c’est qu’il faut d’abord se focaliser sur un value stream donc des équipes, qui vont être intéressés d’accueillir l’innovation que constitue le DevOps.
Ce n’est pas sans rappeler ce qu’on a vu dans l’édition #31 sur la courbe d’adoption de Moore !
Partie 3 : quelles pratiques pour des déploiements plus rapides ? (voie 1)
Les fondations du pipeline de déploiement
Tout l’esprit du DevOps Handbook consiste à rendre très industriel la manière dont on fait des déploiements. On veut que ce processus soit si bien huilé que ça devienne un non-événement. Comme lorsqu’on a tellement l’habitude de faire quelque chose, que ça devient entièrement naturel et qu’on ne ressent plus d’inquiétude au moment de le faire.
Par exemple, on peut faire l’analogie avec la conduite d’une voiture. Lorsqu’on commence à conduire et qu’on passe le permis, on n’est pas à l’aise. C’est difficile, les choses ne sont pas spontanées. Et conduire implique de mobiliser puis synchroniser des muscles et zones du cerveau très différentes. Mais petit à petit, on progresse et quand on est très à l’aise, conduire devient un non-événement. Ce qui était difficile devient naturel.
En matière de MEPs, les auteurs suggèrent de mettre un place un outil pour industrialiser les déploiements. Ils l’appellent un “pipeline de déploiement”. Il faut imaginer ça comme un process automatisé qui démarre quand on a fini de développer une nouvelle fonctionnalité. Cette nouvelle fonctionnalité va suivre différentes étapes avant d’être déployée dans un environnement soit de production soit qui lui ressemble. Tout ça avec un haut degré d’automatisation, pour limiter les tâches manuelles qui entraînent des erreurs.
Pour réussir à mettre en place un tel outil, il faut avoir sécurisé quelques prérequis :
Être capable de créer rapidement des environnements, afin de pouvoir tester dans plein de contextes différents la nouvelle fonctionnalité ;
Pousser les développeurs à ne considérer leur travail fini que lorsque la fonctionnalité est soit accessible à l’utilisateur, soit déployée sur un environnement iso-production ;
Disposer d’un répertoire commun et partagé qui stocke l’ensemble des travaux techniques réalisés (code pour les fonctionnalités, code pour automatiser les déploiements, code des tests automatiques).
Mettre en place des tests automatiques
Si vous me suivez sur LinkedIn, vous savez que c’est un sujet qui me tient à coeur. En tant que PM, on a tout à gagner à avoir des tests automatiques implémentés pour tester rapidement notre système.
L’idée est la suivante :
On crée une nouvelle fonctionnalité donc il faut s’assurer que celle-ci fonctionne. Mais également qu’elle n’a pas cassé une fonctionnalité qui marchait auparavant.
Pour ce faire on va d’abord déployer cette nouvelle fonctionnalité sur un environnement qui ressemble le plus possible à l’environnement auquel accèdera l’utilisateur
Une fois cette fonctionnalité déployée, on va regarder si (1) elle fait ce qu’on attend d’elle ; (2) elle n’a pas perturbé d’autres fonctionnalités
Or tout cela représente beaucoup de travail. Un travail qu’il est pertinent d’automatiser pour que le PM puisse se focaliser sur des sujets plus précis et avec plus de valeur ajoutée.
Deux précisions sur les tests automatiques :
Il faut que ces tests soient rapides. S’ils sont lents (>1-2h), alors on aura toujours tendance à les court-circuiter à faire les choses à la main.
Il faut être très rigoureux et tout de suite aller corriger lorsqu’un test remonte une anomalie. C’est le but même de ces tests. Si on commence à ne plus les écouter, alors autant ne pas les utiliser.
Faire de la vraie intégration continue
L’intégration continue n’est pas un concept facile à comprendre. J’aime bien le schéma ci-dessous qui tente de rendre les choses un peu plus claires.
Tout l’enjeu est de synchroniser plusieurs personnes qui travaillent en même temps sur des choses similaires. Par exemple, imaginez que vous modifiiez avec 3 autres personnes simultanément un Google Docs ! Forcément, il risque d’y avoir des conflits de version. Une personne va modifier telle phrase qu’une autre personne était en train de réécrire. Quelle version choisir ?
Lorsqu’on écrit du code, ce genre de problème arrive tout le temps.
D’où un enjeu de synchroniser le plus souvent possible. On retrouve d’ailleurs ici la notion de faire plus petit pour que ça fonctionne mieux.
Par exemple pour un Google Docs, les choses sont bien plus faciles à corriger lorsque les deux personnes n’ont pas trop écrit dans leur coin. Inversement si l’on se rend compte trop tard des écarts, alors c’est plus chronophage.
Automatiser les déploiements
Ce point peut un peu surprendre si vous n’êtes pas familiers avec les manières de faire des déploiements à l’ancienne. Avant, un déploiement était une action complexe avec un certain nombre d’étapes pas faciles à réaliser :
Se connecter à distance à un serveur (⚠️ le bon serveur avec les bons mots de passe)
Supprimer l’ancienne version du logiciel
Déposer un fichier .zip qui contient la nouvelle version du logiciel à installer
Dézipper puis installer la nouvelle version du logiciel
Vérifier que tout s’est bien passé
Je simplifie un peu mais lorsque toutes ces actions sont faites à la main, on imagine facilement qu’il y a plein de choses qui peuvent ne pas bien se passer.
C’est pour cela qu’il est pertinent d’automatiser tout ça !
De manière plus moderne, avec des infrastructures dans le Cloud, tout ceci se passe souvent avec des interfaces très bien faites dans des navigateurs et un certain nombre de garde-fous pour éviter qu’il y ait des erreurs humaines.
Toujours est-il qu’il est essentiel de s’assurer qu’on automatise toutes ces actions de déploiement. Car, exactement comme pour les tests, l’automatisation apporte :
De la sérénité ;
De la fiabilité ;
De la rapidité.
Ne pas négliger l’architecture
L’architecture est centrale dans tout ce processus visant à améliorer la manière dont on fait évoluer notre système informatique. Une définition de la bonne architecture d’un logiciel pourrait même être “un logiciel qu’il est facile de faire évoluer”.
De manière paradoxale, on se rend compte de l’importance de l’architecture lorsqu’on est confronté à un système avec une très mauvaise architecture. Dans ce genre de situations :
On ne peut pas faire de “petits déploiements” parce que tous les composants sont imbriqués, donc modifier un petit domino à un endroit, risque de faire boule de neige et de lancer une suite de dominos plus gros à d’autres endroits.
On ne peut pas mettre en place de tests automatiques parce que ça impliquerait de faire des très gros changements sur le système et qu’on ne maîtrise pas suffisamment celui-ci.
Bref l’architecture est fondamentale et si vous voulez creuser davantage le sujet, je vous invite à regarder la newsletter que j’ai dédié au sujet il y a quelques mois.
Partie 4 : quelles pratiques pour du feedback accéléré ? (voie 2)
La supervision à notre secours
Précisons d’abord ce qu’est la supervision 🤔 (en anglais monitoring). Il s’agit de l’ensemble des dispositifs qui vont nous aider à surveiller l’état du système à un instant donné.
Prenons l’analogie d’un corps humain. La “supervision” d’un corps humain, ça serait :
Un thermomètre pour surveiller la température corporelle
Un capteur de pouls pour suivre le rythme cardiaque
Une petite pince autour du doigt pour mesurer la saturation en oxygène
Grâce à ces dispositifs de supervision, on va donc remonter des informations sur comment se comporte le corps humain à un instant donné. Et ça va nous aider à tirer des diagnostics rapidement lorsque quelque chose ne va pas !
C’est pareil pour un logiciel. On va installer des dispositifs techniques (qu’on appelle parfois des sondes) afin de pouvoir mesurer l’état du système. Par exemple en regardant si la base de données n’est pas surchargée de requêtes ou si elle ne peine pas à répondre.
Il y a deux enjeux autour de la supervision :
D’une part, générer la bonne donnée ; c’est à dire poser les bonnes sondes pour repérer les bons indicateurs qui nous intéressent
D’autre part, rendre cette donnée accessible au plus grand nombre ; car c’est là qu’elle va être le plus précieuse. Lorsqu’elle est partagée
Analyser pour mieux anticiper
Une fois les métriques collectées, on va pouvoir effectuer des traitements statistiques pour comprendre si le système est opérationnel ou s’il souffre. À la différence d’un corps humain, dont on connaît grosso modo les bonnes fourchettes pour les constantes vitales. On ne sait pas forcément quelles valeurs vont caractériser un fonctionnement sans soucis et quelles valeurs vont au contraire signifier qu’il y a une anomalie importante.
On va donc mélanger :
Des analyses statistiques classiques pour repérer des comportements atypiques. Par exemple si j’ai la moyenne pour une variable donnée, lorsqu’un écart important à cette moyenne survient, il y a sûrement quelque chose qui ne va pas
Des comparaisons par rapport à des étalons de l’industrie. Typiquement, on va tout de même pouvoir définir ce qu’est un temps de chargement acceptable pour une page donnée. Cela nous aidera donc à affiner notre analyse
Du feedback technique pour aider les dévs à faire des déploiements + safes
Ces métriques constituent en fait un véritable feedback pour les développeurs.
Prenons encore une fois l’analogie du corps humain pour bien comprendre.
Si je suis malade, alors le médecin va me prescrire des médicaments. S’il a accès à toutes mes constantes vitales, il pourra constater rapidement si les médicaments prescrits font effet (typiquement, si j’ai de la fièvre, il pourra observer si la fièvre descend bien).
De la même manière, un développeur va déployer de nouvelles fonctionnalités qui vont impacter le fonctionnement du système. En disposant des bonnes métriques pour suivre le comportement de notre produit, le développeur sait si son évolution a été perturbatrice ou non.
Ce feedback “technique” est précieux car il responsabilise les développeurs et sécurise les phases de déploiement.
Faire du A/B testing au quotidien
Le A/B testing est une notion très intéressante. Elle est issue du marketing historiquement. Lorsque des créateurs de prospectus publicitaires devaient choisir entre deux versions (A et B) d’un même prospectus. Ils procédaient de la manière suivante :
Envoyer 50% des prospectus avec la version A
Envoyer 50% des prospectus avec la version B
Ensuite, ils regardaient la version qui obtenaient le meilleur taux de conversion. Et ils pouvaient donc s’orienter vers la version la plus efficace et optimisée.
C’est la même chose en matière de produit logiciel. On va souvent hésiter entre différentes fonctionnalités et entre différentes manières d’implémetner celles-ci. Faire du A/B testing consistera donc à déployer en parallèle deux versions d’une même fonctionnalité pour regarder laquelle est la plus performante selon un indicateur donné.
Attention, cela n’est pas toujours simple à faire. En pratique, il n’est pas évident de maintenir en parallèle deux versions différentes d’un même logiciel. Toutefois, c’est une manière très efficace de choisir entre des alternatives à partir de données fiables.
Un process efficace de validation des changements
Enfin, il est important d’évoquer des pratiques qu’on retrouve beaucoup dans les DSIs traditionnelles. Dans de telles organisations, les déploiements doivent être validés par des instances et des comités. Pour une simple et bonne raison. Les déploiements partent ensuite en production donc vont être accessibles aux utilisateurs finaux. Donc, on veut prévenir toute anomalie en la matière puisque l’impact est décuplé lorsque l’utilisateur est confronté à un fonctionnement défaillant.
Pour autant, ce genre de validation un peu bureaucratique entraîne souvent des effets indésirables :
On tend à vouloir regrouper dans un même paquet de nombreuses fonctionnalités (pour ne pas avoir à multiplier les passages devant le comité) ⇒ mauvaise pratique puisqu’on a vu qu’il valait mieux faire des petits changements
Cela retarde le déploiement des fonctionnalités et donc le moment où les utilisateurs pourront y accéder. Le feedback arrive donc plus tard ⇒ mauvaise pratique car cela augmente le risque qu’il y a un décalage entre ce qu’attend l’utilisateur et ce qu’on a développé
Pour sécuriser ces phases de déploiement, le livre suggère donc de pousser des approches collaboratives :
Organiser des réunions de coordination entre les parties prenantes
Permettre des peer-review (revues par les pairs) des changements
Encourager le pair-programming (lorsque deux développeurs travaillent ensemble sur le même morceau de code)
Partie 5 : quelles pratiques pour apprendre et expérimenter en continu ? (voie 3)
Cette troisième voie est d’autant plus intéressante qu’elle dépasse les sujets purement techniques. Elle vise à transformer l’organisation pour en faire une machine à apprendre.
Apprendre chaque jour
Ici le livre différencie deux types d’actions à mettre en place.
Premièrement les fondations d’une organisation apprenante qui passe par :
Une culture d’apprentissage. En effet, on peut dire autant qu’on veut aux employés que “vous devez apprendre au maximum” / “on apprend de ses erreurs” / “soit je gagne, soit j’apprends”. Si en pratique, le jour où il y a une grosse anomalie ou un gros problème, on cherche un coupable et on le pointe du doigt, c’est contradictoire. Il est important que les leaders de l’entreprise montrent l’exemple, assument leurs erreurs et en parlent ouvertement. Afin que la culture se transforme.
Des analyses post-mortems. L’idée ici est de faire des autopsies de problématiques rencontrées par l’organisation. Afin d’identifier les causes racine de ces problèmes et d’éviter qu’ils se reproduisent dans le futur. Ces analyses doivent être “blameless” (sans reproche). On ne veut pas juger un coupable, plutôt analyser factuellement pourquoi un événement s’est produit. C’est ce qui nous permet dans un second temps de réfléchir à comment on pourrait éviter à l’avenir que celui-ci se reproduise. Une fois que ces post-mortems ont été réalisés, il faut les diffuser le plus largement possible. Cela contribue à cette culture de l’apprentissage évoqué plus haut.
Deuxièmement des boucles de renforcement continu.
En effet, le risque dans ces démarches de ces démarches d’apprentissage est qu’elles soient trop ponctuelles. Typiquement, on met en place un chantier post-mortem qui dure 6 mois. Puis quand les 6 mois sont finis, on arrête de le faire. Pour éviter cela, les auteurs nous invitent à “rester en tension” pour toujours essayer d’être encore meilleur et efficace. Ils évoquent notamment le concept de “Chaos Monkey”. J’en avais parlé dans l’édition dédiée au DevOps. Le Chaos Monkey est un exercice organisé par les équipes de Netflix. Au cours de cet exercice, ils introduisent volontairement un bug dans les systèmes de Netflix. Cela permet aux équipes de s’entraîner en conditions quasi réelles et de voir si elles sont bien réactives et résilientes face à toutes éventualités !
Ça peut sembler un peu masochiste mais c’est une très belle manière d’adopter un état d’esprit orienté vers la progression en continu.
Transformer les découvertes locales en améliorations globales
Clarifions déjà ce qu’on entend par cette distinction entre local et global :
Le niveau local renvoie aux équipes opérationnelles, qui bossent sur des problématiques identifiée qu’ils maîtrisent parfaitement. Ces équipes vont réaliser des apprentissages sur leur domaine d’expertise. Or ces apprentissages ne sont pas uniquement utiles pour eux. Ils le sont aussi potentiellement pour le reste de l’organisation.
C’est à ça que renvoie le niveau global. Il s’agit du niveau de l’organisation dans son intégralité. Cette organisation est composée de différentes équipes locales. Tout l’enjeu du niveau global est de s’assurer que les équipes locales échangent et fassent circuler de l’information pour générer une progression globale.
C’est donc ce qu’il y a derrière cette idée de transformer les découvertes locales en améliorations globales. Les équipes au jour le jour progressent et renforcent leur expertise sur les sujets qu’ils gèrent. Cette progression doit être documentée est partagée au reste de l’organisation afin que d’autres équipes puissent grandir à partir des erreurs ou des idées des autres équipes. C’est la même logique que les post-mortems ! Mais cela va plus loin. Par exemple, si telle équipe a mis en place un processus très efficace pour valider certaines décisions… pourquoi ne pas le diffuser au reste de l‘entreprise ?
Réserver du temps pour l’apprentissage
C’est LE problème qui freine les stratégies d’apprentissage. Derrière ces très bons objectifs de progression et d’apprentissage, la réalité est souvent qu’on manque de temps pour véritablement monter en compétences en continu.
Voici quelques pratiques poussées par l’ouvrage afin de ne pas faire de cet apprentissage la dernière roue du carosse. La priorité qu’on traite uniquement quand il n’y a aucun sujet urgent :
Institutionnaliser des rituels pour travailler sur la dette technique. Il peut s’agir par exemple d’une journée par mois afin de travailler sur LE sujet côté technique qui embête l’équipe.
Permettre à chacun de faire des retours d’expérience en interne. Une telle pratique entraîne un double bénéfice. D’une part c’est valorisant pour la personne partageant son savoir. D’autre part cela contribue à la documentation des apprentissages (et donc au passage du local au global)
Créer des rôles de coachs/consultants internes pour diffuser les bonnes pratiques. L’idée est donc de dédier certaines personnes à ce sujet d’amélioration et de diffusion des bonnes pratiques. Plutôt que de demander à 10 personnes d’allouer 10% de leur temps à ces sujets. Pourquoi ne pas directement dédier une personne au sujet.
Partie 6 : intégrer la SSI et la compliance (DevSecOps)
La SSI est la responsabilité de tous
Le DevSecOps part du même type de constat que celui à l’origine de DevOps : il y a un manque de collaboration entre les équipes Dev, Ops et SSI / cyber. La raison est simple. Les équipes SSI / cyber sont souvent perçues comme étant des freins pour aller délivrer vite des fonctionnalités.
Dès lors, il se passe le fonctionnement suivant :
Je suis convaincu que la cyber va me faire perdre du temps
Donc je ne la contacte qu’au dernier moment quand c’est vraiment trop urgent et que j’ai trop attendu
Comme j’ai tellement attendu, les corrections potentielles sont significatives ce qui ralentit beaucoup les évolutions que je voulais pousser
Ce qui renforce encore plus ma conviction que les équipes cyber vont me faire perdre du temps
Un joli cercle vicieux 😅
À l’évidence ce genre de fonctionnement n’est pas optimal. D’où les recommandations suivantes des auteurs du DevOps Handbook :
Intégrer la SSI aux moments clés. En particulier à des réunions comme les démonstrations ou les gros points de cadrage où on prévoit de développer certaines fonctionnalités. C’est une super manière de s’assurer qu’on ne prend pas de risque inconsidéré côté cybersécurité. Et d’éviter de les déplacer en bout de chaîne, à un moment où les ajustements qu’ils pousseront seront très coûteux.
Raisonner par zone pour la mise en place de la SSI. Il s’agit de cartographier son application en différentes zones logicielles : environnement de déploiement, code applicatif, librairies tierces qu’on utilise. On peut ensuite analyser si les sujets SSI sont correctement mis en place pour ces différentes zones. Cela permet d’avoir une idée globale de la criticité de ces sujets. Puis de prioriser en fonction.
En lien avec la voie 2, créer une supervision dédiée à la SSI. Les événements cyber problématiques doivent être anticipés et il faut pouvoir surveiller leur survenance. La supervision sert à ça. De la même manière qu’on inclut des points de supervision pour éviter que des bugs se produisent. Il en faut pour éviter des problèmes de cybersécurité.
Protéger le pipeline de déploiement
Il est donc nécessaire de s’assurer que tout au long du pipeline de déploiement, les enjeux cyber / SSI soient correctement représentés. En plus de s’assurer que les bons acteurs sont présents autour de la table. On pourra intégrer des contrôles automatiques orientés cyber dans le cadre du processus qui mène au déploiement.
Enfin, le DevOps vise à pousser pour une plus forte collaboration entre les différents acteurs. On l’a vu précédemment avec l’idée d’inclure les acteurs cyber / SSI dans les différentes réunions. Il y a aussi un enjeu à pousser pour une culture collaborative. Plutôt que de séparer et cloisonner les responsabilités. Il faut que tous soient conscients qu’ils participent à la réalisation des mêmes objectifs. Qu’ils soient des acteurs cyber / SSI ou non.
Conclusion
Merci de m’avoir lu. J’espère que ça t’a plu !
Si c’est le cas, fais le moi savoir en likant cette édition 🫶
À la semaine prochaine,
Victor
Très complet, merci beaucoup pour cette vulgarisation du DevOps 👌😃