Dashboard KPI de harness Claude Code : preuve, revenus et risque dans une feuille

Pourquoi créer un artefact dédié

Cet article construit un dashboard KPI de harness pour développeurs et responsables contenu qui publient déjà avec Claude Code. L’échec fréquent est simple : les pages vues montent, mais personne ne sait quel article crée preuve, inscription PDF, clic Gumroad ou consultation. Un workflow Claude Code ne s’arrête pas à une réponse confiante. Il doit laisser un artefact qu’une autre personne peut contrôler. Ici, cet artefact est une ligne par article avec preuve, action de revenu et note de risque.

Traitez l’artefact comme un contrat entre prompt, ligne de commande et page publique. Il doit montrer ce que Claude Code a lu, ce qu’il a changé, quelle commande prouve le résultat et quel chemin de revenus le lecteur voit ensuite. C’est lié à harness engineering, getting started et permissions.

La boucle opérationnelle

La boucle a cinq passages : définir l’action, choisir la preuve, laisser Claude Code faire le plus petit travail utile, vérifier la sortie, puis noter la prochaine action de revenu. Ici, la preuve utile n’est pas seulement le code qui tourne. Surveillez démarrages PDF, clics Gumroad, visites training, preuve de build et risques ouverts. Quand ces champs sont visibles, l’amélioration cesse d’être une devinette.

1. Un article harness reçoit du trafic search mais peu de PDF; la prochaine édition rapproche le checklist gratuit du premier exemple.

2. Un article débutant obtient des PDF mais peu de clics payants; le CTA explique quand le Setup Guide devient utile.

3. Un article permissions envoie vers la consultation; le vocabulaire de risque doit rester visible au milieu du texte.

Starter à copier

const rows = [
  { slug: "claude-code-harness-engineering", sessions: 1882, pdfStarts: 42, gumroadClicks: 9, consultationVisits: 3, riskFlags: 1 },
  { slug: "claude-code-getting-started-complete", sessions: 760, pdfStarts: 28, gumroadClicks: 6, consultationVisits: 1, riskFlags: 0 },
];

function revenueSignal(row) {
  return row.pdfStarts * 1 + row.gumroadClicks * 4 + row.consultationVisits * 9 - row.riskFlags * 3;
}

for (const row of rows) {
  console.log(row.slug, revenueSignal(row));
}

Trois exemples terrain

Exemple 1. Un article harness reçoit du trafic search mais peu de PDF; la prochaine édition rapproche le checklist gratuit du premier exemple.

Exemple 2. Un article débutant obtient des PDF mais peu de clics payants; le CTA explique quand le Setup Guide devient utile.

Exemple 3. Un article permissions envoie vers la consultation; le vocabulaire de risque doit rester visible au milieu du texte.

Checklist d’auto-revue

Avant de transformer ce workflow en habitude, relisez l’article comme une note de release. Le premier contrôle est le scope : le lecteur doit savoir quand utiliser un dashboard KPI de harness et quand une checklist plus petite suffit. Le deuxième contrôle est la preuve : chaque recommandation doit pointer vers une commande, une URL, un diff ou une métrique. Le troisième contrôle est le routing : PDF gratuit, guide Gumroad et consultation doivent répondre à des urgences différentes.

Ajoutez une petite règle d’ownership. Une personne possède l’artefact, une autre la vérification, une autre la prochaine expérience CTA. En solo, ce peut être la même personne, mais les rôles doivent être nommés dans la note. Cela empêche Claude Code de mélanger publication, mesure et vente dans une tâche floue. La prochaine exécution sait aussi où reprendre.

La question utile est : qu’est-ce qui rendra cet article plus facile à vérifier demain matin ? Si la réponse est une capture, gardez-la. Si c’est un prompt plus fort, ajoutez-le au prompt pack. Si c’est une limite plus claire, ajoutez-la aux notes de setup. une ligne par article avec preuve, action de revenu et note de risque n’a de valeur que s’il survit à la session suivante.

Échecs fréquents

Le premier échec consiste à prendre les pages vues comme seul score. Le deuxième est d’approuver sans commande de preuve. Le troisième est d’envoyer tous les lecteurs vers le même produit payant alors qu’un PDF gratuit ou une consultation convient mieux. Écrivez la règle de routing avant de changer le CTA.

Chemin de revenus

Routez par blocage. Si la personne manque de fluidité commande, envoyez-la vers le PDF gratuit ou le cheatsheet Gumroad gratuit. Si elle répète le même travail chaque semaine, proposez 50 Prompt Templates ou Setup Guide. Si le sujet est rollout, risque ou revenu, proposez la consultation. Pour cet article, Prompt Templates standardise les prompts de revue, tandis que Setup Guide stabilise les règles du harness.

Métriques de vérification

Après publication, HTTP 200 ne suffit pas. Vérifiez h1, canonical, hero image, début du corps, liens CTA, mobile layout et langue. Ensuite, suivez démarrages PDF, clics Gumroad, visites training, preuve de build et risques ouverts. Si rien ne bouge, corrigez d’abord le CTA près du premier exemple concret.