Claude Code pour le Trading : De Zéro à un Système de Publication Autonome

Pourquoi automatiser la publication financière

Chaque jour à 7h, un briefing marché est publié. À 23h, un scan algorithmique de 6 000+ tickers tourne. Le dimanche à 18h, une revue hebdomadaire sort. Aucun humain n'appuie sur un bouton.

Avant l'automatisation, la publication financière sur DailyTickers était un processus manuel, fragile et inconstant. Un opérateur humain devait lancer chaque pipeline, vérifier les données, formatter le HTML, ajouter les tags GTM, mettre à jour l'index, committer et pusher. Le résultat : certains jours pas de daily (oubli, fatigue, voyage), des tags GTM manquants sur 15% des pages (tracking perdu), des formats de dates incohérents (tantôt anglais, tantôt français), des mises à jour radar oubliées, et surtout — des données stale parce que personne n'avait relancé le MCP.

Le système actuel repose sur une chaîne simple mais robuste : un bot Discord (Node.js) déclenche des sessions Claude Code via tmux, selon un calendrier défini dans schedules.json. Claude Code exécute le pipeline complet — de la requête MCP à la publication GitHub Pages — avec des règles immuables qui empêchent toute dérive (pas de données inventées, pas de publication incomplète, pas de skip d'étape).

Source : Anthropic — Claude Code CLI usage

Architecture du Système

L'architecture est volontairement linéaire. Pas de microservices, pas de queue, pas de Kubernetes. Chaque publication suit le même chemin :

Les 5 composants

Pourquoi Discord ?

Le choix de Discord comme orchestrateur peut surprendre. Pourquoi pas un simple cron ? Trois raisons :

1. Monitoring natif. Chaque run poste son résultat dans un channel dédié. Un succès montre le lien vers l'article publié. Un échec montre le message d'erreur et le contexte. Pas besoin d'un dashboard séparé — Discord est déjà ouvert sur le téléphone.

2. Commandes manuelles. Slash commands pour déclencher un run hors-schedule, relancer un pipeline échoué, ou forcer un refresh. Utile quand un événement marché inattendu justifie une publication immédiate.

3. Threads de logs. Chaque run crée un thread avec les logs de progression. On peut suivre en temps réel où en est le scanner dans ses 45 minutes de pipeline sans se connecter en SSH.

Source : discord.js — Documentation

Les 4 Schedules : Quand et Quoi

Quatre tâches tournent sur des schedules fixes. Chacune est définie dans schedules.json avec son heure, sa fréquence et son prompt.

Cas spéciaux

Daily du samedi. Les marchés US sont fermés, mais il y a du contenu : récapitulatif de la séance de vendredi (souvent la plus volatile de la semaine), bilan hebdomadaire condensé, et preview de ce qui attend lundi (earnings, données macro, events géopolitiques). Le MCP fournit les données du vendredi — pas besoin de données live.

Daily du dimanche. Marchés fermés + pas de données de la veille à récapituler. Le contenu se concentre sur deux axes : crypto (marché 24/7, il se passe toujours quelque chose le weekend) et géopolitique (les décisions politiques ne s'arrêtent pas le dimanche). Format plus court, ~12 sections au lieu de 17.

Convention de date du scanner. Le dossier du scanner porte la date de la prochaine séance de trading, pas celle de l'exécution. Un scan lancé le mardi 16 à 23h crée le dossier scanner/20260617/ (mercredi). Un scan lancé le vendredi 19 à 23h crée scanner/20260622/ (lundi). Cette convention évite toute ambiguïté sur la validité des setups.

Le prompt de chaque schedule

Chaque schedule envoie un prompt structuré à Claude Code. Le prompt n'est pas un bloc de texte libre — c'est une invocation de skill avec du contexte :

// Exemple : prompt du scanner (simplifié)
const prompt = `
Nous sommes le ${dateStr} à ${timeStr} (heure de Paris).
C'est un ${dayOfWeek}.

Lance le pipeline /scanner pour la prochaine séance
(${nextTradingDay}).

Utilise EXCLUSIVEMENT le MCP DailyTickers pour les données.
Ne jamais inventer de données financières.
Publie via add_card.js. Commit et push si tout est ok.
`;

// Le skill /scanner contient le playbook complet :
// 10 étapes, chacune avec ses règles, ses checks,
// et ses conditions d'arrêt.

Le prompt est court parce que le gros du travail est dans le skill et le CLAUDE.md. Le prompt fournit le contexte temporel (date, jour, prochaine séance) et les contraintes critiques (MCP obligatoire, pas d'invention). Tout le reste — les 17 sections du daily, les critères du scanner, le template HTML — est chargé automatiquement par Claude Code depuis les fichiers du projet.

Source : Anthropic — Claude Code CLAUDE.md memory

Le Pipeline Scanner : 45 Minutes Chrono

Le scanner est la tâche la plus complexe du système. En 45 minutes, il analyse 6 000+ tickers, en filtre la grande majorité, enrichit les survivants avec des données MCP, vérifie l'absence de pièges (dilution, événements proches), calcule des scores, optimise les tailles de position, et génère un article HTML complet avec des setup cards interactives.

Les 10 étapes

Le market cap tiering

Depuis la war room du 19 juin 2026, le scanner n'applique plus un plancher market cap uniforme de $50B. À la place, un sizing tiered :

// Market cap tiering — war room 2026-06-19
if (mcap < 2e9)  return 'REJECT';     // < $2B → rejet
if (mcap < 10e9) return size * 0.5;     // $2–10B → demi-position
if (mcap < 50e9) return size * 0.7;     // $10–50B → position réduite
return size;                            // $50B+ → position pleine

Ce tiering sera reversé si les tickers sub-$20B montrent un stop moyen supérieur à -6% sur 3 rétrospectives consécutives.

Source : SEC EDGAR — Company filings search

Gestion des Erreurs et Recovery

Dans un système autonome, les erreurs ne sont pas des exceptions — elles sont la norme. Le MCP expire, GitHub rate-limit, le contexte sature, le disque se remplit. Ce qui distingue un système fiable d'un système fragile, ce n'est pas l'absence d'erreurs — c'est la visibilité des échecs et la sûreté des dégradations.

Les 5 modes de défaillance

Les règles immuables

Cinq règles sont gravées dans le CLAUDE.md du projet. Elles ne peuvent pas être overridées par un prompt, un skill, ou un agent. Elles forment le filet de sécurité du système :

// Les 5 règles immuables du système

1. MCP HARD STOP
   Si le MCP bloque (auth, timeout, réseau)
   OU renvoie des données incohérentes (NaN, prix aberrants, stale > 48h)
   → STOP IMMÉDIAT. Jamais substituer. Jamais inventer.

2. NO HALLUCINATION
   Ne JAMAIS fabriquer de données financières.
   Pas de prix estimés, pas de market cap "de mémoire",
   pas de 52W range deviné.

3. SIZE CHECK
   Ne pas push un HTML < 10KB.
   Un article complet fait 30-100KB.
   En dessous = génération incomplète.

4. READ BEFORE WRITE
   Toujours lire le JSON cible (daily.json, scanner.json)
   AVANT d'appeler add_card.js.
   Prévient les doublons.

5. NO SKIP
   Jamais skipper une étape du pipeline
   sans accord explicite de l'opérateur.
   Chaque étape existe pour une raison.

Notifications Discord

Chaque run produit une notification dans le channel dédié :

// Succès
✅ Scanner 20260619 publié
   8 setups (3 Dynamic, 3 TKL, 2 Orbit)
   Régime : Neutral (VIX 17.2)
   https://articles.dailytickers.com/scanner/20260622/
   Durée : 43m12s

// Échec
❌ Scanner 20260618 SUSPENDU
   Raison : MCP HARD STOP — token expiré
   Étape : 5/10 (MCP Enrichment)
   Action requise : re-auth MCP puis relancer

Source : Anthropic — Claude Code overview

Orchestration tmux : Isolation et Logs

Chaque run Claude Code a besoin de son propre terminal. Le scanner de 23h et la rétrospective du vendredi peuvent se chevaucher. Deux sessions qui partagent un terminal finissent par corrompre leurs sorties respectives. tmux résout ce problème avec des sessions nommées et isolées.

Gestion des sessions

// Le bot Discord lance chaque pipeline dans une session tmux dédiée

const { execSync } = require('child_process');

function launchPipeline(type, dateStr, prompt) {
  const session = `${type}-${dateStr}`;

  // Vérifier qu'une session du même nom n'existe pas déjà
  try {
    execSync(`tmux has-session -t ${session} 2>/dev/null`);
    console.log(`Session ${session} déjà active, skip`);
    return false;
  } catch (e) {
    // Session n'existe pas — on peut la créer
  }

  // Créer la session et lancer Claude Code
  execSync(`tmux new-session -d -s ${session} \
    'cd ~/GolandProjects/articles && \
     claude -p "${prompt}" 2>&1 | \
     tee ~/logs/${session}.log; \
     echo "EXIT_CODE=$?" >> ~/logs/${session}.log'`);

  // Activer la capture de logs
  execSync(`tmux pipe-pane -t ${session} \
    'cat >> ~/logs/${session}-pipe.log'`);

  return true;
}

// Exemples d'appels
launchPipeline('scanner', '20260619', scannerPrompt);
launchPipeline('daily',   '20260619', dailyPrompt);
launchPipeline('weekly',  '20260621', weeklyPrompt);

Conventions de nommage

Health check et nettoyage

// Vérifier les sessions actives
function getActiveSessions() {
  try {
    const output = execSync(
      'tmux list-sessions -F "#{session_name}|#{session_activity}"',
      { encoding: 'utf8' }
    );
    return output.trim().split('\n').map(line => {
      const [name, activity] = line.split('|');
      return { name, lastActivity: new Date(parseInt(activity) * 1000) };
    });
  } catch (e) {
    return [];
  }
}

// Nettoyer les sessions terminées (inactives > 2h)
function cleanupSessions() {
  const sessions = getActiveSessions();
  const cutoff = Date.now() - 2 * 3600000;

  sessions.forEach(s => {
    if (s.lastActivity.getTime() < cutoff) {
      execSync(`tmux kill-session -t ${s.name}`);
      console.log(`Cleaned up session: ${s.name}`);
    }
  });
}

Chevauchement du vendredi soir

Le vendredi soir à 23h, deux tâches démarrent : le scanner (schedule #1) et, quand le scanner termine, la rétrospective (schedule #4). Grâce à tmux, les deux tournent dans des sessions séparées. La rétrospective attend que le scanner ait pushé ses résultats (elle a besoin des setups du jour pour les ajouter à son bilan). Le bot vérifie le commit du scanner avant de lancer la rétro :

// Attendre que le scanner ait pushé avant de lancer la rétro
async function waitForScannerThenRetro(dateStr) {
  const maxWait = 60 * 60000; // 60 min max
  const start = Date.now();

  while (Date.now() - start < maxWait) {
    const log = fs.readFileSync(
      `~/logs/scanner-${dateStr}.log`, 'utf8'
    );
    if (log.includes('git push origin main') &&
        log.includes('EXIT_CODE=0')) {
      launchPipeline('retro', dateStr, retroPrompt);
      return;
    }
    await sleep(30000); // Check toutes les 30s
  }
  notify('⚠️ Scanner timeout — rétrospective non lancée');
}

Source : tmux — terminal multiplexer manual

Prompt Engineering pour la Publication

Le prompt envoyé par le bot Discord à Claude Code n'est que la pointe de l'iceberg. Le vrai travail de « prompt engineering » est dans les fichiers de contexte persistant que Claude Code charge automatiquement à chaque session.

Anatomie d'un prompt automatisé

Un bon prompt de publication contient exactement 4 éléments :

La pyramide de contexte

Claude Code charge automatiquement une pyramide de fichiers de contexte, du plus général au plus spécifique :

Total : ~97KB (~24 000 tokens) de contexte persistant. C'est le « cerveau » du système. Chaque modification du CLAUDE.md change le comportement de tous les runs futurs — c'est pourquoi on le versionne dans git et on le traite comme du code, pas comme de la documentation.

Le pattern « Skill »

Au lieu de tout mettre dans le prompt, on référence un skill — un playbook versionné qui contient le workflow complet :

// ❌ AVANT : prompt monolithique (500+ mots)
const prompt = `
Nous sommes le 18 juin 2026. Lance le scanner.
Étape 1 : appelle GetRegimeProbability...
Étape 2 : appelle RunScreener avec les filtres...
Étape 3 : pour chaque ticker, vérifie sur SEC EDGAR...
Étape 4 : appelle QueryData types=quote,bars_daily...
... (200 lignes de plus)
`;

// ✅ APRÈS : invocation de skill (4 lignes)
const prompt = `
Nous sommes le jeudi 18 juin 2026.
Lance le pipeline /scanner pour la prochaine séance (vendredi 19 juin).
MCP obligatoire. Commit et push si ok.
`;

// Le skill scanner-pipeline.md (25KB) est chargé
// automatiquement quand Claude Code détecte le mot "scanner"
// dans le prompt. Pas besoin de le répéter.

L'avantage est triple : le prompt est court (moins de tokens par run = moins cher), le playbook est versionné (modifiable sans toucher au bot), et les mises à jour s'appliquent à tous les runs futurs sans redéploiement.

Avant / Après : la même tâche

Source : Anthropic — Claude Code project memory (CLAUDE.md)

Construire son Propre Système

Le système décrit dans cet article n'a pas été construit en un jour. Il a commencé par un seul schedule (le daily briefing), avec un prompt brut de 200 lignes et un cron job. Puis les erreurs ont forgé les règles. Le MCP HARD STOP est né d'un incident réel. L'anti-dilution check est né d'une recommandation catastrophique évitée de justesse. Le tiering market cap est né d'une war room. Chaque contrainte du système est une cicatrice — elle marque un problème qui s'est produit et qui ne se reproduira plus.

Estimation de coût

DailyTickers utilise Claude Code en abonnement (Max plan à $200/mois), pas l'API au token. Cela change fondamentalement l'économie : le coût est fixe, pas proportionnel au volume.

Avec l'abonnement, le coût marginal d'un article supplémentaire est effectivement $0 tant qu'on reste dans les quotas. C'est ce qui rend viable la publication de ~60 articles/mois avec données temps réel et mise en page professionnelle.

Articles liés

Ce guide fait partie d'une série technique sur l'infrastructure DailyTickers :

Source : Anthropic — Claude Code documentation