← RETOUR À L'INDEX

Une usine logicielle personnelle pilotée par Kanban et Hermes

Retour de terrain sur un prototype d'usine logicielle personnelle : cartes Kanban, workers Hermes, artefacts, vérifications et limites observées.

Une conversation avec un agent est pratique pour avancer sur un sujet, mais elle ne suffit pas toujours pour organiser plusieurs travaux indépendants. Quand une tâche prend plus longtemps qu’une session, quand il faut reprendre après une erreur ou quand le résultat doit être relu avant livraison, il faut aussi gérer l’état du travail.

J’expérimente une autre unité de travail : la carte Kanban. Elle porte une demande, un contexte et des critères de fin. Un worker Hermes peut la prendre, travailler dans un espace isolé, produire un artefact — par exemple une branche ou une pull request — puis rendre compte de son état. Le board garde une trace durable du travail en attente, en cours, bloqué ou remis en revue.

Ce n’est pas une usine autonome qui livre sans contrôle. C’est un prototype de chaîne de production assistée, avec une séparation plus explicite entre exécution et validation.

Du ticket au résultat vérifié

Le flux que je cherche à rendre fiable est simple :

flowchart LR
    A[Carte prête] --> B[Worker Hermes]
    B --> C[Artefact isolé]
    C --> D[Tests et contrôles]
    D --> E{Résultat vérifié ?}
    E -- Non --> F[Reprise ou blocage documenté]
    F --> B
    E -- Oui --> G[Revue humaine]
    G --> H[Carte terminée]

Une carte terminée signifie que le worker a fini son périmètre et rendu compte selon le contrat de travail. Cela ne signifie pas automatiquement que le changement est fusionné, déployé ou utile en production. Ces étapes ont leurs propres contrôles et peuvent rester soumises à une décision humaine.

Cette distinction change le rôle de l’agent. Dans une conversation ponctuelle, le fil de discussion porte souvent à la fois l’intention, l’avancement et le résultat. Avec une file de travail, la carte devient l’entrée durable; le worker est une exécution remplaçable; la pull request et ses vérifications sont des preuves examinables. Si un worker échoue, l’état peut être conservé et repris sans prétendre que le résultat existe déjà.

Deux contextes, pas un espace partagé

Mon expérimentation personnelle comprend une instance Hermes distante, hébergée sur une VM Google Cloud et accessible par réseau privé. Une autre instance est utilisée sur un poste local dans un contexte professionnel. Je traite ces environnements comme des contextes séparés : leur présence dans cette histoire ne signifie ni partage de secrets, ni échange de conversations ou de données professionnelles. Je n’ai collecté aucune donnée de l’environnement professionnel pour cet article.

Schéma logique, sans détail d’adressage :

flowchart TB
    subgraph LOCAL[Poste local — contexte professionnel]
        L[Instance Hermes locale]
        LB[Board et travaux de ce contexte]
        L --> LB
    end
    subgraph PERSONAL[Environnement personnel]
        O[Opérateur]
        G[Accès privé]
        H[Gateway Hermes distante]
        K[Board personnel]
        W[Worker séquentiel]
        O --> G --> H --> K --> W
        W --> A[Branche ou autre artefact]
        A --> V[Tests, contrôles et revue]
    end

Le dessin montre des périmètres conceptuels, pas une interconnexion entre les deux. Il ne décrit ni une topologie complète ni un dispositif de sécurité certifié.

Photographie d’un prototype

Au 11 octobre 2026, l’observation expurgée de l’instance personnelle confirme un dispatcher Kanban actif et une limite de concurrence à un worker. Un worker a démarré, émis des signaux de vie, créé un worktree et rendu son état par les outils Kanban. C’est une preuve de lancement et de suivi, pas une preuve de livraison en production.

Une pull request ouverte corrige une boucle d’attente au repos. Son contrôle GitHub Actions était réussi lors de la vérification; la PR rapporte 50 tests locaux. La validation complète et la fusion restaient à faire. La formulation juste est donc « CI réussie sur un correctif proposé », pas « usine autonome et fiable ».

Un autre ticket prêt concernait l’attente de quota et la reprise sans consommer inutilement des tentatives de réparation. Il était encore en file : le besoin était identifié, le correctif n’était pas livré. C’est précisément le genre d’état que le Kanban rend visible, sans le transformer en fonctionnalité acquise.

La persistance du service utilisateur a été corrigée avec le mécanisme systemd linger, ce qui permet au lancement des workers de ne pas dépendre d’une session SSH ouverte. Là encore, cela améliore le démarrage du processus; cela ne valide ni le travail produit ni son déploiement.

Enfin, les previews du portfolio ont été restreintes par Cloudflare Access, tandis que le site de production reste public. Le garde-fou GitHub préalable au déploiement automatique restait à traiter, et les services de fusion du portfolio demeuraient arrêtés. Le prototype dépend donc encore de contrôles explicites et de décisions humaines.

Ces éléments sont une photographie vérifiée à cette date. Les files, contrôles et pull requests évoluent; ils ne constituent pas une promesse de disponibilité permanente.

Ce qui fonctionne — et ce qui reste fragile

Le board donne un endroit commun pour lire les demandes, les affectations et les blocages. Les worktrees limitent les collisions de fichiers entre changements. Les heartbeats et les comptes rendus aident à distinguer un worker vivant d’un worker terminé. La pull request permet ensuite d’examiner le diff et les contrôles sans confondre « tâche exécutée » et « changement accepté ».

La limite à un worker réduit les conflits et la charge sur cette petite infrastructure, au prix d’une file plus lente. Une panne, un quota épuisé ou une mauvaise estimation peut retarder tout ce qui attend derrière. Les retries ne sont pas une solution universelle : répéter une opération sans diagnostiquer son état peut brûler du budget ou produire plusieurs tentatives concurrentes. Le suivi de quota et la reprise contrôlée restent des travaux à mener.

Les protections ne sont pas encore complètes. Un check réussi sur une PR ne remplace ni revue du changement ni validation du déploiement. Tant que les garde-fous de fusion et les contrôles de production ne sont pas effectifs, les services d’exécution et de fusion automatiques restent désactivés. Je préfère une carte bloquée et expliquée à une automatisation qui contourne un contrôle manquant.

Prochaines étapes

Je veux d’abord terminer et vérifier les garde-fous de livraison, puis améliorer le traitement des quotas et les reprises après échec. Ensuite, je pourrai mesurer les routines sur des tâches de référence et comparer leur coût et leur fiabilité. Ces points sont des objectifs, pas des capacités déjà démontrées. Je ne dispose pas encore d’une mesure publiée montrant un gain de coût ou une autonomie de bout en bout.

Inspiration et adaptation

Le point de départ de cette réflexion est la vidéo « I Built a Self-Improving Software Factory ». Elle m’a donné envie d’explorer une organisation par chaîne de travail; cet article décrit mon adaptation personnelle et ce que j’ai pu observer, pas une reproduction de la vidéo. Pour le fonctionnement du Kanban Hermes, voir aussi la documentation officielle.