TL;DR
Jah en ligne = 4.0.35 (navigation mobile et desktop). En une journée, 63 pull requests ont été fusionnées et 28 lots sur 38 de la campagne sont livrés. Mais deux lots fusionnés sur GitHub n'étaient pas dans le code, 43 commits sont entrés sans passer par une porte, et une vague est restée neuf heures sans rien fusionner — non pas faute de code, mais parce qu'elle attendait des décisions. Cet article raconte la journée telle qu'elle a été mesurée, et les quatre règles qui sortent de l'audit.
Ce que l'habitant voit
Rien de spectaculaire, et c'est voulu : le village se tient mieux sur un téléphone. La carte de navigation a été ramenée à une seule source dont les surfaces dérivent (barre de contacts, menu « Moi », Nouveautés, Aide), le paysage 844×390 est traité comme un téléphone et non comme une tablette, les fenêtres se déplacent et se redimensionnent au clavier, et le monde cesse de hurler la nuit : les enseignes de terrain passent d'un halo de 8 px à 3 px, avec un contraste encore conforme.
Trois choses attendent la prochaine mise en ligne : la démo protégée par un droit, les couleurs propres (52 couleurs écrites en dur au lieu de 324 en début de journée), et les quêtes « Modifier » et « Suivre ».
Les chiffres de la journée
Mesurés sur main entre le jalon du matin et la clôture du soir :
| Mesure | Valeur |
|---|---|
| Pull requests fusionnées | 63 |
Commits de fusion sur main | 61 |
Commits directs sur main (hors porter) | 39 |
| Lots livrés / total de la campagne | 28 / 38 |
| Couleurs écrites en dur | 324 → 52 |
| Pull requests encore ouvertes | 1 (#474) |
Le même décompte porte une leçon de vocabulaire : mesurer « combien de travail a été livré » donne 63 si l'on compte les pull requests, 61 si l'on compte les fusions, et 39 si l'on compte les commits. Trois nombres pour une seule journée — aucun n'est faux, mais il faut dire lequel on regarde.
Ce qui a bien marché
La file JSON des lots comme source unique d'état. C'est elle qui a révélé le défaut le plus coûteux de la journée : deux pull requests marquées « fusionnées » sur GitHub étaient absentes du code. Leurs commits s'empilaient sur une base orpheline. Sans un fichier d'état confronté au dépôt et aux pull requests, le lot aurait été déclaré livré et le défaut serait réapparu en production une semaine plus tard. Réparé le soir même, avec la migration renumérotée — deux migrations ne peuvent pas porter le même numéro.
La porte courte en local. La CI est coupée pour raison de quota. À la place, une vérification d'environ quatre à sept minutes par lot (lint, tous les unitaires, intégrations affectées, audit). Elle a tenu la journée sans laisser passer de régression visible — et quand elle est passée au rouge, le diagnostic a distingué deux tests fragiles sous charge d'un troisième défaut préexistant, reproduit sur un commit antérieur à la vague. Un rouge qualifié vaut mieux qu'un rouge ignoré.
Les vagues courtes. Deux heures et douze minutes pour la première, une heure et vingt-deux pour la troisième. Quand les décisions sont prises avant, une vague livrée est une vague rapide.
Ce qui a coûté
Le travail a attendu des décisions, pas du code. Une vague est restée environ neuf heures sans aucune fusion (de 05:07 à 15:05). Ce n'est pas un manque d'agents : c'est un manque d'arbitrages. La réponse retenue est une page unique de dix choix, un clic par question, avec le détail technique replié et un résumé qui se copie pour le donner à un agent. Une page par décision, jamais dix pages d'état.
Huit fichiers bloquent le parallèle. Sur la journée, quelques fichiers reçoivent la majorité des retouches :
STATUS.md 23 fois, la file des lots 19, la table de routage des tests 15, CHANGELOG.md 14, le
service worker 13, tokens.css 11, la liste des tests stables 10. Deux agents qui touchent l'un de ces
fichiers se sérialisent, quoi qu'on fasse par ailleurs.
43 retouches sont entrées sans passer par la porte. Dont deux de code. Résultat : la vérification de main a
été cassée deux fois dans la même journée — une fois par un simple chemin de dossier dans un document, que le
lint refuse. Le geste « toujours une pull request, même pour la documentation » n'est pas une coquetterie.
On ne sait plus qui a fait quoi. 104 commits sur 131 portaient la même signature, et le même agent apparaît sous cinq graphies différentes selon le séparateur utilisé (point médian, point, tiret). Le décompte par agent devient faux — non par malhonnêteté, par typographie. Le remède est un séparateur unique, imposé par une règle.
Des dates inventées. Trois fichiers portaient le 09/10 alors qu'ils ont été écrits le 08/10 avant 23 h. Le geste correct n'est pas de recopier la date du voisin, mais de mesurer l'heure avant de dater un fichier.
Les quatre règles qui changent
- Un couloir par agent. Chaque agent possède un ensemble de dossiers — le monde, la messagerie, le village, le serveur, l'administration, les outils. Deux couloirs tournent en parallèle ; deux agents ne partagent jamais un couloir. Les huit fichiers chauds ci-dessus n'appartiennent à aucun couloir : une seule « plume » les écrit, et un lot qui en a besoin le demande dans sa pull request au lieu de l'éditer.
- Une seule entrée. Retour de jeu, idée, ticket, ligne d'index : tout devient un lot dans la file avant qu'un agent y touche. Aujourd'hui il y a cinq listes de choses à faire ; il n'en restera qu'une.
- Une seule vue vivante. L'état se lit dans le tableau de bord qui recalcule depuis la file, le dépôt et les pull requests. Une page HTML ne se justifie que pour décider, et s'archive dès que c'est décidé.
- Toujours une porte. Pull request y compris pour la documentation, pull request empilée re-ciblée avant
fusion, puis vérification que le commit est bien dans
main. C'est exactement ce qui manquait aux deux lots perdus.
Ce qui reste ouvert
Une pull request attend un œil humain : les enseignes de nuit (#474). La différence est petite et le coût de la garder est nul — mais c'est un changement de rendu, et le rendu se juge à l'œil, pas au test.
Ensuite : le ménage des copies de travail (sept coquilles orphelines dans le dépôt, dont une avec un lien vers les dépendances qu'il faut débrancher avant de supprimer, sous peine de vider le dossier principal — l'incident a eu lieu), la cohérence des peaux, les quatre écrans du monde sur téléphone, et la mise en ligne de la prochaine version.
Le mot de la fin
Une journée à 63 pull requests n'apprend pas qu'on peut aller vite : ça, on le savait. Elle apprend où l'on bute quand on va vite à plusieurs — sur des décisions non prises, sur huit fichiers partagés, sur des portes contournées. Les quatre règles ci-dessus ne ralentissent rien : elles existent parce que la vitesse était déjà là et que c'est l'organisation qui manquait.