Accelerate

1Quatre métriques suffisent à mesurer une équipe de livraison

Les mesures classiques de productivité récompensent toutes le mauvais comportement (ch. 2) :

• Les lignes de code : le livre renvoie au développeur de l'Apple Lisa qui, après avoir optimisé son code, déclara une semaine à -2 000 lignes.
• La vélocité : relative à l'équipe, incomparable, et gonflable à volonté dès qu'elle devient un objectif.
• L'utilisation : la théorie des files d'attente démontre qu'à 100 % d'occupation, les délais tendent vers l'infini ; sans marge, plus rien ne sort.

À la place, quatre mesures de résultat :

• lead time : le délai entre un commit et la production ;
• fréquence de déploiement ;
• MTTR : le temps de rétablissement après incident ;
• taux d'échec des changements.

Deux mesurent le tempo, deux mesurent la stabilité. Vous les connaissez peut-être déjà : ce sont les « métriques DORA », et elles viennent de ce livre.

2Vitesse et stabilité ne sont pas un compromis, et c'est mesuré

Le résultat central, celui qui tue le « on va vite OU on fait bien » (ch. 1-2) : les équipes les plus performantes dominent sur les quatre métriques en même temps. Chiffres 2017 : 46 fois plus de déploiements que les équipes lentes, un lead time 440 fois plus court, un rétablissement 170 fois plus rapide, et 5 fois moins d'échecs de changement.

La citation exacte : « ces résultats démontrent qu'il n'y a pas de compromis entre améliorer la performance et atteindre plus de stabilité et de qualité » (ch. 2). Et ça se voit au compte de résultat : les équipes performantes sont deux fois plus susceptibles de dépasser leurs objectifs de rentabilité et de parts de marché. La prudence procédurière ne protège pas la stabilité ; elle ralentit tout, point.

3La culture se mesure, et elle se change par les pratiques

« Améliorer la culture » sonne comme un vœu pieux. Le livre la rend mesurable avec la typologie de Westrum (ch. 3), trois familles d'organisations reconnaissables à ce qu'elles font des mauvaises nouvelles :

• pathologique : le porteur de mauvaise nouvelle est fusillé ;
• bureaucratique : il est ignoré ;
• générative : il est formé et écouté ; l'échec déclenche une enquête, pas un coupable.

La culture générative prédit statistiquement la performance logicielle ET la performance de l'organisation. Et le levier est contre-intuitif : on ne change pas les mentalités pour changer les comportements, on fait l'inverse. John Shook, témoin direct du redressement de l'usine NUMMI par Toyota : « le moyen de changer la culture n'est pas de commencer par changer la façon dont les gens pensent, mais de changer la façon dont ils se comportent, ce qu'ils font » (ch. 3). Installez le déploiement continu et la revue par les pairs ; la confiance suit.

4Le déploiement continu est un investissement humain

La découverte la plus sous-citée du livre (ch. 4 et 9) : les mêmes pratiques techniques qui accélèrent la livraison réduisent le burnout. Le mécanisme passe par la « douleur de déploiement » : quand déployer fait peur (manipulations manuelles, passages de relais entre silos, mises en prod la nuit), cette anxiété prédit l'épuisement des équipes.

Chez Microsoft, l'équipe Bing a vu la satisfaction d'équilibre vie pro/vie perso passer de 38 % à 75 % après la mise en place du déploiement continu (ch. 9) : pas un programme RH, de l'automatisation. Et Christina Maslach, la référence académique du burnout, donne la direction : réparer l'environnement de travail a bien plus de chances de réussir que « réparer » la personne. Détail qui pique au passage : les tests automatisés ne corrèlent avec la performance que s'ils sont écrits et maintenus par les développeurs eux-mêmes, pas par une QA externe (ch. 4).

5La bonne architecture, c'est celle qui déploie sans demander la permission

