En bref : J’ai construit un orchestrateur autonome avec Claude Code qui gère quatre pans de mon activité sans intervention permanente : rédaction de contenu, suivi commercial, audit SEO et analyse business. Le système fonctionne avec des fichiers Markdown comme file d’attente, un heartbeat régulier, et des garde-fous stricts. Voici comment reproduire cette architecture pas à pas.
Un assistant qui travaille pendant que je fais autre chose
Depuis plus de vingt ans, je dirige plusieurs services SaaS dans l’emailing et la data B2B. La réalité quotidienne, c’est un empilement de tâches qui reviennent sans cesse. Rédiger des articles pour cinq sites différents. Générer des briefs commerciaux pour l’équipe chaque lundi matin. Suivre les abonnements, analyser le churn, mettre à jour les plans de contenu SEO. Aucune de ces tâches n’est particulièrement complexe prise isolément. Mais leur accumulation finit par dévorer les journées.
J’ai commencé à utiliser Claude Code comme assistant interactif. Un prompt, une réponse, un copier-coller. Classique. Puis j’ai réalisé que je tapais les mêmes commandes tous les matins, que je relançais les mêmes analyses chaque semaine, que je reformulais les mêmes consignes à chaque article.
La question s’est imposée d’elle-même : est-ce que je peux faire en sorte que l’agent travaille seul, avec des règles claires, et qu’il me prévienne quand c’est terminé ?
La réponse est oui. Et ça ne nécessite pas une seule ligne de code au sens traditionnel du terme. Pas de Python, pas de Node.js, pas d’API à câbler. Juste Claude Code, des fichiers Markdown, et une architecture bien pensée.
Ce que j’ai aujourd’hui, c’est un orchestrateur central qui tourne en tâche de fond. Il vérifie régulièrement s’il y a quelque chose à faire. Si oui, il délègue à un agent spécialisé. Si non, il se rendort. L’ensemble produit des articles, des briefs commerciaux, des rapports d’analyse et met à jour mes plans de contenu SEO, sans que j’aie besoin d’être devant l’écran.
L’architecture : un dispatcher, quatre agents spécialisés
Le principe fondamental de l’orchestrateur tient en une phrase : il ne fait rien lui-même. Son rôle, c’est de lire, décider et déléguer.
Concrètement, j’ai un projet Claude Code central. Son fichier CLAUDE.md définit son identité : « tu es un dispatcher, pas un exécuteur ». Il connaît l’existence de quatre sous-agents, chacun installé dans son propre répertoire de travail avec ses propres instructions et ses propres accès.
Les quatre workflows correspondent à quatre métiers distincts :
- Contenu : rédaction d’articles de blog pour les différents sites, avec vérification anti-IA automatique et génération de prompts d’illustration
- Commercial : lecture du CRM, génération de briefs pour les commerciaux, suivi du pipeline de vente
- SEO : audit de positionnement, analyse de la concurrence, mise à jour des plans de contenu
- Analyse : synthèses stratégiques, suivi des abonnements, reporting financier
Chaque sous-agent charge uniquement les fichiers de son propre projet. L’agent de rédaction ne voit jamais le CRM. L’agent commercial ne touche pas aux plans de contenu SEO. Cette isolation n’est pas qu’une question d’organisation, elle évite de surcharger la fenêtre de contexte avec des informations inutiles. Un agent qui a trop de contexte perd en pertinence. C’est quelque chose que j’ai appris à mes dépens lors des premières tentatives où un seul agent gérait tout.
L’analogie la plus juste, c’est celle d’un chef de projet qui a quatre collaborateurs spécialisés. Il reçoit les demandes, identifie qui est le mieux placé pour traiter, transmet les consignes et vérifie que le livrable est conforme.
La file d’attente en Markdown : zéro base de données
Le choix le plus contre-intuitif de cette architecture, c’est probablement celui-ci : toute la gestion des tâches passe par des fichiers Markdown. Pas de base de données, pas de Redis, pas de système de queue sophistiqué. Un fichier queue.md avec des sections et des blocs de texte.
Le fichier est structuré en cinq sections qui correspondent aux statuts possibles d’une tâche :
- En attente d’approbation : les tâches qui nécessitent ma validation avant d’être lancées
- À faire : validées, prêtes à être prises en charge
- En cours : une seule tâche à la fois, toujours
- Terminé : archivage de la semaine en cours
- Échoué : avec la raison de l’échec et un compteur de tentatives
Chaque tâche comporte un tag de workflow ([contenu], [commercial], [seo], [analyse]), un niveau de priorité, une date de création, et parfois une échéance.
Pourquoi Markdown plutôt qu’une vraie base de données ? Trois raisons. D’abord, Claude Code lit et écrit du Markdown nativement, sans outil supplémentaire. Ensuite, je peux ouvrir le fichier dans n’importe quel éditeur pour voir instantanément l’état du système. Enfin, le tout est versionné dans Git, ce qui me donne un historique complet et gratuit de chaque action passée.
En complément de la queue, deux autres fichiers d’état complètent le dispositif :
log.md: un journal horodaté de chaque action. Qui a fait quoi, quand, avec quel résultat.recurring.md: le planning des tâches récurrentes, celles qui reviennent tous les jours ou chaque semaine à jour fixe.
Le système entier est lisible par un humain en moins de trente secondes. Pas besoin de tableau de bord ni d’interface dédiée.
Le heartbeat : donner un pouls à l’agent
Un orchestrateur qui ne se réveille jamais ne sert à rien. Il faut un mécanisme pour le déclencher à intervalles réguliers. C’est le principe du heartbeat : un signal externe qui dit à l’agent « réveille-toi et regarde s’il y a du travail ».
Il existe deux approches pour ça.
La première, celle que j’utilise, passe par RunClaudeRun. C’est une application macOS gratuite qui offre une interface graphique pour planifier des exécutions de Claude Code. On définit un prompt, une fréquence, un répertoire de travail, et l’application s’occupe du reste. Pas besoin de toucher au terminal pour configurer la récurrence.
La seconde approche, tout aussi valable, consiste à utiliser un cron classique avec Claude Code en mode headless. Le flag -p transforme Claude Code en agent non interactif, pilotable depuis n’importe quel script. Une ligne dans la crontab suffit :
*/30 8-19 * * 1-5 cd ~/mon-projet && claude -p "/heartbeat"
Cette ligne lance le heartbeat toutes les trente minutes, entre 8h et 19h, du lundi au vendredi. L’avantage du cron, c’est que ça tourne sur n’importe quel système. L’avantage de RunClaudeRun, c’est la visibilité : on voit les tâches planifiées, les historiques d’exécution, et on peut modifier la fréquence en deux clics.
Avec un abonnement Claude Max, lancer Claude Code via un cron ou un scheduler est parfaitement conforme aux conditions d’utilisation d’Anthropic. C’est d’ailleurs un cas d’usage documenté dans leur documentation officielle.
À chaque heartbeat, l’orchestrateur exécute la même séquence :
- Vérifier qu’on est dans la plage horaire autorisée
- Lire la file d’attente
- S’il y a une tâche « À faire » : prendre la plus prioritaire, la passer « En cours », déléguer au sous-agent approprié
- Si la queue est vide : vérifier les tâches récurrentes du jour
- Si vraiment rien à faire : noter « idle » dans le journal et se rendormir
Une règle stricte : une seule tâche par heartbeat. Ça peut sembler lent, mais c’est un choix délibéré. Chaque exécution de Claude Code a sa propre fenêtre de contexte, propre et fraîche. Pas de pollution entre les tâches, pas de confusion. La tâche suivante sera traitée au prochain battement.
Les guardrails : ce que l’agent n’a pas le droit de faire
Donner de l’autonomie à un agent IA sans poser de limites, c’est la recette pour les catastrophes. J’ai mis en place un fichier de garde-fous qui définit explicitement ce que l’agent peut et ne peut pas faire. Ce fichier a une particularité : il est marqué comme non modifiable, y compris par l’agent lui-même, même si on le lui ordonne.
Les actions bloquées sont redirigées vers la file d’attente d’approbation. L’agent ne peut pas :
- Envoyer un email ou un SMS à un client ou un prospect
- Publier sur un site en production
- Modifier du code sur une branche principale
- Supprimer des données
- Toucher à des documents contractuels ou financiers
- Répondre à un client en mon nom
- Engager une dépense
En revanche, l’agent a carte blanche pour :
- Rédiger des brouillons (jamais publiés directement)
- Analyser des données CRM, analytics, SEO
- Générer des rapports et des synthèses
- Lire tous les fichiers de tous les projets
- Créer des fichiers dans les dossiers de travail
- Mettre à jour les fichiers d’état du système
C’est le modèle « human-on-the-loop » plutôt que « human-in-the-loop ». La nuance est réelle. Dans un système human-in-the-loop, l’humain valide chaque étape. Ici, l’humain supervise et n’intervient que sur les actions sensibles. Le reste tourne en autonomie.
La confiance se construit progressivement, et c’est un point à ne pas sous-estimer. Au début, j’avais placé beaucoup plus d’actions dans la catégorie « approbation requise ». Au fil des semaines, en constatant que l’agent faisait les bons choix, j’ai élargi son périmètre d’autonomie. Mais les actions à impact externe, celles qui touchent un client ou engagent la société, restent sous validation humaine. Et ça ne changera pas.
Les sous-agents : chacun son métier, chacun son contexte
Chaque sous-agent est un projet Claude Code autonome avec son propre fichier CLAUDE.md, ses propres skills, et ses propres accès aux outils externes.
L’agent rédacteur est le plus abouti des quatre. Il rédige des articles pour cinq sites différents en respectant une charte éditoriale précise définie dans un skill dédié. Après la rédaction, il lance automatiquement une vérification anti-IA via une API de détection. Si le score dépasse un seuil fixé à l’avance, il ré-humanise les passages détectés et reteste. Il génère aussi le prompt pour créer l’illustration de l’article. Livrable final : un fichier Markdown complet avec en-tête structuré, prêt à être relu et publié, plus un fichier texte pour l’image.
L’agent commercial se connecte au CRM pour récupérer les données du pipeline. Il génère des briefs structurés pour chaque commercial de l’équipe : affaires en cours, relances à faire, statistiques de performance. Ces briefs sont envoyés par email chaque lundi matin. Règle absolue : l’agent ne contacte jamais les prospects lui-même. Il prépare le travail pour les humains.
L’agent SEO dispose d’outils d’analyse de positionnement et de recherche de mots-clés. Il audite les sites, identifie les opportunités de contenu, et met à jour les plans éditoriaux. Quand l’agent rédacteur termine un article, l’agent SEO est automatiquement notifié pour mettre à jour le suivi.
L’agent analyste travaille sur les données business : suivi des abonnements, analyse du churn, synthèses stratégiques. Il a accès aux documents internes et produit des rapports hebdomadaires.
Le point commun entre ces quatre agents : aucun d’entre eux ne soupçonne l’existence des trois autres. Ils ne communiquent jamais directement entre eux. Toute la coordination passe par l’orchestrateur central et la file d’attente partagée.
Les tâches récurrentes : le planning automatique
L’orchestrateur ne se contente pas de traiter les tâches qu’on lui soumet. Il sait aussi ce qu’il doit faire de sa propre initiative, grâce au planning de récurrences.
Le fichier recurring.md décrit les tâches automatiques :
- Tous les jours : vérifier le plan de contenu et lancer la rédaction d’un article si les conditions sont réunies (maximum un article par jour tous sites confondus, maximum un par site et par semaine)
- Chaque lundi : générer les briefs commerciaux pour l’équipe
- Chaque mardi : produire le rapport de suivi des abonnements
- Chaque lundi : rédiger la synthèse hebdomadaire d’activité
Quand la queue est vide au moment du heartbeat, l’orchestrateur consulte ce planning. Si une tâche récurrente est due, il la crée dans la file d’attente et la traite au battement suivant. Ce mécanisme transforme l’orchestrateur de simple exécuteur de commandes en système véritablement proactif.
Pour la rédaction d’articles, les règles de priorisation évitent la surproduction. L’orchestrateur choisit en priorité les articles « socle » d’un silo thématique avant les articles satellites. Il respecte la phase du plan de contenu. Et il transmet au rédacteur le contexte de maillage interne nécessaire pour insérer les bons liens vers les articles déjà publiés.
La synthèse hebdomadaire est rédigée directement par l’orchestrateur, sans passer par un sous-agent. Il relit le journal de la semaine, compte les tâches terminées et échouées, identifie les tendances, et produit un résumé structuré. C’est mon tableau de bord du lundi matin.
Le chaînage : quand une tâche en déclenche une autre
L’un des mécanismes les plus utiles de toute l’architecture, c’est le chaînage automatique des tâches. Quand un agent termine son travail, l’orchestrateur peut créer une tâche de suivi sans la moindre intervention humaine.
Exemple concret : l’agent rédacteur termine un article pour un des sites. L’orchestrateur marque la tâche comme terminée, puis crée automatiquement une tâche SEO pour mettre à jour le plan de contenu. L’agent SEO, au heartbeat suivant, prend cette tâche, marque l’article comme « rédigé » dans le fichier de suivi, vérifie la cohérence du maillage interne, et identifie le prochain article à rédiger dans le planning.
Ce chaînage fonctionne avec des règles simples définies dans les instructions du dispatcher. Quand une tâche de type [contenu] passe en « Terminé », créer une tâche [seo] de mise à jour. Pas de moteur de workflow complexe, juste des conditions lisibles dans un fichier Markdown.
Le résultat, c’est un flux continu de travail sans intervention. Un article est rédigé le mardi, le plan de contenu est mis à jour le mardi soir ou le mercredi matin, et le prochain article est identifié et planifié pour le lendemain. La boucle tourne.
Ce que j’aurais fait différemment
Ce système n’est pas né d’un coup. Il a évolué par itérations, et certaines étapes étaient franchement des impasses.
Ma première tentative reposait sur un daemon local qui faisait tout tourner dans un seul projet, avec un seul agent omniscient. L’agent avait accès au CRM, aux sites web, aux plans de contenu, aux documents stratégiques, le tout en même temps. Le résultat était médiocre. Trop de contexte tue la pertinence. L’agent perdait le fil, mélangeait les consignes d’un workflow avec celles d’un autre. J’ai abandonné cette approche après quelques semaines d’essais peu concluants.
Le découpage en sous-agents spécialisés a tout changé. Chaque agent a un périmètre clair et limité. Ses instructions tiennent sur quelques pages. Il ne connaît que ce dont il a besoin pour sa mission. La qualité des livrables a fait un bond immédiat.
Autre apprentissage : la règle « une tâche par heartbeat » paraît contraignante au premier abord, mais elle élimine une catégorie entière de problèmes. Quand un agent enchaîne plusieurs tâches dans la même session, les erreurs de la première contaminent la seconde. Le contexte se pollue, les hallucinations augmentent. Mieux vaut repartir de zéro à chaque battement.
Sur la question du coût : je fonctionne avec un abonnement Claude Max. Pour un usage professionnel qui couvre quatre workflows quotidiens et des dizaines de tâches par semaine, le rapport qualité-prix est sans commune mesure avec l’embauche d’un assistant ou l’externalisation de ces tâches.
Le conseil le plus important si vous voulez construire quelque chose de similaire : commencez petit. Un seul agent, une seule tâche récurrente, des guardrails très restrictifs. Élargissez le périmètre uniquement quand vous avez confiance dans le système. La tentation de tout automatiser d’un coup est forte. Elle mène droit au mur.
Questions fréquentes
Faut-il savoir coder pour mettre en place un orchestrateur ?
Non, et c’est ce qui rend l’approche accessible. L’orchestrateur repose entièrement sur des fichiers Markdown et la configuration native de Claude Code. Pas de Python, pas de serveur à déployer. Il faut par contre être à l’aise avec le terminal et comprendre la logique de l’automatisation.
Claude Code peut-il publier directement sur un site WordPress ?
Techniquement oui, via des connecteurs dédiés qui permettent de créer des articles dans WordPress. Mais dans mon architecture, c’est une action bloquée par les guardrails. L’agent rédige des brouillons Markdown. La publication reste une décision humaine. Un article publié avec une erreur factuelle ou un ton inadapté, c’est un risque réputationnel que je ne délègue pas.
Combien de temps faut-il pour mettre en place un tel système ?
Le premier agent fonctionnel avec une tâche récurrente peut tourner en une journée. L’architecture complète avec quatre sous-agents, les guardrails, le chaînage et les récurrences m’a demandé environ trois semaines en itérations progressives. Le plus long, ce n’est pas la technique. C’est l’affinage des instructions pour que les livrables soient réellement exploitables sans retouche.
L’orchestrateur peut-il tourner sur un serveur distant ?
Claude Code fonctionne en local sur la machine où il est installé. Pour un fonctionnement 24/7, il faudrait une machine allumée en permanence, un Mac Mini dédié par exemple. Dans mon cas, le créneau 8h-19h en semaine couvre largement les besoins. L’agent n’a pas besoin de tourner la nuit pour absorber la charge quotidienne.
Peut-on utiliser un autre modèle que Claude pour l’orchestration ?
L’architecture Markdown et le principe du heartbeat sont transposables à d’autres outils. Mais la force de Claude Code, c’est son intégration native avec le système de fichiers, les skills, et les sous-agents. Reproduire cette mécanique avec un autre LLM demanderait de développer une couche d’outillage que Claude Code fournit nativement.
Que se passe-t-il quand une tâche échoue ?
L’agent marque la tâche comme échouée avec la raison de l’erreur et un compteur de tentatives. Au heartbeat suivant, si la tâche a échoué moins de trois fois, l’orchestrateur peut retenter. Au-delà, elle reste en échec et je reçois une notification pour intervenir manuellement. En pratique, les échecs sont rares et concernent surtout des problèmes de connectivité avec les outils externes.
