Templates¶

Le kit fournit des templates : structures vides ou pré-remplies qui facilitent le démarrage d'un artefact. Ils sont installés dans .meta/ du projet consommateur par le bootstrap.

Template — Expression Originelle (EO)¶

Fichier : .meta/template-eo.md

Usage : point de départ pour capturer une Expression Originelle brute (email, compte-rendu d'atelier, prise de note spontanée). Remplir puis déplacer vers .product/.epics/<BE-ID>/eo.md.

Source : meta/template-eo.md du kernel.

ÉTUDE D'OPPORTUNITÉ¶

FICHE D'IDENTITÉ¶

Champ	Valeur
Titre	[TITRE ÉTUDE D'OPPORTUNITÉ]
Date	[Date]

[Entités à l'origine de la demande et sponsors éventuels]

ORIGINE ET MOTIF DE LA DEMANDE¶

[Historique ou origine de la demande, passages en instance préalable, travaux antérieurs...]

ACTEURS ETUDE¶

Rôle	Nom
Référent PU	[Nom]
Participants CR référentes	[Noms]
Contributeurs Groupes (CAs et/ou producteurs)	[Noms]
Autres PU	[Noms]
Product Owner	[Nom]
Autres fonctions supports CATS	[Noms]

BESOIN¶

Elevator Pitch EHS¶

Section	Description
Pour	[les clients/utilisateurs]
Qui	[font quelque chose]
Le/La	[nom de l'ambition/projet]
Est un(e)	[quelque chose - le 'comment']
Qui	[apporte cette valeur]
À la différence de	[un concurrent, un existant ou l'absence d'existant, les irritants ou difficultés]
Notre ambition	[fait quelque chose de mieux - le 'pourquoi']

ASPECTS NON FONCTIONNELS¶

[Aspects non fonctionnels identifiés]

MARCHÉS¶

Marché	Concerné
PART	[ ]
BP	[ ]
PRO	[ ]
AGRI	[ ]
ENTREPRISE	[ ]

USERS¶

Utilisateur	Concerné
Conseiller	[ ]
Téléconseiller	[ ]
Back-Office	[ ]
Clients	[ ]
Prospects	[ ]

CANAUX¶

Canal	Concerné
Agences	[ ]
Plateforme téléphonique	[ ]
Siège	[ ]
NPC (espace client web)	[ ]
NMB (application mobile)	[ ]

PERIMETRE¶

[Nombre d'utilisateurs ou de clients concernés, volumétrie en jeu, étapes du processus, nombre de contrats...]

PERENITE DES BESOINS¶

Durée	Concerné
< 1 AN	[ ]
ENTRE 1 et 3 ANS	[ ]
ENTRE 3 et 10 ANS	[ ]
> 10 ANS	[ ]

AXE DE VALEUR¶

Axe	Sélection
Conquête & Développement Client	[ ]
Satisfaction Client	[ ]
Efficacité opérationnelle	[ ]
Réglementaire	[ ]

ARGUMENT DE VALEUR¶

[Arguments clefs de vente de la nouvelle offre proposée, identification des risques opérationnels mis sous contrôle et les pénalités financières évitées, description des étapes back office automatisées, explicitation du temps commercial libéré pour un conseiller, identification des irritants traités, arguments favorisant l'adoption d'un nouvel outil de vente...]

RESULTATS ATTENDUS¶

[Résultats attendus et objectifs mesurables]

SCORE VALEUR¶

Critère	Valeur
Score	[Faible/Moyen/Faible]
Criticité temporelle	[Faible/Moyenne/Inconnue]
Convergence	[Faible/Moyenne/Inconnue]
Efforts	[Faible/Moyen/Élevé]
Commentaires	[Commentaires sur le score valeur]

Template — PRD (Product Requirements Document)¶

Fichier : .meta/template-prd.md

Usage : point de départ pour rédiger le PRD d'une Feature pendant le statut fe.PRD_EN_COURS (entre G2 et G3, introduit en v3 par ADR-0009). Remplir puis déplacer vers .product/.features/<FE-ID>/prd.md. Le PRD reste LIVING jusqu'à G3 où il est figé en même temps que spec.md et plan-fab.md.

Frontmatter requis par G3 (check prd-meta) :

problem_statement — quel problème, pour qui, avec quel impact mesurable.
user_personas — primaire, secondaire, éventuellement opérateur.
success_criteria — critères mesurables (métrique + seuil + baseline) distincts des OKRs BE.

Skill associé : #prd-architect — chaîne architect → refiner → critique pour produire le PRD à partir du plan-dev.md de la BE parente.

Source : meta/template-prd.md du kernel.

title: "PRD — [Nom de la Feature]" feature_id: "FE-XX" parent_be: "BE-XX" status: draft problem_statement: "[phrase unique : quel problème, pour qui, avec quel impact mesurable]" user_personas: - primaire: "[persona principale — celle qui bénéficie directement]" - secondaire: "[persona annexe — impactée par la bascule]" success_criteria: - "[critère mesurable 1 — ce qui doit être vrai en fin de cycle]" - "[critère mesurable 2]" - "[critère mesurable 3]"

PRD — [Nom de la Feature]¶

Ce document est LIVING pendant les phases PRD_EN_COURS et FAB_PLAN_EN_COURS. Il est gelé en COLD au passage de la porte G3 en même temps que spec.md et plan-fab.md. Les clés de frontmatter problem_statement, user_personas et success_criteria sont requises par le check prd-meta de G3.

Contexte¶

[Lien avec la Business Epic parente — extrait pertinent du plan-dev.md de la BE, positionnement dans le cycle MVP courant, filière pilote confirmée.]

Problème¶

Situation actuelle¶

[Description narrative du problème tel qu'il se manifeste aujourd'hui. Quel est le signal de déclenchement ? Quelle friction concrète, observée chez quelle population ?]

Coût du statu quo¶

[Impact mesurable si on ne fait rien : temps perdu, opportunités manquées, risque opérationnel, coût caché. Si possible, chiffrer — même grossièrement.]

Personas¶

Rôle	Persona	Enjeu	Implication dans le cycle
Primaire	[Nom / rôle]	[Ce qu'elle gagne]	[Co-conception, test, validation]
Secondaire	[Nom / rôle]	[Comment elle est impactée]	[Formation, change management]
Opérateur	[Nom / rôle]	[Ce qu'elle doit bascule]	[Procédure, runbook]

Critères de succès¶

Critères mesurables (distincts des OKRs de la BE, qui portent sur l'outcome business global). Ceux-ci portent sur le livrable Feature.

#	Critère	Mesure	Seuil attendu	Baseline
1	[Qu'est-ce qui doit être vrai ?]	[Métrique / preuve]	[Valeur cible]	[Valeur actuelle]
2	[...]	[...]	[...]	[...]
3	[...]	[...]	[...]	[...]

Scope¶

Dans le scope¶

[Fonctionnalité ou flux 1 — traité par la Feature]
[Fonctionnalité ou flux 2]
[...]

Hors scope (non-objectifs)¶

[Ce que la Feature ne couvre pas, explicitement — pour fermer la porte aux demandes dérivantes pendant la fabrication.]
[Report éventuel sur une autre Feature ou un cycle ultérieur.]

Hypothèses produit¶

Ce que l'on tient pour vrai au moment de la rédaction du PRD. Une hypothèse fausse = remise en cause du cadrage → re-G3 (retour en FAB_PLAN_EN_COURS) ou abandon FE.

[H1 — hypothèse usage / comportement utilisateur]
[H2 — hypothèse technique / faisabilité]
[H3 — hypothèse marché / adoption]

Dépendances¶

Amont	Nature	État
[Autre Feature / système]	[Donnée, API, décision gouvernance]	[Disponible / attendue le …]

Aval	Nature	Impact attendu
[Feature / système aval]	[Ce qui consomme cette Feature]	[Contrat d'interface]

Risques produit¶

#	Risque	Probabilité	Impact	Mitigation
1	[Adoption faible par persona primaire]	[Faible/Moyenne/Élevée]	[Faible/Moyen/Élevé]	[Approche de mitigation]
2	[Dérive de scope pendant la fabrication]	[...]	[...]	[...]
3	[Dépendance amont non levée à temps]	[...]	[...]	[...]

Questions ouvertes¶

[Ce qui reste à trancher avant G3. Chaque question devrait être résolue avant le freeze du PRD — sinon elle se transforme en risque ou en hypothèse produit.]

[Question 1]
[Question 2]
[Question 3]

Références¶

Business Epic parente : [BE-XX]
plan-dev.md BE : [extrait pertinent]
Études / entretiens utilisateurs : [liens]
ADR-0009 : cadrage v3 du PRD dans la machine d'états sdeg-kernel

Pourquoi des templates minimaux ?¶

Le kit privilégie la capture fidèle sur la structuration prématurée. Un template trop détaillé induit des réponses formatées qui perdent la texture originelle du propos sponsor.

Règle d'or : le template doit inviter à écouter, pas à combler des cases. Les cases vides sont des invitations à interroger plus loin, pas des attentes à satisfaire.

Ajouter un template projet¶

Les templates livrés par le kernel sont génériques. Un projet consommateur peut :

Créer ses propres templates dans .meta/ (non écrasés par le bootstrap).
Les référencer dans son propre guide d'usage.
Ne pas les placer dans .sdeg/meta/ — ce dossier est rechargé à chaque update.

Ce que les templates ne sont pas¶

Pas des formulaires : il n'y a rien à valider, rien à soumettre.
Pas des livrables finaux : le livrable est produit par un skill à partir du template.
Pas des contrats : ils évoluent avec le kit, sans rupture.

Voir aussi : Première session · Skills de cadrage.