Vingt-trois briques en cinquante-sept jours

Ce n'est pas un sprint. Ce n'est pas un miracle. C'est ce qui s'est passé quand la boucle de rétroaction MCP — celle dont je raconte la nuit fondatrice ailleurs — a commencé à tourner en production. Et c'est aussi ce qui a coûté ce qu'aucune métrique de productivité ne capture : les pannes en cascade, les secrets fuités à réparer dans l'urgence, les CI qui pointaient sur du néant. Cet article raconte les deux faces.

La chronologie brute

Si tu regardes les dates de création dans GitHub, la cascade se lit comme un journal de bord :

21-22 mars 2026 : mcp-unified, puis hub-tree. Premier nœud d'une cascade qui ne s'est plus arrêtée.
28-29 mars 2026 : hub-deploy, puis quatre dépôts le même jour — knowledge-export, hub-dashboard, knowledge-indexer, hub-ui. Première grappe en parallèle.
4-5 avril 2026 : hub-agent, hub-npmjs, hub-vscode.
1er-5 mai 2026 : reprise après deux semaines de calme — hub-n8n, hub-zulip, hub-ollama, hub-whisperx, hub-e2e. Les briques OSS self-host qui couvrent les workflows, la messagerie, le LLM local, la transcription audio, les tests bout-en-bout.
8-14 mai 2026 : la cadence accélère encore. memories, ledger, hub-projects, hub-www, prosodie, hub-vault. Six dépôts en six jours.
17 mai 2026 : hub-mail et hub-plausible. Pour le routage des emails et la mesure d'audience de ce site.

Tu peux vérifier dans la timeline — c'est l'objet de la promesse de ce site. Les dates ne sont pas reconstituées après coup, elles sont l'historique Git.

La technique d'accélération

Comment fait-on tomber un dépôt nouveau dans le cluster en deux ou trois soirées, à partir de rien ? Quatre choses, qui se renforcent.

Premièrement, un scaffold qu'on connaît par cœur. Chaque nouveau dépôt hub-* part du même squelette : un Dockerfile, un chart Helm OCI embarqué dans helm/, une CI GitHub Actions qui build, push et déploie, un fichier VERSION qui pilote la sémantique, un Makefile qui expose les actions. Je n'ai pas écrit ce scaffold en pensant à la cascade — il s'est cristallisé pendant les trois ou quatre premiers dépôts, et à partir du cinquième, je le réplique sans réfléchir. L'agent IA, lui, le réplique encore plus vite, parce qu'il l'a vu cinq fois et qu'il sait ce qui change d'un service à l'autre.

Deuxièmement, la knowledge qui sert de contexte permanent. Chaque dépôt a son .github/copilot-instructions.md minimal qui pointe vers la knowledge centrale. Quand j'ouvre une session sur n'importe lequel des vingt-trois dépôts, l'agent commence par interroger le MCP, retrouve les invariants partagés (commits en français, tests de santé obligatoires, refactor toléré seulement si justifié, MCP semantic-hub source de vérité), et applique le pattern de l'écosystème sans que je le re-décrive. Le coût d'onboarding d'un nouveau dépôt est tombé à dix minutes — le temps d'ajouter son org_slug et d'écrire un README de cinq paragraphes que l'agent ingère ensuite.

Troisièmement, le GitOps unifié. Tous les dépôts pointent vers hub-deploy, qui contient le versions.yaml source de vérité. Le chart Helm est embarqué dans chaque repo de service ; sa CI auto-bumpe VERSION à chaque push, build l'image Docker (s'il y en a une), et publie le chart OCI dans harbor avec le nouveau tag — tout ça sans intervention humaine. Conséquence : livrer une nouvelle version en prod tient à un seul nombre à modifier sur la ligne du service dans versions.yaml. Le CD prend le relais. Pas de console à ouvrir, pas de manifests à éditer.

Quatrièmement, la cohérence des conventions. Le format des commits, la structure des charts Helm, le nommage des branches, la procédure de release : tout est documenté dans la knowledge et appliqué automatiquement par l'agent. Quand je crée le vingtième dépôt, il a la même tête que le deuxième — mais avec les leçons accumulées sur les dix-huit précédents.

Cette mécanique-là, prise ensemble, transforme la création d'une brique en un acte coûteux mais reproductible. Tu paies le scaffold une fois ; tu le replies vingt-trois fois sans recommencer.

Le prix payé

Ça n'a pas été calme. Les cinquante-sept jours sont aussi cinquante-sept jours d'incidents en cascade, dont voici les plus instructifs.

