Dix ans après l'avoir lu, les gens disent encore « on a un problème de Brent ». Brent, c'est le personnage d'un roman sur des serveurs qui plantent, la personne sans qui rien ne sort et dont le savoir ne quitte jamais la tête. Si ta dernière mise en production s'est jouée un samedi soir, tu connais le tien.
Autour de ce roman, il existe une petite bibliothèque sur la livraison logicielle et sur la façon d'organiser les équipes. J'en ai lu six, avec une fiche de lecture pour chacun. Voici l'ordre que je suivrais, et ce que tu peux laisser de côté.
Le roman pour comprendre
The Phoenix Project (Gene Kim, Kevin Behr et George Spafford, 2013, 8,2/10) fait ce que des rayons entiers de manuels ratent : faire comprendre la gestion de flux à quelqu'un qui n'a jamais ouvert un livre de gestion. Tu subis trois pannes avec le héros avant que le mentor n'explique quoi que ce soit, et quand l'explication arrive, tu en avais besoin. Le travail non planifié devient un tableau de cartes vidé par les urgences. Le goulot d'étranglement devient Brent.
Soyons honnêtes : littérairement, c'est un roman d'aéroport. Personnages-fonctions, méchante caricaturale, mentor qui a réponse à tout. Le décor (baies de stockage, comités de validation des changements) est celui de 2013, et la transformation s'accomplit en quatre mois, ce qui relève du conte de fées. Dans la vraie vie, compte des années. Mais le décor a vieilli parce que le livre a gagné : déployer dix fois par jour, impensable à l'époque, est devenu banal. Pour les recettes modernes, la fiche renvoie à The DevOps Handbook, que je n'ai pas fiché ici.
Les chiffres pour convaincre
Accelerate (Nicole Forsgren, Jez Humble et Gene Kim, 2018, 7,4/10) a mis des chiffres dans un débat qui n'avait que des slogans. Avant lui, « il faut déployer plus souvent » était une opinion de conférence. Après, c'est le résultat de quatre ans de recherche, répliqué depuis. Et l'enterrement des comités d'approbation est devenu mon argument préféré en réunion : ce n'est pas moi qui le dis, c'est l'étude.
La limite : c'est un livre d'argumentation, pas un manuel. Tu sauras quoi viser, pas comment y aller. La lecture est parfois aride, répétitive sur la fin, et les chiffres du type ×46 et ×440 datent de 2017. Ne retiens pas les valeurs, retiens le cadre : des capacités plutôt que de la maturité, des résultats plutôt que de l'activité. Pour les chiffres à jour, la fiche pointe vers les rapports annuels de DORA, gratuits.
Le comment, enfin
Continuous Delivery (Jez Humble et David Farley, 2010, 463 pages, 7,8/10) est le socle de la moitié de mon métier. Je n'ai pas connu CruiseControl et je ne ferai pas semblant. Ce que le livre m'a donné, c'est le pourquoi derrière les boutons sur lesquels j'appuie : pourquoi un seul binaire voyage, pourquoi le même script partout, pourquoi on déploie sans livrer. Avec ces raisons, on arrête de bricoler et on conçoit.
Tout l'outillage a vieilli. Hudson, Ant, Puppet première époque : remplace mentalement par GitHub Actions, Docker, Kubernetes, Flyway. Les conteneurs n'existaient même pas, Docker date de 2013. Le livre est épais et parfois sec, et les auteurs eux-mêmes conseillent de le picorer plutôt que de l'avaler. Fais-le. Les principes, eux, n'ont pas pris une ride : un pipeline de CI moderne, c'est le deployment pipeline du chapitre 5.
La forme des équipes
Team Topologies (Matthew Skelton et Manuel Pais, 2019, 8,2/10) est un livre de management rare : écrit pour des développeurs. Son vrai cadeau, c'est le vocabulaire. Une fois que tu sais dire « c'est un monolithe distribué » ou « il nous faut une équipe habilitante ici », une friction vague devient un problème nommable, donc réparable. La manœuvre inverse de Conway (concevoir les équipes pour obtenir l'architecture voulue, puisque l'architecture finit par copier l'organisation) vaut à elle seule la lecture.
Il est répétitif, ses études de cas sont minces, et c'est un livre de conception d'organisation : il faut souvent l'aval du management pour appliquer quoi que ce soit. N'attends pas une recette à lancer seul lundi matin. Lis-le comme le compagnon d'Accelerate (les données) et de The Phoenix Project (l'histoire).
L'humain, et les vieux de la classe
Peopleware (Tom DeMarco et Timothy Lister, édition 1999, 8,2/10) a prouvé, données en main, que les projets échouent pour des raisons humaines. Je suis développeur, pas manager, donc je ne jouerai pas l'expert. Mais le chapitre sur le flow m'a mis des mots sur ce que je ressens depuis des années : cette remontée de quinze minutes dont on se fait arracher, et que presque aucun lieu de travail ne protège. Le monde de 1987 transparaît (open spaces, téléphone fixe, zéro télétravail), et quelques anecdotes tombent bizarrement. Lis-le moins pour les bureaux que pour le miroir.
Le Mythe du mois-homme de Frederick Brooks (édition 1995, 7,8/10) a été écrit en 1975 sur une catastrophe de 1964. Brooks dirigeait OS/360 et, au lieu de minimiser, il a disséqué. Chaque loi vient de quelque chose qui a réellement planté. Les parties techniques datent (program clerks, overlay statique), pas les mécanismes : ajouter des développeurs à un projet en retard le retarde davantage. Saute le vocabulaire de 1975, garde les lois.
L'ordre que je suivrais
| # | Livre | Pages | Note | Pour quoi faire |
|---|---|---|---|---|
| 1 | The Phoenix Project | 432 | 8,2 | Comprendre le flux par l'histoire |
| 2 | Accelerate | 288 | 7,4 | Convaincre avec des données |
| 3 | Continuous Delivery | 463 | 7,8 | Le pourquoi du pipeline, à picorer |
| 4 | Team Topologies | 240 | 8,2 | Nommer et dessiner les équipes |
| 5 | Peopleware | 245 | 8,2 | Protéger le flow, lire les gens |
| 6 | Le Mythe du mois-homme | 322 | 7,8 | Répondre à « ajoutons deux personnes » |
Conclusion
Le plus ancien de ces six livres, écrit en 1975, est aussi celui dont la loi principale n'a été annulée par aucune révolution : ni Git, ni l'agile, ni le cloud. Et le plus récent sur les équipes dit lui-même que son cadre ne suffit pas sans culture ni pratiques d'ingénierie. Les outils de livraison changent tous les cinq ans, les problèmes entre humains, jamais.
J'ai recousu la moelle de dizaines de livres tech dans un seul fil, des bits et du Big O jusqu'à l'ère de l'IA : c'est Le grand livre du développeur. Continuous Delivery, The Phoenix Project, Accelerate et Peopleware y sont fondus au niveau « Prouver, livrer, tenir la charge ». Team Topologies, Peopleware et Le Mythe du mois-homme reviennent au niveau « Le logiciel est pour des humains ».
📚 Autres comparatifs. Livres sur le code propre et le refactoring : dans quel ordre les lire et Livres Event Sourcing et CQRS : dans quel ordre les lire.