Contexte
Quand un portefeuille de projets devient un système à piloter
Mes produits IA vivent dans des dépôts distincts, avec leurs tâches, leur état Git, leurs contrôles qualité et leurs sessions d’agents. Le vault RomainOS ajoute une seconde couche de décisions et de suivi.
Consulter chaque source séparément donnait beaucoup d’information, mais aucune réponse immédiate à la question utile : où dois-je intervenir maintenant ?
Problème
L’état était dispersé. La confiance aussi.
Un dépôt sale, un contrôle de santé en échec ou une documentation périmée ne portent pas le même niveau d’urgence. Il fallait agréger ces signaux sans les aplatir dans une simple liste.
L’ajout d’agents créait un second problème : automatiser une action sans pouvoir expliquer, revoir ou arrêter son exécution aurait déplacé la charge au lieu de la réduire.
Mon rôle
Conception produit, architecture et exploitation
J’ai défini le modèle de données, les règles de santé, le score d’attention et les parcours de revue. J’ai ensuite construit le scanner, le dashboard React, l’app Electron et les scripts planifiés.
J’ai également conçu le modèle de confiance : une file actionnable unique, une isolation Git par branche, des contrôles adaptés au risque, un journal d’audit et un kill switch.
Solution
Un poste de commande centré sur la prochaine action
Un registre JSON unique décrit les six projets surveillés. Les scanners lisent leur état Git, leurs tâches et leurs contrôles de santé, puis produisent un statut et un score d’attention comparables.
L’interface rassemble les éléments réellement actionnables dans une Inbox. Les analyses IA restent consultatives tant qu’elles ne sont pas transformées en proposition revue par le kernel.
Le même système est livré dans une app macOS dédiée, connectée au backend local et au dépôt réel plutôt qu’à une copie statique des données.
Choix clés
Quatre décisions pour garder le contrôle
Un registre comme source unique
Le scanner CLI et le dashboard React consomment le même fichier projets. Ajouter ou modifier un projet ne demande pas de maintenir deux configurations parallèles.
Un cœur local, des frontières explicites
Le dashboard et les scanners restent locaux. Les appels Anthropic, Telegram et Whoop appartiennent à des couches séparées, activées uniquement avec leurs clés et documentées comme telles.
Une seule file actionnable
Les analyses du CMA restent des recommandations. Seule la review queue du kernel peut passer de proposé à approuvé puis exécuté.
Une autonomie qui échoue vers la revue
Les actions d’agents sont isolées sur une branche, journalisées et soumises à des gates. Une commande risquée, un dépôt sale ou un contrôle rouge renvoie l’action vers un humain au lieu de forcer l’exécution.
Résultat & apprentissage
Six projets, une seule vue opérationnelle
Le Command Center surveille six entrées, y compris sa propre santé. Le scan est planifié toutes les trente minutes et au login. Le dashboard a été packagé et lancé comme app macOS dédiée.
L’apprentissage principal : pour un produit agentique, la gouvernance fait partie de l’interface. La provenance, le niveau de risque, les gates et le bouton d’arrêt doivent être aussi lisibles que la recommandation elle-même.
C’est un outil personnel : aucun chiffre d’utilisateurs ou gain de temps n’est publié. Le résultat vérifiable est un système opérationnel, pas une métrique d’adoption extrapolée.
Stack & méthodes
Local-first, observable, supervisé
- React + Vite
- Node.js
- Electron
- better-sqlite3
- Git et scanners locaux
- launchd
- Agent Trust Kernel
- Review queue + gates QA
- Vitest