Il y a deux semaines, je vous racontais comment était né notre livre sur les software factories.
Depuis, il a pris sa forme définitive : un titre, une couverture, des dessins, et 260 pages qu’on relit une dernière fois avant impression. Le 26 novembre, il sera entre vos mains. En attendant, je vous en ouvre les premières pages, et je vous laisse repartir avec son premier chapitre.
Vous avez déjà vécu ce jeudi-là
Le livre s’ouvre sur une scène que vous avez sûrement déjà vécue. Un jeudi, votre outil d’IA produit en une demi-journée ce que vous auriez chiffré à trois jours. Le lundi suivant, sur une tâche plus simple, il tourne en boucle, et il faut tout reprendre à la main. Même outil, même équipe, mais deux résultats opposés.
C’est de cette variabilité que part le livre. Pas pour expliquer comment mieux prompter, mais pour poser la vraie question : quand une machine produit le code, qu’est-ce qu’une entreprise doit décider, et qu’est-ce qu’elle ne doit surtout pas laisser décider à sa place ?
Six décisions, dans l’ordre
Le livre est construit comme un parcours. Six décisions, qu’on prend l’une après l’autre, chacune avec son chapitre, ses exemples et ce qu’il faut en retenir.
1. Quel résultat on cherche. Gagner du temps n’est pas un objectif. Le chapitre 2 passe en revue les promesses de l’usine, les mauvaises raisons de « faire de l’IA », et comment écrire noir sur blanc ce qui permettra de juger si ça a marché.
2. Par où commencer. Pas par un projet neuf. Par l’existant, ses goulots, ce que l’équipe fait déjà avec l’IA sans le dire, et la décision de départ formalisée en une page.
3. Comment faire travailler agents et humains ensemble. C’est le cœur du livre : ce qu’un agent ne doit pas décider à votre place, la bonne information à lui donner, le passage de l’agent isolé à la ligne de production, et jusqu’où lui laisser la main.
4.Comment vérifier que ça fonctionne. Ce qu’un contrôle automatique peut prouver, ce qu’il ne peut pas, et comment organiser une revue qui ne devienne pas un tampon.
5. Ce que ça change pour les employés. Deux chapitres sur le travail humain autour des agents et sur le jugement, cette compétence qu’on ne forme pas en une journée de démonstration. Le titre de l’un d’eux : « Le développeur est mort. Vive le développeur ! »
6. Mesurer, puis décider la suite. Les chiffres qui comptent et ceux qui mentent, et la décision qu’on oublie toujours de préparer : étendre, adapter, réduire, ou arrêter.
Les dessins de Jean-Marc
Un livre sur les usines logicielles pouvait vite devenir austère. On savait que Jean-Marc Charles, CTO avec qui on travaille depuis plus de trois ans sur des missions de direction technique et de coaching, dessinait à ses heures perdues (même s’il en a peu). Alors on lui a demandé s’il voulait bien mettre les idées du livre en images. Il a dit oui tout de suite, et il y a mis bien plus que ce qu’on espérait : une série d’esquisses qui prennent chaque concept à contre-pied, avec un robot un peu trop zélé et des humains un peu trop confiants. Elles disent en une case ce qu’on met parfois trois pages à expliquer. Merci Jean-Marc, le livre ne serait pas le même sans toi.
Le premier chapitre est à vous
On ne vous demande pas de nous croire sur parole sur le fait que ce livre va transformer votre organisation. On vous offre le premier chapitre : onze pages qui tiennent en trois temps.
Le problème. Cet écart de résultat entre deux prompts, et ce qu’il révèle de la façon dont votre équipe produit aujourd’hui. Pas une question d’outil ni de prompt, mais d’organisation.
La factory. Ce qu’on appelle une AI Software Factory : une organisation où des agents prennent en charge une vraie part du travail, et qui reste observable, vérifiable et sous contrôle à mesure que leur autonomie grandit. Ce qu’elle n’est pas, aussi, et l’endroit précis où la métaphore industrielle cesse d’être utile.
Le fil du livre. Les six décisions, dans l’ordre, et un plan de lecture pour entrer par la porte qui vous concerne selon votre rôle et là où vous en êtes.
Vous y lirez aussi ce que le livre ne fera pas. Il ne promet pas de révolution, elle a déjà eu lieu. Il ne recommande ni une stack ni un outil, et ne brandit aucun chiffre de productivité. Il s’arrête sur une seule question, que vous retrouverez à chaque chapitre : quand produire du code devient facile, qu’est-ce qu’on choisit de ne pas automatiser ?
En onze pages, vous saurez si ce livre est pour vous 😉
—
A très vite,
Matthieu