Summoner - Quand l orchestrateur s orchestre lui-même

Le paradoxe

Summoner est un dashboard pour piloter des sessions Claude Code. Je l’ai construit avec Claude Code. Première boucle.

Mais le jour 3, j’ai voulu aller plus loin : permettre à Claude Code d’utiliser Summoner comme un outil. Pas juste un humain qui clique sur un dashboard, une IA qui appelle l’API de Summoner pour lancer d’autres sessions IA. Deuxième boucle.

Le concept est vertigineux. Claude Code, dans une session Summoner, utilise le serveur MCP de Summoner pour lancer une nouvelle session Claude Code dans un autre projet. L’orchestrateur qui orchestre, piloté par ce qu’il orchestre.

MCP en 30 secondes

Model Context Protocol. Un standard ouvert pour donner des outils à un LLM. Au lieu de décrire textuellement ce que l’IA peut faire, on lui expose des fonctions typées qu’elle peut appeler directement. Comme une API, mais conçue pour les IA.

Le serveur MCP de Summoner expose les opérations du dashboard comme des outils : lister les projets, lancer une session, vérifier son statut, envoyer un message, exécuter un workflow. Claude Code voit ces outils comme des fonctions natives. Il peut orchestrer plusieurs projets dans une seule conversation.

Le premier test

Le prompt : « Lance les tests sur un projet, puis déploie le jardin si tout passe. »

Claude Code appelle le MCP pour démarrer une session de tests. Le dashboard Summoner affiche la session qui démarre. Les tests tournent. Le WebSocket streame l’output en temps réel dans le dashboard pendant que Claude Code attend le résultat via MCP.

Les tests passent. Claude Code reçoit le statut de succès. Il appelle une nouvelle session pour le déploiement. Le build se lance, les assets sont générés, le conteneur Docker est reconstruit.

Deux projets orchestrés, zéro intervention humaine au-delà du prompt initial. Le dashboard montrait les deux sessions en parallèle, chacune avec son flux de logs.

Le risque de la récursion

Le problème prévisible : un workflow qui lance une session Claude, qui décide de lancer une autre session, qui en lance une autre. Chaque session spawne un process node-pty. Chaque process consomme de la mémoire. Sans garde-fou, ça explose.

C’est le même pattern qu’un max_call_stack dans un langage de programmation. Il faut une condition d’arrêt explicite. La profondeur de récursion doit être limitée, au-delà d’un certain niveau, Summoner refuse de lancer une nouvelle session et retourne une erreur.

C’est un choix architectural, pas un détail d’implémentation. Sans cette limite, la première boucle accidentelle transforme le laptop en radiateur.

Les workflows YAML

Le vrai pouvoir du MCP n’est pas dans les appels ponctuels. C’est dans les workflows, des séquences d’étapes décrites en YAML que Summoner exécute comme un pipeline CI/CD pour IA.

Le workflow engine supporte 7 types d’étapes : prompt Claude, commande shell, requête HTTP, code JavaScript, sleep, condition, et gate d’approbation manuelle. Les dépendances forment un DAG. Les étapes indépendantes tournent en parallèle. Les étapes de type claude spawne une session MCP. Les étapes de type shell exécutent une commande directement.

On peut déclencher un workflow à la demande, sur un cron, ou via webhook. Le BMAD orchestrator structure les phases de travail en Baseline/Measure/Analyze/Design avec des prompt templates dédiés.

Le tout visible en temps réel dans le dashboard.

Le vertige

Il y a un moment, le troisième soir, où j’ai réalisé ce que j’étais en train de faire. J’utilisais Claude Code pour écrire le code du serveur MCP qui allait permettre à Claude Code de se piloter lui-même via Summoner que j’avais construit avec Claude Code.

Trois niveaux de méta. Le serpent qui se mord la queue, mais chaque morsure produit du code fonctionnel.

Le plus étrange : ça marche. L’idée qu’un LLM puisse orchestrer ses propres instances via un protocole standard, en suivant un workflow déclaratif, avec des garde-fous explicites, c’est un pattern qui va devenir courant. Aujourd’hui, c’est encore le genre de truc qu’on code tard le soir en se demandant si on est allé trop loin.

Ce que j’en retiens

La récursion en IA a les mêmes risques que la récursion en programmation : sans condition d’arrêt, ça explose. Le contrôle de profondeur n’est pas optionnel, c’est une décision architecturale fondamentale.

Et la leçon méta : les outils les plus intéressants sont ceux qui peuvent être utilisés pour se construire eux-mêmes. Summoner orchestrant Claude Code qui améliore Summoner, c’est un flywheel. 23 commits, 3 jours, ~35 000 lignes de code, 4 packages. Le genre de boucle vertueuse qui, avec les bons garde-fous, accélère tout ce qu’elle touche.