Herald : le serveur MCP qui se développe lui-même

On a tous vécu ce moment : 45 min de design system sur le Claude.ai (ou sur le tel), et Claude Code qui nous répond “Hello, what are we building today?” 💀 Quand tu arrives devant ta console…

Herald me trottait dans la tête depuis des mois. Un pont entre Claude Chat et Claude Code. Piloter mon poste de dev depuis mon téléphone.

Voici l’histoire de Herald — un serveur MCP auto-hébergé qui relie Claude Chat à Claude Code — et la session où il a gagné sa propre confiance.

Le problème

Si vous utilisez Claude pour développer, vous connaissez le problème du cerveau coupé en deux. Claude Chat tourne dans votre navigateur et sur votre téléphone — parfait pour réfléchir, planifier, discuter. Claude Code tourne dans votre terminal — parfait pour écrire et exécuter du code. Mais ils ne se parlent pas. Ils ne partagent rien. Pas de contexte, pas de mémoire, pas de coordination.

Vous passez 20 minutes à affiner une architecture avec Claude Chat. Puis vous ouvrez votre terminal, et Claude Code repart de zéro. Vous devez tout ré-expliquer. À. Chaque. Fois.

L’idée

Et si Claude Chat pouvait dire à Claude Code quoi faire ? Directement. Depuis votre téléphone.

Pas par copier-coller. Pas par un document partagé. Via le protocole MCP (Model Context Protocol) officiel qu’Anthropic a construit exactement pour ça.

C’est Herald. Un binaire Go qui tourne sur votre poste de travail, expose un endpoint MCP en HTTPS, et permet à Claude Chat de dispatcher des tâches à Claude Code. Lancer un refactoring, suivre la progression, lire le diff — tout depuis votre téléphone pendant que votre machine fait le travail.

📱 Claude Chat (téléphone / web)
     │
     ▼ MCP over HTTPS
🖥️  Herald (votre poste de travail)
     │
     ▼ lance & gère
⚡ Claude Code (exécute les tâches)

Du zéro au serveur fonctionnel

Lundi soir : recherche de l’écosystème. Personne n’avait construit ce pont. Le protocole Custom Connectors était documenté, des bibliothèques MCP existaient en Go, mais personne n’avait connecté les pièces.

Mardi : rédaction de la spec, validation du marché (50K-100K développeurs utilisent Claude Code), choix de la stack. Go 1.26, routeur chi, SQLite pur Go, six dépendances au total. Binaire unique, zéro CGO, cross-compilable.

Mercredi matin : Herald tournait. Neuf outils MCP enregistrés, OAuth 2.1 avec PKCE, exécution de tâches avec isolation par branche Git. Je l’ai connecté comme Custom Connector dans Claude Chat et j’ai vu les outils apparaître.

C’est là que ça devient intéressant.

Utiliser Herald pour construire Herald

Premier vrai test : est-ce que Herald peut développer Herald ?

J’ai ouvert Claude Chat sur mon téléphone et j’ai demandé de scaffolder la feature mémoire v0.2 — un système de contexte partagé entre Chat et Code. Herald a dispatché la tâche à Claude Code sur mon poste. Claude Code a lu le codebase existant, créé la structure du package, écrit les interfaces Go, stubbé les implémentations, lancé go vet et la suite de tests, et tout commité sur une nouvelle branche.

Deux minutes trente-cinq. Six fichiers créés. Soixante-huit tests existants toujours verts. Tout depuis mon téléphone.

Ensuite j’ai demandé un README. Claude Chat — via Herald — a dispatché la tâche. Claude Code a lu chaque fichier source du repo, compris l’architecture, écrit un README en anglais et en français, et commité les deux. Trois minutes.

Ça marchait. Mais fonctionnel ne veut pas dire sûr. Herald expose Claude Code sur le réseau. Chaque vulnérabilité est potentiellement une exécution de code à distance sur votre machine. J’avais besoin de savoir ce que j’avais raté.

L’audit de sécurité

J’ai demandé à Claude Chat de lancer un audit de sécurité complet du codebase Herald. Le prompt était détaillé — vérifier les flux d’auth, le path traversal, l’injection de commandes, l’injection SQL, la gestion des secrets, la concurrence, les dépendances. Lire chaque fichier.

Herald a dispatché l’audit comme une tâche. Claude Code a lancé des sous-agents en parallèle — un pour l’auth, un pour l’exécuteur, un pour le store, un pour le réseau/concurrence. Chaque sous-agent a lu les fichiers pertinents, analysé le code, et remonté ses trouvailles. L’agent principal a compilé le tout en un rapport structuré.

Quatre minutes quarante-sept secondes. Cinquante-sept tours de raisonnement.

Le résultat : un rapport d’audit formel. Vingt trouvailles sur cinq niveaux de sévérité.

