Le principe de « juste assez »¶

La règle¶

Pour franchir une porte, ne produire que ce qu'elle exige. Rien de moins. Rien de plus.

La machine d'états encode, pour chaque porte, des preconditions (checklist humaine) et des checks (validations automatisées). C'est la définition précise de ce qu'il faut pour passer. Tout le reste est optionnel, et souvent nuisible.

Pourquoi c'est dur¶

Les équipes — et les IA — ont un biais naturel vers la sur-production :

Documenter « au cas où ».
Ajouter des colonnes à un tableau « qui pourraient servir ».
Concevoir une architecture « pour anticiper » un cas qui n'arrivera peut-être jamais.
Écrire des user stories pour des features pas encore validées.
Générer des diagrammes qui ne seront pas relus.

Chaque ajout semble gratuit au moment où il est fait. En cumul, il produit :

Du bruit qui noie le signal utile.
De la dette mentale : chaque artefact doit être maintenu ou son obsolescence tracée.
De la rigidité prématurée : documenter un choix qui aurait pu rester ouvert le fige dans les esprits.
Un coût d'inattention : quand la décision cruciale arrive, les artefacts superflus ont consommé l'énergie qui aurait dû lui être consacrée.

Ce que le kit fait pour contrer le biais¶

1. Les portes imposent un périmètre¶

sdlc/schema.js est explicite. Pour passer G1 (Vision arrêtée d'un Business Epic), il faut :

Un asis.md et un tobe.md qui posent l'écart entre situation actuelle et cible
Un ehs.md (Epic Hypothesis Statement, via skill #be-hypothesis-statement)
Un lbc.md (Lean Business Case) et un okrs.md
Un decision.md daté avec sponsor et decision ∈ {go, conditional-go} (NO-GO si decision = no-go)

Il n'est pas exigé : un business plan détaillé, une matrice SWOT, une roadmap trimestrielle, un wireframe, un plan d'architecture. Ces artefacts peuvent être utiles ailleurs — pas pour cette porte.

2. Le Coach Développement Émergent ramène à la porte active¶

L'agent orchestrateur a pour consigne explicite : identifier la porte suivante et n'appeler que les skills qui y mènent. Si une session part en digression vers un artefact prématuré, le Coach recentre.

3. Les skills ont un périmètre strict¶

Chaque prompt (.github/prompts/*.prompt.md) cible un artefact, une porte. Le skill #be-hypothesis-statement produit hypothesis.md — pas une roadmap, pas un backlog, pas une architecture. Si l'utilisateur demande autre chose, le skill doit (idéalement) rediriger vers le bon skill.

4. L'invariant LIVING/COLD dissuade le travail spéculatif¶

Si un artefact n'est pas destiné à être gelé bientôt, il reste LIVING longtemps — ce qui visuellement signale qu'il n'est pas une décision. L'équipe apprend à ne pas investir trop dans des LIVING qui n'iront jamais vers COLD.

Le test du « juste assez »¶

Avant de rédiger, générer, documenter un artefact, se poser trois questions :

Quelle porte est active ?
Cet artefact est-il listé dans les preconditions ou les freeze de cette porte ?
Si non, pourquoi je le produis maintenant ?

Les seules réponses acceptables à la question 3 :

« Pour clarifier ma propre pensée en brouillon, que je jette ensuite. »
« Pour une porte ultérieure clairement planifiée dans cette vague. »
« Par commande explicite d'un sponsor (à tracer). »

Réponse inacceptable : « Parce que ça me semble une bonne idée. »

Le test inverse : « quelle porte est bloquée ? »¶

Si un projet stagne, la question n'est pas « qu'est-ce qui manque ? » mais « quelle porte attend un livrable spécifique, et ce livrable est-il vraiment produit ? »

Souvent, le projet a produit plein d'artefacts autour de la porte, mais pas l'artefact que la porte exige. C'est un symptôme classique. Le kit le rend visible : node sdlc/sdlc.js check <id> liste exactement ce qui manque.

Corollaire : le « pas encore »¶

Le kit valorise la phrase « pas encore ». Elle apparaît partout :

Dans les préconditions non satisfaites (item décoché de la checklist).
Dans les objets NOT_STARTED du registre.
Dans les skills qui refusent de livrer si les prérequis ne sont pas là.
Dans la communication avec les sponsors : « Cette décision n'est pas encore prise parce que nous attendons X. »

« Pas encore » n'est pas un aveu d'échec — c'est un aveu de discipline. L'équipe sait ce qu'elle ne sait pas, et le dit.

Les sponsors demandent souvent plus d'artefacts que le « juste assez » n'en exige : une roadmap visuelle, un plan d'investissement, un deck COMEX. Le kit ne les interdit pas — il les range hors de la machine d'états, dans des livrables dédiés de communication (voir skill #portfolio-priorisation, skill #atelier-incertitudes).

La règle : un artefact de communication sponsor ne remplace pas un artefact de porte. Ils coexistent, mais ne se confondent pas. Un deck COMEX élégant ne fait pas passer G3. Un Récit au DOR satisfait ne remplace pas un deck COMEX.

Voir aussi : Herméneutique · LIVING / COLD · Les 4 portes · Agent Coach Émergent.