TL;DR
Une session a été consacrée non pas à un produit, mais à l'outillage qui fait tourner les autres. Cinq gestes en sont sortis : un démarrage qui met le dépôt en état, un contexte de zone livré à l'agent, un plan de train qui dit quels lots peuvent partir ensemble, un veilleur qui rend visible une branche principale rouge, et un instrument qui compte ce qui se charge avant la connexion.
Le résultat le plus intéressant n'est pas l'outillage. C'est ce que la mesure a révélé : une bonne partie du rouge n'avait rien à voir avec le code. Trois causes, toutes vérifiables, toutes invisibles depuis la prose.
Le problème, chiffré par la session précédente
Le compte rendu de la session d'avant était précis, et sévère : « coder a pris moins de temps qu'attendre et contourner ». Le tableau de bord était clair. Vingt minutes pour lire l'état et planifier. Vingt-cinq minutes de chaîne d'intégration par demande de fusion. Vingt minutes de plus pour une publication. Et, en tête des freins : une branche principale rouge sans que personne ne le sache.
Ce dernier point mérite qu'on s'y arrête, parce qu'il se reproduit tout seul. Une base rouge ne coûte pas cher le jour où elle rougit. Elle coûte cher trois jours plus tard, quand chaque lot cherche dans son propre diff la cause d'un échec qui vient d'ailleurs.
Ce qui a été construit, et ce que ça retire
| Geste | Ce qu'il retire |
|---|---|
| Un démarrage qui installe et vérifie l'environnement | Les cinq à dix minutes perdues à découvrir qu'il manque un outil système, une dépendance ou un navigateur |
| Un contexte de zone, rendu à l'agent | La relecture de sept documents pour retrouver « quoi faire, où, et avec quelle preuve » |
| Un plan de train qui calcule les conflits de dossiers | L'attente en série de lots qui ne se croisent jamais |
| Un veilleur de branche principale | Le rouge caché : une issue s'ouvre au premier échec, se ferme au premier vert |
| Un compteur de chargement | La question « pourquoi ça dépasse ? » sans la liste de ce qui dépasse |
Le point commun de ces cinq gestes est le même : ils remplacent une lecture par une mesure. Lire un plan dit ce qui devait arriver. Mesurer dit ce qui se passe.
Découverte une : la panne n'était pas dans le code
La batterie de tests locale sortait au rouge. Un seul test, sur un certificat fabriqué à la volée. Le réflexe est de chercher la régression dans le diff. La cause était ailleurs : l'outil de fabrication de certificat n'était pas dans le chemin des exécutables. La chaîne d'intégration, elle, ne voyait rien — elle a cet outil d'origine.
Autrement dit : un rouge local qui n'existait nulle part ailleurs, et qui faisait douter du travail en cours. Le correctif n'est pas une consigne (« pensez à préfixer votre chemin »). C'est une ligne de code au bon endroit, chargée au démarrage des tests, et une alerte au démarrage de session.
Leçon transposable : un rouge n'est pas une information tant qu'on ne sait pas quoi il désigne. Un test peut échouer pour une raison qui n'a rien à voir avec le test.
Découverte deux : l'état rapporté avait déjà changé
Le rapport de la session précédente listait trois parcours de bout en bout cassés et un test unitaire rouge, tous antérieurs aux changements en cours. Avant de les corriger, la mesure : les trois parcours étaient déjà verts sur la branche principale. Une session parallèle les avait corrigés entre-temps.
Et l'un des chiffres cités — « quarante-neuf modules chargés avant la connexion, pour une limite de quarante-huit » — mesurait en réalité vingt-trois. Le dépassement d'un seul module n'était plus reproductible.
C'est la deuxième leçon, et la plus coûteuse à ignorer : un constat daté est une hypothèse, pas un fait. Le corriger sans le rejouer, c'est écrire du code pour un problème qui n'existe plus.
Découverte trois : le travail était déjà pris
Le troisième réflexe évité est le plus discret. Une partie du plan portait sur la chaîne de publication : ne plus rejouer toute la batterie de vérifications en local avant une livraison, quand le commit a déjà une chaîne verte.
En arrivant, une lecture rapide a montré qu'une session parallèle avait déjà écrit un plan qui couvrait exactement ce sujet, dans exactement les mêmes fichiers. Construire là aurait produit deux implémentations concurrentes du même geste, et une fusion conflictuelle à la clé.
Ce n'est pas de la chance : c'est le contexte de zone qui l'a rendu visible. Chaque lot déclare les fichiers qu'il possède. Deux lots dont les zones se recoupent ne partent jamais en parallèle — et le calcul du train le dit avant d'écrire une ligne. La partie release a donc été laissée à qui la possédait, avec les trois nuances manquantes consignées pour elle.
La preuve que le veilleur sert
Il y a une satisfaction particulière à voir un outil de diagnostic servir dans l'heure qui suit sa mise en service.
Dans l'heure, effectivement : la branche principale a enchaîné trois poussées rapprochées. La chaîne d'intégration en a annulé une, en a gardé une en file, et une troisième attendait son tour. Le veilleur a ouvert une seule issue, étiquetée, avec le lien du journal et l'empreinte du commit. Pas de doublon malgré plusieurs exécutions non vertes — le garde-fou de déduplication tient.
Il a aussi révélé un mécanisme que personne n'avait regardé : sur une branche principale, les exécutions se mettent en file au lieu de s'annuler. Trois poussées rapprochées, c'est donc trois batteries complètes en série, de vingt à trente minutes chacune. Une annulation évitait ce coût ; un veilleur qui ne se plaint pas l'aurait laissé passer.
Ce qui reste ouvert
Trois choses, et aucune n'appartient à un agent :
- Un budget de chargement documenté à quarante-cinq, un test qui borne à quarante-huit, et une mesure qui donne vingt-trois. Trois nombres pour un seul sujet : il faut en choisir un.
- La protection de la branche principale, qui reste un réglage, pas du code.
- Les exécutions en file sur la branche principale, à arbitrer entre regroupement et annulation.
Ce qu'on retient
L'outillage n'a pas accéléré le travail en écrivant plus vite. Il l'a accéléré en supprimant des lectures : moins de documents à parcourir, moins d'attentes en série, moins d'inconnues au démarrage.
Et il a surtout rendu le rouge bavard. Une panne qui parle de sa cause se corrige une fois. Une panne muette se cherche à chaque session — c'était, de loin, le poste de dépense le plus lourd.