Délègue en parallèle : les subagents

C'est quoi un subagent ?

Un subagent est un processus séparé qui gère une tâche de façon indépendante. C'est l'analogie la plus proche d'un « employé IA » : tu lui confies une mission délimitée, il travaille dans son coin avec le contexte et les outils nécessaires, puis te ramène le résultat. L'agent principal — celui avec qui tu converses — devient un chef d'orchestre : il découpe le travail, délègue, et assemble les résultats.

Ton skill principal /post va déléguer à des subagents et collecter leurs résultats. Comme ils tournent en parallèle, les tâches indépendantes (publier sur 4 plateformes) se font simultanément au lieu d'une à la fois. C'est le changement d'échelle de ce chapitre : on passe d'un assistant qui fait les choses vite à un système qui fait plusieurs choses en même temps.

La vraie superpuissance : le contexte isolé

Le gain de temps est l'avantage visible, mais il y en a un second, plus subtil et tout aussi précieux : chaque subagent travaille dans sa propre fenêtre de contexte. Souviens-toi du chapitre 2 : le bruit dégrade les réponses. Quand un subagent adapte ton post pour Instagram, il charge les règles Instagram, les échantillons Instagram, fait ses essais — et tout ce volume ne pollue pas la conversation principale. L'agent principal ne reçoit que le résultat final, propre.

Sans subagents, publier sur 4 plateformes remplirait ta fenêtre de contexte de quatre fois tout ce travail intermédiaire, et la session deviendrait confuse bien avant la fin. Avec eux, ta conversation principale reste un journal de bord lisible : mission, délégation, résultats. C'est pour ça que les subagents sont utiles même pour des tâches séquentielles volumineuses — explorer une grosse base de code, analyser dix documents — pas seulement pour le parallélisme.

Définir des subagents spécialisés (optionnel mais puissant)

Claude Code peut lancer des subagents génériques à la volée — c'est ce que fera ton skill. Mais tu peux aussi définir des subagents nommés et spécialisés, avec la commande /agents ou en créant des fichiers dans .claude/agents/. Chaque fichier décrit un rôle : son nom, sa description (qui sert à Claude pour savoir quand le solliciter), les outils auxquels il a droit, et son prompt système.

---
name: redacteur-instagram
description: Adapte un contenu au format Instagram (légende + hashtags) dans la voix de la marque. Utiliser pour toute publication Instagram.
tools: Read, Write, Bash
---

Tu es le spécialiste Instagram de la marque.
Tu lis brand-voice.md avant toute rédaction.
Format : accroche forte, légende aérée, 3 à 5 hashtags en fin.
Tu ne publies jamais sans média associé.

L'intérêt de la spécialisation : un subagent « rédacteur Instagram » avec un rôle précis et des outils restreints est plus fiable qu'un généraliste, exactement comme dans une équipe humaine. Et limiter ses outils (pas d'accès réseau pour un relecteur, par exemple) est une mesure de sécurité gratuite. Pour le projet de Léa, le skill avec subagents à la volée suffit — mais garde cette carte en tête pour tes systèmes plus ambitieux.

Skill, hook, subagent : qui fait quoi ?

À ce stade du cours, tu as trois mécanismes d'extension. Ils se ressemblent de loin, mais chacun répond à une question différente — et les confondre est l'erreur la plus courante des débutants :

Les trois se combinent naturellement : le skill décrit la procédure, qui délègue à des subagents, dont chaque action passe sous les hooks. C'est exactement l'architecture du système de Léa.

Passer le skill en multi-plateforme

mets à jour le skill /post pour supporter « all » :
/post "sujet" all

quand la plateforme est « all » :
- crée le visuel une seule fois
- lance un subagent par plateforme (twitter, linkedin, instagram, facebook)
- chaque subagent adapte le texte au format, aux limites et à la voix de la plateforme
- tous publient en parallèle
- journalise tous les résultats

Note le détail « crée le visuel une seule fois » : c'est un choix d'architecture. La génération du visuel est coûteuse et le résultat est partagé — elle reste donc dans l'agent principal, avant la délégation. Seul le travail réellement indépendant (adapter le texte, publier, journaliser) part en parallèle. Identifier ce qui est partagé et ce qui est indépendant, c'est le cœur de la conception d'un système parallèle.

Lance ensuite : /post "nos engagements zéro déchet" all. Claude crée un visuel, rédige les variantes selon ta voix, te demande validation, puis lance les subagents. Tu verras plusieurs blocs de tâches s'exécuter simultanément dans l'interface — c'est ton équipe au travail.

flowchart TD
  M["/post sujet all"] --> V["Visuel créé une seule fois"]
  V --> S1["Subagent Twitter"]
  V --> S2["Subagent LinkedIn"]
  V --> S3["Subagent Instagram"]
  V --> S4["Subagent Facebook"]
  S1 --> J["Journal + URLs"]
  S2 --> J
  S3 --> J
  S4 --> J

Pourquoi pas en séquence ?

Chaque publication est asynchrone : Claude envoie le post puis interroge l'API toutes les quelques secondes jusqu'au statut « publié » (5 à 30 s selon la plateforme). 4 posts en série = jusqu'à 2 minutes d'attente cumulée, pendant lesquelles rien d'utile ne se passe. 4 subagents en parallèle = une seule attente, celle du plus lent.

Chaque subagent gère son propre cycle asynchrone : envoyer, interroger, traiter la réponse, journaliser. La rédaction des variantes et la validation, elles, restent dans l'agent principal — tu valides une fois, puis tout part en parallèle. Et si un subagent échoue (API en panne, quota dépassé), les trois autres terminent normalement : tu ne reprends que la plateforme en échec, pas tout le lot.

Les limites du parallélisme

Le réflexe « tout paralléliser » serait une erreur. Le parallélisme a un coût : chaque subagent consomme ses propres tokens, et orchestrer a sa propre complexité. Il ne vaut le coup que si les tâches sont réellement indépendantes (aucune n'a besoin du résultat d'une autre) et assez longues pour que l'attente cumulée pèse. Adapter quatre posts : parfait. Trois étapes dont chacune dépend de la précédente (rechercher → rédiger → publier) : aucune parallélisation possible, c'est une chaîne.

Le bon test : dessine ton flux comme le diagramme ci-dessus. Les branches qui partent du même nœud sans se toucher ensuite sont parallélisables ; tout ce qui s'enchaîne verticalement ne l'est pas. Deux minutes de schéma évitent des heures d'architecture inutilement complexe.