Citadel : l'infrastructure d'autonomie pour vos agents Claude Code

Repartir de zéro à chaque session, ça suffit

Vous ouvrez une session avec votre assistant IA, vous ré-expliquez l'architecture, les conventions, les pièges du codebase. La session se termine, tout est perdu. Le lendemain, rebelote. Et dès qu'une tâche devient lourde — refondre une couche entière — c'est à vous de la découper à la main, de suivre l'avancement, de vérifier chaque morceau. Un simple fichier de consignes comme CLAUDE.md ou AGENTS.md aide, mais il reste passif : il ne route rien, ne retient rien, ne surveille rien.

Citadel comble ce vide. C'est un harness — une couche d'orchestration qui s'intercale entre vous et l'assistant pour encadrer et coordonner le travail des agents — conçu pour Claude Code et Codex. Là où CLAUDE.md décrit, Citadel agit : il route les demandes, capitalise ce que les agents apprennent, et pose des garde-fous de sécurité. Par orchestration, on entend ici le fait de faire travailler plusieurs agents ensemble — les lancer, répartir les tâches, collecter et fusionner leurs résultats — plutôt qu'un seul agent en solo.

Si vous connaissez BMAD, voyez le parallèle ainsi : BMAD structure la méthode (les documents de planification) ; Citadel fournit l'infrastructure d'autonomie (routage, mémoire, hooks, coordination, reviews). Les deux sont complémentaires.

« Stop re-explaining your codebase every session. Start compounding what your agents learn. »

Installation en deux commandes

Avant d'orchestrer quoi que ce soit, il faut brancher le plugin. Citadel est open source (licence MIT) et ne demande que Claude Code — ou Codex — et Node.js ≥ 18.

git clone https://github.com/SethGammon/Citadel.git
claude --plugin-dir /chemin/vers/Citadel

Une fois dans la session, lancez la première configuration :

/do setup

Cette commande détecte votre stack, installe les hooks et génère le fichier harness.json qui pilote le comportement du harness. C'est le seul passage obligé avant de commencer.

Le routeur /do : dire l'intention, pas la mécanique

Le vrai point d'entrée n'est pas une commande précise à mémoriser, mais votre intention. Vous décrivez ce que vous voulez, et /do classe la demande selon quatre critères — portée, complexité, besoin de persistance, parallélisme — puis la dispatche vers le chemin d'exécution le moins cher capable de la traiter : commande directe, skill, ou orchestrateur.

/do review src/auth/session.ts
/do overhaul the API layer

La première demande est légère : /do lance directement la review du fichier. La seconde est lourde : il déclenche le spawn de plusieurs agents en parallèle, chacun dans son espace isolé, qui partagent leurs découvertes puis fusionnent leurs résultats. Même porte d'entrée, deux trajectoires radicalement différentes — c'est tout l'intérêt du routage : ne sortir l'artillerie que quand la tâche le justifie.

Les skills restent invocables directement par leur slash-command si vous savez déjà ce que vous voulez : /review, /archon, /fleet, /setup.

Des revues de code en cinq passes

Plutôt qu'un vague « à améliorer », Citadel produit des retours localisés et actionnables : ce qui ne va pas, où, et quoi faire. Une seule commande suffit :

/review src/auth/session.ts

La revue (alias /do review) parcourt la cible selon cinq axes — correctness, security, performance, readability, consistency — et regroupe chaque finding par passe et par sévérité, avant de rendre un verdict. Vous choisissez la cible :

• un fichier : /review src/x.ts ;
• un dossier, exploré récursivement ;
• un diff : /review --diff HEAD~3 ou /review main..feature ;
• par défaut, vos changements staged + unstaged (git diff HEAD).

La sortie ressemble à ceci :

[correctness] src/auth/session.ts:42 — HIGH
  Le token expiré n'invalide pas la session : `expiresAt < now`
  devrait être `<=`. Cas limite non couvert par les tests.
  -> Corriger la comparaison et ajouter un test de bord.

[security] src/auth/session.ts:88 — MEDIUM
  Le cookie de session est posé sans l'attribut `Secure`.
  -> Forcer Secure + HttpOnly en production.

Verdict : 1 finding bloquant, 2 mineurs. Ne pas merger en l'état.

D'autres reviews spécialisées complètent l'arsenal : /merge-review, /security-review, /qa, /test-gen, et /verify qui contrôle qu'un changement fait bien ce qu'il doit de bout en bout.

Les hooks : le filet de sécurité

Un agent autonome qui peut lire des fichiers, lancer des commandes shell et modifier du code, ça inquiète — à raison. Les hooks sont la réponse de Citadel : des scripts déclenchés automatiquement sur des événements du runtime, qui servent à la fois de filet de sécurité et d'observabilité. Deux moments comptent :

• PreToolUse — avant qu'un outil s'exécute ; un hook peut alors bloquer l'action ;
• PostToolUse — après ; le hook observe, mesure, réagit.