Le vingt-quatrième bw login simultané. Quand j'ai migré tous mes dépôts vers le vault Vaultwarden self-hosté (hub-vault), j'ai poussé les secrets en parallèle sur vingt-trois repos d'un coup. Le rate-limit de hub-vault, par défaut à dix requêtes par minute sur l'endpoint d'authentification, a explosé : un mur de 429 sur /identity/connect/token, et la moitié des CI à refaire. Le fix immédiat : MAX_BURST=500/SECONDS=10 dans la config Vaultwarden, puis rollout restart. Le fix long terme : ne plus pousser en parallèle, séquencer les bw login.

Le double-bump de version. Pendant que je polissais ma CI auto-bump (la step Prepare qui patch+1 le VERSION à chaque push), j'ai bumpé localement par habitude. Résultat : double bump à chaque push, versions.yaml qui pointait vers une image qui n'existait plus dans harbor, déploiement qui pull une image inexistante et timeout. Le temps de comprendre : trois services down pendant deux heures. La leçon : la CI bumpe, le local ne bumpe jamais.

Le service account fantôme. Helm, quand on supprime un RBAC d'un chart, ne supprime pas l'account déjà référencé dans un Deployment précédent. Le pod se crée, ne trouve pas son SA, échoue en FailedCreate. Mon quick fix le matin où ça m'est tombé dessus : kubectl create sa <name> vide. Sale, mais ça a remis le service en ligne en quinze secondes pendant que je comprenais le vrai bug.

Le runner bloqué sur docker push. Un runner self-hosté qui a un docker push qui se gèle bloque tous les autres jobs en file d'attente. Le diagnostic n'est pas évident — le job tourne, donc le runner se croit occupé, donc les autres attendent indéfiniment. Le fix : kill -9 du PID dans le pod runner, puis investiguer pourquoi docker push ne rendait pas la main.

Le redémarrage de dams. Mon node dams (la dev-box GPU) reboote de temps en temps. Au boot, flannel met environ trente secondes à créer son subnet.env. Pendant ce temps, les pods qui démarrent voient leur réseau cassé et restent en Completed zéro-ready. Le fix : kubectl rollout restart sur les déploiements qui ont ce symptôme dès que dams revient.

Il y en a une douzaine d'autres du même calibre. Chacune, prise isolément, est un détail. Mises bout à bout, elles ont coûté des soirées et des week-ends — et chacune a fini en mémoire écrite quelque part, accessible à mon agent IA, pour que je n'y retombe plus.

La règle de durabilité

L'erreur facile, en lisant ce qui précède, serait de croire que la cadence elle-même est la performance. Elle ne l'est pas. La performance, c'est qu'à chaque tour, la base devienne plus stable au lieu de devenir plus fragile.

Ce qui rend ces cinquante-sept jours tenables — et qui distingue cette cascade d'un faux-départ comme HAIK, ma première tentative d'écosystème en novembre 2025 que j'ai dû abandonner — c'est une seule règle. Pour chaque brique nouvelle, je dois écrire en parallèle au moins une page de knowledge qui la décrit, l'inscrit dans l'invariant de l'écosystème, et garde mémoire de ses pièges. La cascade fonctionne parce que la knowledge grossit avec elle.

Sans cette discipline, la rétroaction tournerait à vide — l'agent IA s'auto-référencerait à partir de ses propres approximations, et la qualité moyenne du code dériverait à mesure que le volume augmenterait. C'est exactement ce qui a failli se passer la nuit où j'ai laissé le LLM coder seul. La sortie du pattern, c'est l'œil humain ; et l'œil humain travaille sur la knowledge.

Concrètement, ça veut dire : pas de nouveau dépôt sans son docs/README.md au minimum. Pas de feature non triviale sans son ADR (Architecture Decision Record). Pas de bug pénible sans une mémoire formelle dans le système. Ce travail-là prend du temps — peut-être autant que le code lui-même. Mais c'est ce qui empêche la dette d'écraser la cadence.

Bilan

Vingt-trois briques en cinquante-sept jours, c'est aussi vingt-trois briques qui parlent toutes la même langue : même format de logs, même style de chart Helm, même convention de versionning, même pattern d'authentification, même knowledge centrale. Tu ouvres n'importe laquelle aujourd'hui, tu te repères en deux minutes — parce que tu es déjà chez toi.

Le calme est revenu. Les nouvelles briques s'ajoutent plus lentement à présent, par opportunisme plutôt que par nécessité — les deux dernières en date, hub-mail et hub-plausible, sont nées pour la newsletter et l'analytics de ce site. La plateforme tient, elle se documente elle-même, et elle laisse la place mentale d'aller faire autre chose. Comme rouvrir le projet d'un robot qui attend.

Voir aussi