La bonne nouvelle : des fondations solides. SQL paramétré partout, JWT avec HMAC-SHA256 et vérification de signature en temps constant, tokens stockés par hash, prompts passés via stdin et pas en arguments CLI, exec.CommandContext avec échappement propre des arguments. Zéro vulnérabilité connue dans les dépendances (govulncheck clean).

La mauvaise nouvelle : six vulnérabilités critiques.

Six critiques

Voici ce que l’audit a trouvé :

C1 — Open Redirect : L’endpoint d’autorisation OAuth acceptait n’importe quel redirect_uri sans validation. Un attaquant pouvait rediriger le code d’autorisation vers son propre serveur et l’échanger contre des tokens. Bypass complet de l’authentification.

C2 — Contournement PKCE : PKCE n’était appliqué que si le client fournissait un code_challenge. L’omettre, et toute la vérification de preuve de possession disparaissait. Combiné avec C1, c’était game over.

C3 — Pas de rate limiting : La config définissait des limites. Le middleware n’était jamais câblé. Requêtes illimitées sur tous les endpoints. Brute force, déni de service, accumulation de coûts API — tout grand ouvert.

C4 — Pas de limite de concurrence : maxConcurrent était un champ du task manager. Il n’était jamais vérifié. Chaque appel à Start() lançait une goroutine immédiatement. Processus Claude Code illimités.

C5 — Timeout non borné : timeout_minutes contrôlé par l’utilisateur sans validation de maximum. Passez 999999 et votre tâche tourne indéfiniment.

C6 — Timing attack sur le secret client : Le secret client était comparé avec != au lieu de subtle.ConstantTimeCompare. Le secret était stocké en clair dans le struct. Une analyse statistique des temps de réponse pouvait l’extraire octet par octet.

Lire cette liste m’a refroidi. J’avais construit une crypto solide pour les tokens JWT mais laissé la porte d’entrée grande ouverte sur le flux OAuth.

Dix-huit minutes, six correctifs

Je les ai tous corrigés. Via Herald. Depuis Claude Chat.

Chaque fix suivait le même pattern : créer une branche, lire le code actuel, implémenter le correctif, mettre à jour les tests existants, ajouter des tests de sécurité, vérifier la compilation et la suite complète de tests, commiter.

Quelques moments marquants :

Le fix C2 a trouvé et corrigé un bug pré-existant — oauthError() passait nil comme *http.Request à http.Redirect, ce qui aurait paniqué en production. Le fix de sécurité a attrapé un crash gratuitement.

Le fix C3 a implémenté un rate limiter token bucket complet sans dépendance externe — pur Go avec sync.Mutex, nettoyage périodique des entrées périmées, limitation par token et par IP, header Retry-After. Le tout depuis un seul prompt de tâche.

Le fix C5 a ajouté une défense en profondeur sur deux couches — le handler MCP clamp le timeout, et le task manager le clamp à nouveau indépendamment. Même si le handler a un bug, le manager n’autorisera jamais une exécution non bornée.

Le fix C6 est allé plus loin que la recommandation de l’audit : au lieu de juste passer en comparaison temps constant, il a hashé le secret client au repos avec SHA-256. Même si le struct est dumpé de la mémoire, le secret brut a disparu.

Après les six correctifs : 23 tests d’auth qui passent, tests de rate limiter verts, tests de timeout verts, suite complète au vert avec le race detector. Zéro régression.

Ce que ça signifie

Herald qui développe Herald, ce n’est pas un gadget. C’est la preuve que l’outil fonctionne.

Quand j’écris le README et qu’il dit “Lancez un refactoring depuis votre téléphone, suivez la progression, lisez le diff” — ce README a été écrit depuis mon téléphone, via Herald. Quand la section sécurité liste neuf mesures de durcissement — ces mesures ont été auditées et corrigées via Herald.

Toute la session de développement — spec, scaffolding, README, audit, six correctifs critiques — s’est déroulée en un après-midi, depuis Claude Chat, dispatchée via Herald vers Claude Code tournant sur mon poste de travail. Je n’étais pas devant mon ordinateur pour la majeure partie.

C’est le workflow que Herald permet. Pas pour moi spécifiquement, mais pour tout développeur qui utilise Claude Code et veut se détacher de son terminal.

La suite

Herald est open source sous licence MIT. C’est une alpha — fonctionnelle, auditée, mais une alpha.

La feuille de route :

• v0.1 ✅ — Serveur core. Pont MCP, tâches async, intégration Git, OAuth 2.1.
• v0.2 🔄 — Mémoire partagée entre Claude Chat et Claude Code. Le pont de contexte.
• v0.3 — Dashboard web temps réel avec SSE.
• v1.0 — API stable, option d’hébergement managé.

Si vous utilisez Claude Code et que le problème du cerveau coupé en deux vous frustre, Herald est peut-être ce que vous cherchez.

→ github.com/btouchard/herald

Construit par Benjamin Touchard. Herald développe Herald.