Workflows
Quatre workflows décrit ici dominent le paysage agentique à l’heure actuelle (le workflow built-in Claude Code, Spec-kit, Superpower et BMAD). Beaucoup d’axes les départagent (devx, vitesse, coût, efficacité), mais un seul structure leur philosophie : ce qu’ils laissent comme trace. L’axe va de zéro artefact à une équipe agile entière de personas qui en produisent des dizaines. C’est cet axe que nous suivons ici ; les autres se lisent en filigrane.
Un workflow découpe l’instruction d’entrée en phases et fait transiter des artefacts (chapitre 5.1) d’une phase à l’autre. Le “bon” workflow alterne étapes déterministes (lint, build, test) et étapes inférentielles (raisonner, implémenter), pour que les étapes obligatoires ne dépendent pas du LLM. Plus il matérialise d’artefacts, plus il offre de continuité et de parallélisation, mais au prix de plus de friction.
Claude Code built-in
Claude Code ne matérialise rien. C’est l’option zéro de l’axe : un changement de mode (SHIFT+TAB) modifie l’agent à la volée, tout vit dans la fenêtre de contexte et meurt à la session suivante.
- Fonctionnement : SHIFT+TAB bascule entre trois modes :
- Normal : l’agent propose chaque action et demande confirmation humaine avant d’écrire
- Plan : l’agent explore le code, raisonne et produit un plan qu’il soumet à validation humaine. Aucune modification tant que le plan n’est pas approuvé
- Édition auto-accept : l’agent applique directement ses modifications sans confirmation
- Artefacts de travail : aucun, by design. Plan et édition ne créent aucun document sauf demande explicite. Tout disparaît à la session suivante.
- Adapté pour : tâches unitaires où la perte de mémoire entre sessions n’est pas un problème.
- Limite : pas de continuité ni de parallélisation. Dès que la tâche grossit ou doit survivre à un
/clear, il faut passer à un workflow qui produit des artefacts.
Spec-kit
Spec-kit place la spec au centre et dérive le code. Toolkit open-source de GitHub pour le Spec-Driven Development, il installe une séquence de commandes, chacune produisant un artefact qui nourrit la commande suivante.
- Fonctionnement :
/speckit.constitution: principes et contraintes permanents du projet (cf. chapitre 4.3, doctrine)/speckit.specify: le quoi et le pourquoi (cf. 5.1, Specification)/speckit.clarify: l’agent lit la spec, repère ambiguïtés et cas limites, pose des questions dont les réponses sont réinjectées (cf. 5.1, Exploration)/speckit.plan: stack et architecture (cf. 5.1, Plan d’implémentation)/speckit.tasks: découpage en tâches ordonnées par dépendances, marquées[P]quand parallélisables/speckit.implement: pour l’exécution- garde-fous qualité optionnels :
/speckit.checklist,/speckit.analyze.
- Artefacts de travail : un dossier
specs/(constitution, spec, plan, tasks) où chaque phase laisse une trace. - Adapté pour : une feature avec ambiguïté réelle ou plusieurs étapes, qui demande continuité entre sessions et possibilité de paralléliser.
- Limite : overhead de cérémonie disproportionné pour une tâche unitaire. La qualité dépend du sérieux mis dans la phase
clarify.
Superpower
Superpower ajoute la discipline qui rend les artefacts exécutables. Là où Spec-kit fournit la structure, Superpower fournit la méthode : spécification, TDD, revue, avant d’écrire la moindre ligne.
- Fonctionnement :
- Brainstorm : raffinement de l’idée par questions, exploration d’alternatives, design validé par sections (cf. 5.1, Exploration)
- Plan : plan exécutable avec chemins de fichiers exacts, commandes, test qui échoue, implémentation minimale, message de commit (cf. 5.1, Plan d’implémentation)
- Exécution : des sous-agents implémentent tâche par tâche, avec une revue en deux temps après chacune
- Artefacts de travail : artefacts de phase (brainstorm, plan détaillé) + les skills réutilisables eux-mêmes (red-green-refactor TDD, debug en 4 phases, authoring de nouveaux skills). Seul des quatre à capitaliser au-delà de la tâche via sa bibliothèque de skills (pont vers le chapitre 5.3).
- Adapté pour : qui cherche une méthodologie reproductible avec TDD strict, revue systématique, exécution parallélisée par sous-agents.
- Limite : prescriptif. La discipline (tests d’abord, revue) est un coût si elle n’est pas désirée. Plus lourd à adopter qu’un workflow adhoc, et suppose d’adhérer à ses partis pris.
BMAD
BMAD multiplie les artefacts jusqu’à reproduire une équipe agile entière. Breakthrough Method of Agile AI-Driven Development : un système multi-agents où chaque rôle d’une équipe humaine devient un persona « Agent-as-Code ».
- Fonctionnement : des fichiers markdown décrivent expertise, responsabilités, contraintes et livrables des personas qui se relaient sur un cycle agile :
- Planning : Analyst + PM + Architect → PRD et design d’architecture (cf. 5.1, Specification + décisions d’archi, cf. chapitre 4.3)
- Story generation : le Scrum Master découpe en story files prêtes pour le dev (≈ découpage du Plan d’implémentation)
- Development : des agents Developer implémentent chaque story sur une branche dédiée, avec tout le contexte de planning
- QA : PR + revue multi-agents automatisée, chaque quality gate vérifié.
- Artefacts de travail : les plus nombreux et les plus formels avec PRD, diagrammes d’architecture, test plans, sprint stories, tous persistants et versionnés comme des livrables.
- Adapté pour : un projet ou une feature d’ampleur où l’on veut tracer chaque rôle et chaque décision comme dans une équipe humaine.
- Limite : le plus lourd des quatre. BMAD démultiplie la cérémonie et la maintenance des personas. Surdimensionné pour une tâche simple, et retombe vite dans le « trop d’artefacts » (chapitre 5.1).
Un axe sépare les quatre workflows : ce qu’ils laissent comme trace
- Claude Code n’en produit aucun et survit le temps d’une session
- Spec-kit en aligne quatre pour passer le cap du
/clear - Superpower ajoute la discipline qui les rend exécutables
- BMAD les multiplie jusqu’à reproduire une équipe
Le choix n’est pas une question de préférence mais d’échelle : on prend le plus léger qui tient la tâche.