Construire un vrai outil autour du CLI Claude Code : streaming et garde-fous

Un skill ou un agent Claude Code, c'est un fichier markdown avec un frontmatter YAML. Rien de compliqué tant qu'on en a deux ou trois. Le problème commence à l'accumulation : corriger un skill à la main sans retour immédiat sur les erreurs de frontmatter, et perdre toute trace de ce qui a été lancé, quand, avec quel résultat et à quel coût. Ces deux frictions, pas une seule, sont ce que j'ai voulu régler avec Tarmac.

Deux frictions, deux réponses#

Friction	Réponse
Corriger un skill à la main, sans retour immédiat	Éditeur avec validation en direct du frontmatter (nom, description, outils autorisés, modèle)
Perdre la trace de ce qui a tourné	Historique de chaque run : durée, coût, tokens, statut

La deuxième réponse est celle qui a demandé le plus de réflexion architecturale, parce qu'elle implique de faire tourner un vrai processus, pas de simuler un résultat.

Ne pas simuler : streamer un vrai processus CLI#

Le point de départ non négociable : Tarmac n'est pas un wrapper qui affiche un résultat préfabriqué. Chaque lancement est un vrai appel au CLI claude officiel, en mode headless (claude -p), avec le texte de la réponse streamé en direct dans l'interface au fur et à mesure qu'il est produit par le processus.

Techniquement, ça veut dire lire la sortie standard d'un sous-processus au fil de l'eau et la pousser vers le navigateur, plutôt qu'attendre la fin de l'exécution pour tout afficher d'un coup. La différence n'est pas que cosmétique : sur un skill qui prend trente secondes, voir le raisonnement se construire en direct change complètement la capacité à repérer un problème avant la fin du run, plutôt que de découvrir l'échec après coup.

Le coût et les tokens ne sont pas des détails#

Une exécution de skill qui « a marché » ne dit rien sur si elle a coûté trois cents ou trois dollars. Sans historique, ce chiffre disparaît dès que le terminal se ferme. Avec un historique persistant (SQLite en local), la question change de nature : on ne demande plus seulement « est-ce que ce skill fonctionne », mais « est-ce que ce skill est rentable à faire tourner tous les jours ». C'est une question qu'on ne se pose jamais tant qu'on n'a pas les chiffres sous les yeux.

Le mode démo, un choix de conception sous-estimé#

Un détail qui a plus d'impact qu'il n'y paraît : Tarmac expose un mode démo, un jeu de données factice qui permet de montrer l'interface publiquement sans exposer sa configuration .claude réelle. Séparer la démonstration de l'usage réel n'est pas seulement une question de confidentialité, c'est ce qui rend l'outil montrable à quelqu'un sans lui faire courir le risque de voir vos prompts et vos coûts personnels.

Pourquoi l'exécution réelle reste locale#

La vitrine de Tarmac est déployée sur Vercel, mais l'exécution réelle des skills reste volontairement en local (localhost:3700). Faire tourner le CLI Claude Code contre un dossier .claude réel demande un accès au système de fichiers et à des identifiants qui n'ont rien à faire sur un serveur public partagé. Le garde-fou le plus important n'est pas dans le code, c'est dans cette décision de périmètre : ne jamais déployer publiquement une capacité d'exécution qui donne accès à la configuration de quelqu'un.

Ce que ça généralise#

Construire un outil autour d'un CLI agentique révèle une règle qui dépasse ce projet précis : la valeur ne vient pas de l'appel au modèle lui-même, elle vient de tout ce qui l'entoure, retour d'erreur immédiat, traçabilité du coût, séparation nette entre démonstration et exécution réelle. Le modèle est la partie facile. Le tissu de garde-fous autour est ce qui rend l'outil utilisable au quotidien plutôt qu'une démo qu'on montre une fois.