Méthodologie — spec-first, domain-driven

Je ne prompte pas mes agents.
J'écris un contrat avec eux.

Une spec domaine. Des stories qui tranchent au lieu de décrire. Un agent dev qui suit une archi qu'il ne peut pas contourner. Un agent QA qui rejoue la story sur l'app déployée. Ce qui tourne en prod, c'est ce qui est écrit.

1 🧭 Spec domaine PRD + epics le vocabulaire du métier décisions tranchées 2 📋 Stories écrite avec l'agent PM 1 story = 1 contrat hors-scope écrit depends_on déclaré 3 🏗️ Agent Dev lit le layou-dev-kit domain → data → UI 1 agent par story 4 🧪 Quality gate lint · tests · archi i18n + widgetbook review adversariale 5 🚀 Release build web + TestFlight l'app est déployée pas un mock 6 🤖 Agent QA rejoue la story sur l'app en prod light + dark PASS → story done FAIL → nouvelle story La story le contrat

Survole une étape pour l'isoler. Les nœuds ouvrent le fichier réel, copiable. Fais glisser le graph. Touche un nœud pour ouvrir le fichier réel.

Le contrat

Un prompt s'évapore.
Une story se rejoue.

C'est toute la différence. Une story se relit, se review, se teste, et six mois plus tard elle explique encore pourquoi le code est comme ça. Un agent qui reçoit une story n'a rien à deviner — et un agent qui devine, il invente.

Et je ne la tape pas moi-même. L'agent PM me cuisine : il pose les questions qui piquent, je tranche, il rédige. La story sort de cette séance — c'est exactement pour ça qu'elle contient des décisions et pas des options. Mon boulot dans l'histoire, ce n'est pas l'écriture : c'est d'arbitrer, et de signer.

story-b2-distance-duration-auto.md
  • status: où en est la story dans la boucle
  • fr: FR-16 l'exigence du PRD qu'elle couvre — la traçabilité remonte jusqu'à la spec
  • epic: le lot auquel elle appartient
  • dev_kit: ../layou-dev-kit l'archi que l'agent dev relit avant d'écrire une ligne
  • depends_on: ce qui doit exister avant — c'est ce qui autorise le parallèle

Ce que la story tranche

  • Des décisions, pas des options. « Routes API (New), parce que le SDK JS legacy est inutilisable en Dart. » L'agent n'arbitre pas : il applique.
  • Le hors-scope, écrit. C'est la ligne qui empêche un agent zélé de refactorer la moitié de l'app.
  • Le comportement en cas d'échec. API muette → on ne remplit rien, le champ reste éditable. Pas de crash, pas de 0,00 € silencieux.
  • Des tâches numérotées. T0…T7. Une story qui ne se découpe pas est une story trop grosse.
Cycle de vie
draft ready-for-dev in-progress review done
Une story

Un agent. Un cycle complet : spec lue, code écrit, quality gate, release, QA. Bout en bout.

Un lot

Plusieurs stories indépendantes → plusieurs agents en parallèle. Agent A sur le sélecteur client, Agent B sur la persistance, en même temps.

Les dépendances

depends_on dit qui attend quoi. Deux agents ne se marchent dessus que si la spec a oublié de le dire.

L'agent dev

Une archi qu'il ne peut pas contourner

Le layou-dev-kit est un repo à part, posé à côté de l'app. La story pointe dessus, l'agent le lit avant de coder. Ce ne sont pas des conseils : ce sont des invariants. Quand l'agent accélère ×10, c'est la seule chose qui empêche le code de partir en vrille ×10.

  • 01 presentation n'importe jamais data.
  • 02 domain n'importe ni data, ni presentation, ni Firebase, ni Flutter UI.
  • 03 La racine lib/ = shell, router, startup, DI. Rien d'autre.
  • 04 Tout SDK externe est wrappé avant d'atteindre le code de l'app.
  • 05 Usecase obligatoire pour les writes, les effets de bord, les décisions métier.
  • 06 Ordre d'implémentation : domain → data → app → presentation.
  • 07 UI : screen → connector → organism → molecule.
  • 08 Clean Architecture dès le jour 1. Même pour un MVP. Zéro code jetable.
Voir l'architecture en visualisation interactive →

L'agent QA

Des tests verts
ne prouvent pas que l'app marche.

Alors le QA ne lit pas le code : il ouvre un vrai navigateur sur l'app déployée et rejoue la story, écran par écran, comme un utilisateur. Le piège : une app Flutter rend dans un <canvas> — il n'y a rien à cliquer. La solution tient en une ligne d'architecture : chaque élément interactif porte un Semantics(identifier:) stable. C'est ce qui rend l'app pilotable par un agent.

  • Sur l'app déployée L'E2E tape l'URL de prod. Pas un mock, pas un émulateur : ce que l'utilisateur touche.
  • Light ET dark Chaque écran, dans les deux thèmes. C'est là que 80 % des régressions visuelles sortent.
  • Une suite par epic epic-1-auth, epic-4-calculator, epic-7-acceptance… + un run-all qui les enchaîne.
  • Screenshot à chaque étape La preuve est visuelle. Je relis un parcours complet en 30 secondes.
  • Ce qui est stub est écrit Le plan de test dit ce qui n'est pas encore bâti → l'agent ne remonte pas de faux bugs.
  • PASS → done. FAIL → story. Un bug ne part pas dans un backlog flou : il redevient une story, avec son contrat.

Honnêtement

Ce que la méthode ne fait pas

Ça ne décide pas à ma place

La spec, les arbitrages produit, le go/no-go : c'est moi. Les agents exécutent un contrat, ils ne le signent pas.

Ça ne remplace pas l'expertise

Si tu ne sais pas pourquoi une liste non lazy va ramer sur un vieux Android, aucun agent ne te le dira spontanément.

Ça ne pardonne pas une story floue

Story vague = code vague, ×10 en vitesse. Le goulot d'étranglement n'est plus le code : c'est l'écrit.

Ce n'est pas du waterfall

Une décision tombe en cours de route ? La story se corrige, le PRD aussi. Ce qui est figé, c'est ce qui est écrit — pas le plan.

Tu veux cette boucle sur ton app ?

Flutter/mobile senior, 7+ ans, delivery accélérée par agents. 20 minutes pour voir si je suis le bon profil.

Réserver un fit-call