Exemples réels installés par défaut :

• external-action-gate (PreToolUse, Bash) : bloque les actions externes non consenties — lecture de secrets dans un .env, requêtes réseau sortantes — tant que la session n'a pas donné son consentement ;
• governance (PreToolUse sur Edit, Write, Bash, Agent) : applique la constitution avant toute action à risque ;
• cost-tracker (PostToolUse, tous outils) : suit les tokens consommés et le coût ;
• circuit-breaker : sur échec répété, coupe une boucle qui s'emballe ;
• complexity-check (PostToolUse sur Edit/Write JS/TS) : garde-fou de complexité.

D'autres complètent le dispositif : doc-sync, config-change, file-changed, intake-scanner (au démarrage de session) et elicitation.

La constitution : gouverner ce que les agents ont le droit de faire

Les hooks bloquent techniquement ; encore faut-il une règle qui dise quoi bloquer. C'est le rôle de la constitution — un document de politiques, docs/CONSTITUTION.md, qui fixe ce que les agents peuvent et ne peuvent pas faire. Elle est hiérarchisée en trois niveaux :

• Tier 1 — « hard constraints » : contraintes qui bloquent toujours, non outrepassables par une instruction de session ;
• Tier 2 puis Tier 3 — priorité décroissante.

L'agent policy-enforcer lit ce document pour rendre un verdict allow ou block sur une action proposée. Les orchestrateurs l'invoquent systématiquement avant toute opération « Red » — comprendre : irréversible — pour éviter qu'un agent zélé ne supprime ce qu'il ne devrait pas.

L'orchestration autonome : Archon et Fleet

C'est là que Citadel change d'échelle. Pour une tâche qui dépasse une session ou un seul agent, deux orchestrateurs prennent le relais.

/archon est un agent de campagne autonome, multi-sessions : il décompose un objectif en phases, délègue à des sous-agents, revoit la qualité de leur travail, et maintient l'état de la campagne d'une session à l'autre — vous fermez, vous rouvrez, il reprend où il en était.

/archon
/fleet

/fleet, lui, est un orchestrateur parallèle : il lance plusieurs agents par vagues coordonnées, collecte leurs découvertes et partage le contexte d'une vague à la suivante. Chaque agent travaille dans un worktree isolé — une copie de travail séparée du dépôt Git, si bien que deux agents peuvent modifier des fichiers en parallèle sans se marcher dessus ; leurs résultats sont fusionnés ensuite.

Autour d'eux gravitent des agents de contrôle : policy-enforcer (juge de constitution), phase-validator (vérifie les conditions de sortie de chaque phase), arch-reviewer (repère les violations de frontières architecturales) et knowledge-extractor (extrait les patterns et pièges vers le wiki).

Une mémoire qui se capitalise

Voici l'atout qui justifie le slogan : ce que les agents apprennent ne s'évapore pas. Citadel persiste l'état des campagnes et enregistre la télémétrie — les données mesurées au fil de l'exécution : coût en tokens, décisions prises, ce que les gardes ont attrapé. Deux commandes transforment ce vécu en savoir réutilisable :

/learn
/postmortem

/learn compile les patterns, décisions et anti-patterns d'un travail terminé en pages de wiki structurées — intégrées au savoir existant, pas empilées en vrac. /postmortem génère le post-mortem d'une campagne : ce qui a cassé, ce que les garde-fous ont intercepté. Session après session, le codebase gagne une mémoire.

À savoir honnêtement

Toute cette puissance a un prix, et il serait malhonnête de le taire.

• Complexité ajoutée. Un harness, ses hooks, sa constitution, ses orchestrateurs : c'est une couche de plus à comprendre et à maintenir. Pour un script d'une heure, c'est disproportionné.
• Coût en tokens. Le multi-agents multiplie les appels au modèle : plusieurs agents en parallèle, plus les agents de contrôle qui les surveillent, consomment nettement plus qu'une session solo. Le routeur /do existe justement pour ne PAS sortir l'artillerie sur une petite tâche — encore faut-il lui laisser faire ce tri.
• Projet jeune. Citadel est en version 0.x/1.x : l'outil bouge vite, les commandes et les comportements peuvent évoluer d'une version à l'autre. À vous de suivre le dépôt et de figer une version si la stabilité prime.

Alors, Citadel ou pas ?

La réponse tient en une ligne de partage. Sur un gros codebase, pour du travail au long cours qui demande de l'autonomie et de la mémoire entre sessions, Citadel apporte une infrastructure qu'aucun fichier de consignes ne remplace. Pour une tâche ponctuelle et bien cadrée, un simple CLAUDE.md reste plus léger et suffit amplement.

Le meilleur moyen de trancher : l'essayer sur un vrai bout de code. Clonez le dépôt officiel, lancez /do setup, et regardez le routeur décider à votre place.

Pour d'autres retours sur l'outillage IA appliqué au dev, voir la catégorie Outils IA et la Veille YouTube IA quotidienne du site.