Ni le langage, ni l'âge du système (mainframe compris), ni les microservices ne prédisent la performance. Ce qui la prédit, et c'est même le plus fort prédicteur du déploiement continu mesuré en 2017 : le couplage faible, des systèmes ET des équipes (ch. 5). Le test tient en une question : votre équipe peut-elle déployer à la demande, sans coordination avec d'autres équipes, sans environnement de test partagé, sans permission extérieure ?

Concrètement : le couplage fort, c'est l'équipe qui doit ouvrir un ticket à l'équipe base de données, attendre la fenêtre de déploiement du vendredi soir et synchroniser trois services pour livrer un seul bouton. Le couplage faible, c'est la même équipe qui pousse en prod un mardi à 14 h, seule, parce que son service a son propre déploiement et son propre schéma. Le premier ralentit à chaque recrutement ; le second accélère.

Le livre prévient : « la dernière architecture microservices à la mode déployée sur des conteneurs ne garantit aucune performance si vous ignorez ces caractéristiques » (ch. 5). Le chiffre qui scelle l'argument : dans les équipes performantes, le nombre de déploiements par développeur AUGMENTE quand l'équipe grossit ; chez les autres, il s'effondre. L'architecture découplée est ce qui permet de recruter sans ralentir.

6Les comités d'approbation ralentissent tout et ne sécurisent rien

Le résultat le plus brutal pour les DSI classiques (ch. 7). Quatre régimes d'approbation des changements ont été comparés :

• comité externe (CAB) ;
• approbation des seuls changements risqués ;
• revue par les pairs ;
• aucun processus.

Verdict des données : l'approbation par un comité externe corrèle négativement avec le lead time, la fréquence de déploiement et le temps de rétablissement, sans aucune amélioration du taux d'échec. La formulation du livre ne prend pas de gants : « c'est, en réalité, pire que n'avoir aucun processus d'approbation du tout » (ch. 7).

L'alternative qui marche : revue par les pairs (pair programming ou revue intra-équipe) plus pipeline de déploiement automatisé. Même dans les secteurs régulés : la ségrégation des tâches exigée par PCI DSS se satisfait par la revue de code et le pipeline, pas par un comité qui se réunit le jeudi.

7Les bons leaders ne suffisent pas

Le chapitre 11 mesure le leadership « transformationnel » en cinq dimensions (vision, communication inspirante, stimulation intellectuelle, soutien, reconnaissance) et trouve un résultat à double tranchant. Côté pile : les équipes dont les leaders sont dans le tiers le plus faible ont moitié moins de chances d'être performantes. Côté face, et c'est le chiffre gênant pour les keynotes : les équipes avec les leaders du top 10 % ne sont pas plus susceptibles d'être performantes que la moyenne.

Le leadership amplifie les pratiques techniques et l'autonomie des équipes ; il ne les remplace jamais. Un sponsor enthousiaste sans pipeline automatisé ni équipes autonomes, ça fait de beaux slides et les mêmes lead times.

8Une recherche qui montre ses limites, pas des opinions qui s'affirment

Ce qui distingue ce livre de toute la littérature DevOps : la partie II détaille la méthode au lieu de la cacher (ch. 12-15). Analyse « inférentielle-prédictive » : les hypothèses sont posées avant la collecte, à partir de la théorie existante, précisément pour ne pas pêcher des corrélations bidon dans les données (les auteurs citent en contre-exemple la corrélation de 0,9471 entre la consommation de fromage et les morts par étranglement dans les draps).

Les limites sont avouées noir sur blanc : échantillonnage par réseaux (les milieux DevOps s'auto-sélectionnent), perceptions subjectives, pas de causalité stricte. Et un sondage bien construit voit ce que les logs ne voient pas : Forsgren raconte un système de stockage IBM dont les métriques étaient parfaites pendant que les clients souffraient ; le problème vivait dans l'interface humain-système, invisible des logs (ch. 14).