#0. Résumé en dix lignes
| Élément | Contenu |
|---|---|
| Persona | Analyste d'affaires — persona n° 7 du brief commun (§9) |
| Douleur dominante | Exigences qui meurent dans un document mort |
| Ce que KySpectra apporte | L'exigence cesse d'être un paragraphe dans un fichier : elle devient un objet versionné, typé, relié, validé en EARS, visible sur un tableau et relié à ce qui la teste |
| Surfaces concernées | Portail client — espace de travail projet ; vues spec, boards, graph, review, artifacts, delivery ; pages /projects/{id}/specify, /projects/{id}/analyze, /projects/{id}/feedback ; tableau public /public/feedback |
| Services réels sollicités | spec-service (4107), copilot-service (4118), collaboration-service (4128), artifact-service (4129), test-quality-service (4109), audit-compliance-service (4113) |
| Offre recommandée | Palier Équipe — 49,00 $ CAD/mois [Hypothèse] — plafond d'autonomie N2 |
| Ce qu'on ne promet pas | Remplacer votre outil de suivi de tickets ; remplacer votre traitement de texte ; une application mobile ; un gain de productivité chiffré |
| Statut de la chaîne | Maillons Comprendre, Spécifier, Concevoir, Vérifier 🟢 Livrés ; place de marché de capacités 🟡 En cours ; application mobile ⚪ Planifiée |
| Preuve la plus parlante | Langage naturel → objets de spécification proposés, relus par un humain avant écriture, puis reliés à des tests, à des artefacts BPMN et à un tableau de suivi — le tout dans une seule base versionnée |
| Risque d'adoption | La personne attend un éditeur de documents plus confortable ; KySpectra remplace le document par une structure de données, ce qui est un changement de méthode avant d'être un changement d'outil |
#1. Portrait
Camille, 36 ans, analyste d'affaires. Iel travaille dans une organisation de 600 personnes qui a trois directions métier — opérations, service à la clientèle, finances — et deux équipes de développement, l'une interne, l'autre fournie par un prestataire. Iel est le point de passage obligé entre les cinq.
Iel a commencé en support applicatif, puis a bifurqué vers l'analyse il y a huit ans. Ce parcours lui a laissé une conviction : une exigence mal formulée coûte toujours plus cher qu'une exigence écrite lentement. Iel a vu passer trois méthodologies, deux outils de gestion d'exigences abandonnés en cours de route, et un nombre indéterminé de documents de 60 pages que plus personne n'ouvre après la deuxième semaine.
C'est là le cœur du problème : iel produit des documents d'exigences que personne ne relit après la deuxième semaine. Le document est validé, signé, versionné dans un espace partagé — puis il vit sa vie de fossile pendant que le projet, lui, continue de bouger.
#1.1 Sa journée réelle
Iel arrive vers 8 h 45. Iel a en moyenne trois initiatives actives, à des maturités différentes. Sa journée est faite d'entretiens métier, de reformulations, de tableaux comparatifs et de messages de clarification. Iel écrit beaucoup, mais le plus gros de son temps part en synchronisation : redire à l'équipe A ce que l'équipe B a décidé, retrouver quelle version d'une règle fait foi, expliquer une troisième fois pourquoi une contrainte existe.
Iel n'a aucune visibilité fiable sur ce qui est réellement construit. Iel l'apprend en recette, souvent trop tard pour infléchir quoi que ce soit sans coût.
#1.2 Sa boîte à outils actuelle
| Catégorie | Ce qu'iel utilise aujourd'hui |
|---|---|
| Rédaction d'exigences | Traitement de texte et tableur, modèles maison, numérotation manuelle |
| Partage | Espace documentaire d'entreprise, avec versions v3_final_relu_VF |
| Suivi de travail | Outil de tickets géré par les équipes de développement, où iel a un accès en lecture |
| Modélisation | Outil de diagrammes générique, dessins refaits à la main à chaque changement |
| Ateliers | Réunions d'alignement, tableau blanc numérique, notes reprises ensuite à la main |
| Retours utilisateurs | Boîte courriel partagée, formulaire interne, remontées du service à la clientèle |
| Communication | Messagerie d'entreprise, où se prennent la moitié des arbitrages — et où ils disparaissent |
#1.3 Ce qui le fait juger — par les directions métier et par les équipes de développement
- La clarté de ses exigences : combien de questions les développeurs doivent poser avant de commencer.
- Le nombre d'écarts découverts en recette qui auraient dû être détectés à l'analyse.
- Sa capacité à dire, à tout moment, où en est une demande métier.
- Le fait que les trois directions se reconnaissent dans ce qui est livré, sans s'être accordées entre elles au préalable.
#1.4 Ce qui l'empêche de dormir
- Le document que personne n'ouvre. Iel y a passé trois semaines. Il est déjà faux.
- La règle de gestion contradictoire. Deux directions ont demandé l'inverse l'une de l'autre, et personne ne s'en apercevra avant la mise en production.
- La recette. Le moment où l'écart entre ce qui a été demandé et ce qui a été construit devient public.
- La question « pourquoi ? ». Six mois après, iel ne retrouve plus la décision métier qui a produit une exigence, seulement l'exigence.
Sa phrase à iel, telle qu'iel la dirait en entretien : « Je n'ai pas besoin d'écrire plus vite. J'ai besoin que ce que j'écris reste vivant, relié à ce qui est construit, et retrouvable quand on me demande pourquoi. »
#2. Douleurs — mécanisme de coût et fréquence
Chaque douleur est décrite avec le mécanisme par lequel elle coûte (temps perdu, risque encouru, décision retardée) et sa fréquence observée.
| # | Douleur | Mécanisme de coût | Fréquence |
|---|---|---|---|
| D1 | Document d'exigences périmé dès la troisième semaine. Le fichier est figé, le projet continue de bouger. | Temps perdu : maintien manuel de plusieurs versions parallèles. Risque : deux équipes travaillent sur deux vérités différentes. | À chaque initiative, dès la troisième semaine |
| D2 | Exigence formulée de façon ambiguë. « Le système doit gérer les remboursements » — sans déclencheur, sans acteur, sans condition. | Temps perdu : questions de clarification à répétition. Décision retardée : la tâche stagne avant même d'être prise. | Plusieurs exigences par lot de rédaction |
| D3 | Absence de lien entre exigence et test. La recette teste ce qu'elle comprend, pas ce qui a été demandé. | Risque encouru : une exigence entière peut n'être couverte par aucun test sans que personne ne le sache. | À chaque campagne de recette |
| D4 | Écart entre demande et livraison découvert en recette. Le décalage se voit quand le coût de correction est maximal. | Temps perdu : reprise complète d'un lot. Décision retardée : arbitrage d'urgence entre report et acceptation dégradée. | 1 à 3 fois par trimestre et par initiative |
| D5 | Allers-retours avec les développeurs. Chaque zone d'ombre devient un fil de messagerie asynchrone. | Temps perdu : demi-journée de latence par question, des deux côtés. Coût de dérivation : iel devient un goulot d'étranglement permanent. | Quotidienne |
| D6 | Absence de traçabilité vers la décision métier. L'exigence existe ; la décision qui l'a produite a disparu. | Temps perdu : reconstitution de l'historique en interrogeant des personnes. Risque : on revient sur une décision déjà arbitrée. | Mensuelle, et systématique à chaque audit interne |
| D7 | Réunions d'alignement répétées. Les mêmes points sont rediscutés parce qu'aucune trace commune ne fait autorité. | Temps perdu : mobilisation simultanée de plusieurs directions. Décision retardée : l'arbitrage attend la prochaine réunion. | 2 à 4 réunions par semaine |
| D8 | Changement d'exigence non propagé. Une règle change ; le test, le diagramme et l'exigence dérivée ne suivent pas. | Risque encouru : incohérence livrée en production. Temps perdu : chasse manuelle aux dépendances. | À chaque changement d'exigence structurante |
| D9 | Aucune vue du statut réel. Iel ne sait pas ce qui est en analyse, en construction, en recette, ni ce qui est bloqué. | Décision retardée : impossible de répondre à une direction métier sans relancer trois personnes. | Continue |
| D10 | Retours utilisateurs dispersés. Courriels, formulaires, remontées du service à la clientèle, notes de réunion. | Temps perdu : consolidation manuelle. Risque : un signal fort passe inaperçu parce qu'il est arrivé par le mauvais canal. | Hebdomadaire |
| D11 | Doublons d'exigences entre directions. Trois directions demandent la même chose avec trois vocabulaires différents. | Temps perdu : rédaction et recette en triple. Risque : trois implémentations divergentes de la même règle. | À chaque cadrage multi-direction |
#3. Réponse produit — uniquement des fonctionnalités réelles
Règle appliquée : chaque ligne cite la surface du portail ou le service réel. Une douleur sans réponse aujourd'hui est signalée telle quelle, avec son statut honnête.
| Douleur | Fonctionnalité KySpectra qui y répond | Où c'est dans le produit | Statut | Ce que ça change concrètement |
|---|---|---|---|---|
| D1 Document périmé | Spécification exécutable : objets versionnés, typés, reliés — l'exigence n'est plus un paragraphe, c'est une donnée | spec-service (4107) — GET /api/v1/projects/{id}/spec-items, GET /api/v1/spec-items/{id} ; portail : /projects/{id}/spec et /projects/{id}/spec/{itemId} |
🟢 Livré | Il n'y a plus de « version qui fait foi » à retrouver : il y a un objet, avec son historique. |
| D1 Document périmé | Baselines de spécification : figer un état de référence sans figer le travail | spec-service — GET /api/v1/projects/{id}/baselines |
🟢 Livré | Le gel contractuel devient un instantané daté, pas un fichier joint à un courriel. |
| D2 Exigence ambiguë | Validation EARS : la formulation est contrôlée par la plateforme, pas par la relecture d'un pair | spec-service, drapeau EARS_GENERATION_ENABLED à vrai |
🟢 Livré | « Quand X survient, le système doit Y » devient la forme attendue, vérifiée à l'écriture. |
| D2 Exigence ambiguë | Copilote de spécification : du langage naturel vers des objets proposés, relus avant écriture | copilot-service (4118) — POST /api/v1/copilot/ask, proposition relue via GET /api/v1/copilot/save-objects/{id} ; portail : /projects/{id}/specify |
🟢 Livré | Iel dicte l'intention métier ; la plateforme propose des objets structurés ; iel décide de ce qui est écrit. |
| D2 Exigence ambiguë | Métamodèle par projet : validation d'un modèle propre au projet, au-delà de la forme générique | spec-service — métamodèles et validation de modèle |
🟢 Livré | Les règles de rédaction de votre organisation deviennent une contrainte outillée, pas une consigne de guide de style. |
| D3 Exigence sans test | Couverture des critères d'acceptation rattachée aux objets de spécification | test-quality-service (4109) — /test-plans, /test-cases, /test-suites, /test-cycles, /runs ; portail : vue test (capacité test:read) |
🟢 Livré | On répond à « quelles exigences sont couvertes ? », pas seulement à « quel pourcentage de lignes ? ». |
| D3 Exigence sans test | Traçabilité bidirectionnelle : de l'exigence vers ce qui la vérifie, et retour | spec-service — GET /api/v1/spec-items/{id}/traceability, GET …/{id}/relationships ; portail : vue graph et /projects/{id}/trace |
🟢 Livré | Une exigence orpheline de test devient visible avant la recette, pas pendant. |
| D4 Écart en recette | Analyse d'écarts entre l'intention exprimée et la spécification en place | spec-service — POST /api/v1/projects/{id}/spec/analyze ; portail : /projects/{id}/analyze |
🟢 Livré | L'écart est un objet affiché et discutable, pas une découverte de dernière minute. |
| D4 Écart en recette | Vue de revue : écarts, matrice de traçabilité, décision consignée | Vue review (capacité review:read) ; collaboration-service (4128) — /api/v1/reviews |
🟢 Livré | La revue d'analyse produit une décision datée, pas un compte rendu. |
| D5 Allers-retours | Commentaires attachés à l'objet de spécification plutôt qu'à un fil de messagerie | collaboration-service — /api/v1/comments ; création et commentaire → rôle EDITOR |
🟢 Livré | La question et sa réponse restent accrochées à l'exigence concernée. |
| D5 Allers-retours | Artefacts BPMN et modèle de données projetés depuis la spécification | artifact-service (4129) — /api/v1/artifacts, /api/v1/diagrams ; portail : vue artifacts |
🟢 Livré | Le processus se lit sur un schéma généré, ce qui supprime une classe entière de malentendus. |
| D6 Décision perdue | Enregistrements de décision rattachés au projet | spec-service — routeur /adrs |
🟢 Livré | La décision devient un objet daté et relié à l'exigence qu'elle motive. |
| D6 Décision perdue | Journal d'audit chaîné avec vérification de chaîne | audit-compliance-service (4113) — GET /api/v1/audit-compliance/audit/events, GET …/audit/verify-chain |
🟢 Livré | « Qui a décidé quoi et quand » se répond sans reconstitution orale. |
| D7 Réunions répétées | Séparation des devoirs sur la décision de revue : la décision est réservée au rôle PUBLISHER et l'auteur ne peut pas s'approuver | collaboration-service — machine à états de revue, rejet de submitted_by == reviewer_id ; l'interface bloque le bouton avant l'appel serveur |
🟢 Livré | L'arbitrage a un lieu, un rôle et une trace — au lieu d'une réunion de plus. |
| D8 Changement non propagé | Analyse d'impact avant modification d'une exigence | spec-service — POST /api/v1/spec-items/{id}/impact ; portail : vue graph |
🟢 Livré | Avant de changer une règle, la liste de ce qu'elle entraîne est affichée. |
| D9 Statut invisible | Vue boards : tableau Kanban par statut de cycle de vie des objets de spécification |
Espace de travail — vue boards (capacité spec:read) |
🟢 Livré | Iel répond à « où en est-on ? » en ouvrant un écran, pas en relançant trois personnes. |
| D9 Statut invisible | Vue delivery : pipeline spécification → suivi, acceptation humaine, export vers vos outils de suivi |
Espace de travail — vue delivery |
🟢 Livré | L'outil de suivi de l'équipe reste en place ; il est alimenté depuis la spécification. |
| D10 Retours dispersés | Page de retours projet et tableau public avec vote et changelog | Portail : /projects/{id}/feedback ; route publique anonyme /public/feedback |
🟢 Livré | Un canal unique, priorisé par vote, avec un journal de ce qui a été livré. |
| D10 Retours dispersés | Widget de collecte de retours embarquable dans vos propres interfaces | frontend/packages/feedback-widget — bundle autonome intégrable |
🟢 Livré | Le retour est capté là où l'utilisateur se trouve, pas dans une boîte courriel partagée. |
| D11 Doublons | Relations entre objets de spécification et graphe de traçabilité | spec-service — GET /api/v1/spec-items/{id}/relationships ; vue graph |
🟢 Livré | Deux demandes équivalentes formulées différemment deviennent visiblement reliées. |
| D11 Doublons | Analyse d'écarts inter-directions appliquée à un même projet | POST /api/v1/projects/{id}/spec/analyze ; page /projects/{id}/analyze |
🟢 Livré | La contradiction se lit sur un écran avant d'être arbitrée en réunion. |
| Attente non couverte | Traitement de texte enrichi avec mise en page contractuelle et suivi de modifications à la ligne | — | ⚪ Hors périmètre assumé | KySpectra n'est pas un traitement de texte. Si votre livrable attendu est un document paginé signé, l'export existe mais ce n'est pas la promesse. |
| Attente non couverte | Outil de suivi de tickets complet — sprints, capacité, affectations individuelles | — | ⚪ Hors périmètre assumé | Il ne remplace pas votre outil de suivi, il l'alimente par export depuis la vue delivery. |
| Attente non couverte | Application mobile | — | ⚪ Planifié — aucun code mobile n'existe dans le dépôt | Les portails sont responsives et utilisables via navigateur mobile. Rien de plus. |
| Attente non couverte | Place de marché de capacités | Code écrit et testé, jamais déployé | 🟡 En cours | Ne pas le présenter comme disponible. |
#4. Semaine type — avant / après
Méthode. Les heures déplacées sont marquées [Hypothèse]. Elles ne viennent d'aucune mesure client — il n'existe aucun pilote à ce jour. Elles servent à structurer une conversation de valeur, jamais à être publiées comme un résultat. La colonne « Comment le mesurer » indique la source de mesure réelle et disponible dans le produit.
#4.1 Avant KySpectra
| Jour | Activité dominante | Temps typique | Frottement |
|---|---|---|---|
| Lundi | Atelier de cadrage avec deux directions métier, puis reprise des notes | 3 h d'atelier, 1 h 30 de mise au propre | Les notes ne deviennent jamais une exigence structurée du premier coup |
| Mardi | Rédaction et reformulation d'exigences dans le document maître | 4 h | Numérotation manuelle, formulations hétérogènes, pas de contrôle de forme |
| Mercredi | Réunions d'alignement, arbitrages, mise à jour du document | 2 h 30 de réunion, 1 h de mise à jour | Les mêmes points reviennent faute de trace commune faisant autorité |
| Jeudi | Réponses aux questions des deux équipes de développement | 2 h fragmentées | Questions posées dans deux canaux différents, réponses non conservées |
| Vendredi | Préparation de recette et consolidation des retours utilisateurs | 3 h | Aucun lien exigence ↔ test ; retours éparpillés sur quatre canaux |
#4.2 Après KySpectra
| Jour | Ce qui change | Heures déplacées [Hypothèse] |
Comment le mesurer |
|---|---|---|---|
| Lundi | L'atelier se termine dans /projects/{id}/specify : l'intention dictée devient des objets proposés, relus puis écrits |
−45 min de mise au propre | Nombre de propositions relues via GET /api/v1/copilot/save-objects/{id} avant écriture |
| Mardi | La forme est contrôlée par la validation EARS et par le métamodèle du projet ; la numérotation disparaît au profit d'identifiants d'objets | −1 h 15 de reformulation | Taux d'objets refusés à la validation, en baisse d'une semaine à l'autre — spec-service |
| Mercredi | L'arbitrage passe par une revue avec décision consignée, réservée au rôle PUBLISHER | −1 h de réunion | Nombre de revues portant une décision — collaboration-service /api/v1/reviews |
| Jeudi | Les questions sont des commentaires attachés à l'objet ; le processus se lit sur un BPMN généré | −45 min de va-et-vient | Volume de commentaires par objet — /api/v1/comments ; artefacts consultés dans la vue artifacts |
| Vendredi | La couverture exigence ↔ test est lisible ; les retours arrivent par /projects/{id}/feedback et /public/feedback avec vote |
−1 h de consolidation | Part des exigences reliées à au moins un cas de test — spec-service traçabilité + test-quality-service |
#4.3 Bilan hebdomadaire
| Poste | Avant | Après [Hypothèse] |
Écart [Hypothèse] |
|---|---|---|---|
| Mise au propre d'atelier | 1 h 30 | 0 h 45 | −0 h 45 |
| Rédaction et reformulation | 4 h | 2 h 45 | −1 h 15 |
| Réunions d'alignement | 2 h 30 | 1 h 30 | −1 h |
| Réponses aux équipes de développement | 2 h | 1 h 15 | −0 h 45 |
| Consolidation des retours et préparation de recette | 3 h | 2 h | −1 h |
| Total déplacé | — | — | ≈ 4 h 45 par semaine et par analyste [Hypothèse] |
Honnêteté sur le chiffre. Ces 4 h 45 ne sont pas un engagement contractuel. Elles décrivent une hypothèse à valider pendant la Phase 1 — pilotes fermés, du 2026-09-07 au 2026-10-04 (brief §11).
[Gabarit : mesure réelle du temps de rédaction et d'alignement avant/après, à collecter auprès d'au moins trois pilotes de Phase 1]
#5. Valeur créée
#5.1 Valeur qualitative
| Dimension | Ce qui change pour Camille |
|---|---|
| Autorité de la parole | Iel ne dit plus « c'est dans le document » ; iel montre un objet versionné avec son historique et sa décision d'origine. |
| Fin de l'archéologie documentaire | La question « quelle version fait foi ? » disparaît, parce qu'il n'y a plus de versions parallèles de fichiers. |
| Rigueur sans lourdeur | La validation EARS et le métamodèle du projet imposent la forme sans qu'iel ait à jouer le rôle de correcteur. |
| Visibilité | La vue boards donne le statut réel du cycle de vie sans réunion préalable. |
| Alignement inter-directions | L'analyse d'écarts rend visible la contradiction entre deux directions avant l'arbitrage, pas pendant. |
| Continuité | Ce qu'iel écrit reste explicable devant la personne qui prendra sa suite. C'est la promesse du manifeste, mot pour mot. |
| Écoute structurée | Les retours utilisateurs arrivent par un canal unique, avec vote et changelog public. |
#5.2 Valeur quantitative — formules visibles
Aucun gain chiffré sans formule. Les variables [Hypothèse] sont à remplacer par les mesures du pilote.
#Formule 1 — Temps de rédaction et de reformulation récupéré
GAIN_REDACTION = A × H_redac × R × S
| Variable | Signification | Valeur de travail |
|---|---|---|
A |
Nombre d'analystes d'affaires concernés | 3 [Hypothèse] |
H_redac |
Heures hebdomadaires de rédaction et reformulation avant | 4 h [Hypothèse], §4.3 |
R |
Part récupérée grâce à EARS, au métamodèle et au copilote | 0,31 [Hypothèse], §4.3 |
S |
Semaines travaillées par an | 44 [Hypothèse] |
Application : 3 × 4 × 0,31 × 44 = 163,68 heures-personnes par an [Hypothèse].
#Formule 2 — Coût évité des réunions d'alignement
GAIN_ALIGNEMENT = N_reunions × D_reunion × P_participants × T_evitement × S
| Variable | Signification | Valeur de travail |
|---|---|---|
N_reunions |
Réunions d'alignement par semaine | 3 [Hypothèse], §2 D7 |
D_reunion |
Durée moyenne en heures | 0,75 h [Hypothèse] |
P_participants |
Personnes mobilisées par réunion | 5 [Hypothèse] |
T_evitement |
Part évitable grâce à une décision consignée faisant autorité | 0,3 [Hypothèse] |
S |
Semaines travaillées par an | 44 [Hypothèse] |
Application : 3 × 0,75 × 5 × 0,3 × 44 = 148,5 heures-personnes par an [Hypothèse].
#Formule 3 — Couverture d'exigences par les tests
TAUX_COUVERTURE = E_reliees / E_total
| Variable | Signification | Valeur de travail |
|---|---|---|
E_reliees |
Exigences reliées à au moins un cas de test | Mesuré par la traçabilité spec-service croisée avec test-quality-service |
E_total |
Exigences actives du projet | Mesuré par GET /api/v1/projects/{id}/spec-items |
Ce ratio n'est pas une estimation : il se lit dans le produit dès la première campagne de recette. C'est l'indicateur le plus honnête de cette persona, parce qu'il ne dépend d'aucune hypothèse.
#Formule 4 — Coût des écarts découverts en recette
COUT_ECART_RECETTE = N_ecarts × C_reprise × P_evitement
| Variable | Signification | Valeur de travail |
|---|---|---|
N_ecarts |
Écarts demande/livraison découverts en recette, par an | [Gabarit : nombre d'écarts de recette par an, à extraire de l'outil de recette du client] |
C_reprise |
Coût moyen de reprise d'un écart — heures d'analyse, de développement et de re-recette | [Gabarit : coût moyen de reprise, à établir avec le client] |
P_evitement |
Part évitable grâce à l'analyse d'écarts en amont | 0,25 [Hypothèse] |
Interdiction assumée. Tant que
N_ecartsetC_reprisene sont pas fournis par le client, cette formule ne produit aucun chiffre publiable. On la présente vide, on la remplit ensemble.
#Formule 5 — Coût de la plateforme, à mettre en regard
COUT_ANNUEL = U × P_mensuel × 12
| Variable | Signification | Valeur de travail |
|---|---|---|
U |
Utilisateurs à équiper — analystes, responsables métier relecteurs, référents de recette | 10 [Hypothèse] |
P_mensuel |
Prix mensuel du palier Équipe | 49,00 $ CAD [Hypothèse] — valeur réellement en base, slug = team, devise CAD |
12 |
Mois par an | 12, valeur fixe |
Application : 10 × 49 × 12 = 5 880 $ CAD par an [Hypothèse].
Précision obligatoire. La modalité « par utilisateur » est une hypothèse de travail ; la base contient un prix mensuel de plan (annuel 490,00 $ CAD), pas une tarification par siège arrêtée. À valider par le propriétaire avant toute publication (brief §10).
#6. Canevas de création de valeur
Aucun diagramme à afficher
Diagramme 1 — flowchart
#7. Canevas de proposition de valeur
#7.1 Profil client — Camille, analyste d'affaires
#Tâches à accomplir
| Type | Tâche | Intensité |
|---|---|---|
| Fonctionnelle | Recueillir un besoin métier et le traduire en exigence non ambiguë | Quotidienne |
| Fonctionnelle | Maintenir la cohérence des exigences entre trois directions métier | Hebdomadaire |
| Fonctionnelle | Fournir aux deux équipes de développement une base compréhensible sans réunion | Quotidienne |
| Fonctionnelle | Préparer et suivre la recette | Par campagne, environ mensuelle |
| Fonctionnelle | Consolider les retours utilisateurs et les prioriser | Hebdomadaire |
| Sociale | Être reconnu comme la référence sur le « pourquoi » d'une règle | Continue |
| Sociale | Ne pas être la personne qui a laissé passer la contradiction | Continue |
| Sociale | Faire tenir ensemble trois directions qui ne se parlent pas directement | Continue |
| Émotionnelle | Écrire sans le sentiment que le document sera périmé avant d'être lu | Continue |
| Émotionnelle | Arriver en recette sans appréhension de l'écart | Par campagne |
#Frustrations
| Frustration | Sévérité |
|---|---|
| Le document d'exigences que personne ne rouvre | Élevée |
| L'ambiguïté détectée trop tard, par un développeur | Élevée |
| L'écart demande/livraison découvert en recette | Élevée |
| L'impossibilité de dire quelles exigences sont testées | Élevée |
| Les réunions d'alignement qui rejouent les mêmes points | Moyenne |
| La décision métier introuvable six mois après | Élevée |
| Le changement d'exigence qui ne se propage pas | Élevée |
| Les retours utilisateurs éparpillés sur quatre canaux | Moyenne |
| Les doublons d'exigences entre directions | Moyenne |
#Attentes et gains recherchés
| Gain attendu | Nature |
|---|---|
| Une exigence qui reste juste dans le temps | Durabilité |
| Une forme d'écriture contrôlée automatiquement | Réduction d'erreur |
| Savoir en un écran quelles exigences sont couvertes par un test | Réduction de risque |
| Voir la contradiction inter-directions avant l'arbitrage | Anticipation |
| Retrouver la décision métier d'origine sans interroger personne | Autonomie |
| Répondre à « où en est-on ? » sans réunion | Gain de temps |
| Un canal unique de retours, priorisé et public | Crédibilité |
#7.2 Carte de valeur — KySpectra
#Produits et services proposés
| Élément | Surface réelle | Statut |
|---|---|---|
| Explorateur et détail de spécification | /projects/{id}/spec, /projects/{id}/spec/{itemId} |
🟢 Livré |
| Génération assistée d'exigences | /projects/{id}/specify, POST /api/v1/copilot/ask |
🟢 Livré |
| Validation EARS | Drapeau EARS_GENERATION_ENABLED à vrai |
🟢 Livré |
| Métamodèle par projet | spec-service — validation d'un modèle propre au projet |
🟢 Livré |
| Tableau Kanban par statut de cycle de vie | Vue boards |
🟢 Livré |
| Graphe de traçabilité et d'impact | Vue graph, /projects/{id}/trace |
🟢 Livré |
| Analyse d'écarts | /projects/{id}/analyze |
🟢 Livré |
| Revues, commentaires et décision | Vue review, collaboration-service |
🟢 Livré |
| Artefacts BPMN et modèle de données | Vue artifacts, artifact-service |
🟢 Livré |
| Retours projet et tableau public | /projects/{id}/feedback, /public/feedback |
🟢 Livré |
| Widget de collecte embarquable | frontend/packages/feedback-widget |
🟢 Livré |
| Export vers vos outils de suivi | Vue delivery |
🟢 Livré |
| Bilingue français et anglais | Portails, parité stricte des clés de traduction | 🟢 Livré |
| Place de marché de capacités | — | 🟡 En cours |
| Application mobile | — | ⚪ Planifié |
#Solutions aux problèmes
| Frustration visée | Mécanisme produit qui la traite |
|---|---|
| Document jamais rouvert | L'exigence est un objet interrogeable et filtrable, pas un paragraphe dans un fichier |
| Ambiguïté tardive | Validation EARS à l'écriture + métamodèle propre au projet |
| Écart en recette | POST /api/v1/projects/{id}/spec/analyze et page /projects/{id}/analyze |
| Couverture inconnue | Traçabilité bidirectionnelle exigence ↔ cas de test |
| Réunions rejouées | Décision de revue réservée au rôle PUBLISHER, consignée et opposable |
| Décision introuvable | Enregistrements de décision /adrs + journal d'audit chaîné vérifiable |
| Changement non propagé | POST /api/v1/spec-items/{id}/impact avant modification |
| Retours éparpillés | Page de retours projet, tableau public avec vote et changelog, widget embarquable |
| Doublons inter-directions | Relations entre objets + analyse d'écarts sur un même projet |
#Créateurs de gains
| Gain recherché | Créateur de gain KySpectra |
|---|---|
| Exigence durable | Versionnement, relations, baselines de spécification |
| Écriture rigoureuse sans effort de correction | EARS + métamodèle + copilote relu avant écriture |
| Recette démontrable | Traçabilité vers les cas de test et les cycles d'exécution |
| Alignement inter-directions | Analyse d'écarts affichée avant arbitrage |
| Mémoire des décisions | Enregistrements de décision + journal d'audit à chaîne de hachage |
| Visibilité immédiate | Vue boards par statut de cycle de vie |
| Cohabitation avec l'existant | Export vers l'outil de suivi déjà en place, sans le remplacer |
| Travail bilingue | Français par défaut, anglais de plein droit |
#7.3 Évaluation d'adéquation
| Tâche / frustration | Réponse produit | Niveau d'adéquation | Commentaire |
|---|---|---|---|
| Écrire une exigence non ambiguë | EARS + métamodèle + copilote | Fort | Livré ; c'est le cœur de la proposition pour cette persona |
| Maintenir la cohérence dans le temps | Objets versionnés, relations, baselines | Fort | Livré |
| Relier exigence et test | Traçabilité bidirectionnelle + test-quality-service |
Fort | Livré |
| Détecter l'écart avant la recette | Analyse d'écarts + vue review |
Fort | Livré |
| Retrouver la décision métier | Enregistrements de décision + journal d'audit | Fort | Livré |
| Voir le statut réel | Vue boards |
Moyen à fort | Livré ; reflète le statut de cycle de vie des objets, pas la capacité d'équipe |
| Piloter les affectations et la charge de l'équipe | Export vers l'outil de suivi | Faible, assumé | KySpectra alimente votre outil de suivi ; il ne le remplace pas |
| Produire un document paginé contractuel | Export de documentation | Faible, assumé | Ce n'est pas un traitement de texte |
| Travailler depuis un téléphone | — | Faible | Portails responsives seulement ; aucune application mobile |
Aucun diagramme à afficher
Diagramme 2 — flowchart
#8. Objections et réponses honnêtes
| # | Objection | Réponse |
|---|---|---|
| O1 | « J'ai déjà un outil de gestion des exigences. » | Alors la vraie question est : vos exigences sont-elles reliées à ce qui les teste, à ce qui les livre et à la décision qui les a produites ? Si oui, restez. Sinon, c'est exactement l'écart que KySpectra comble. Si votre besoin est uniquement de stocker et numéroter des exigences, ce n'est pas pour vous. |
| O2 | « Vous allez remplacer notre outil de suivi de tickets. » | Non, et ce n'est pas l'intention. KySpectra n'est pas un outil de suivi de tickets : il alimente le vôtre par export, depuis la vue delivery. Vos sprints, vos affectations et votre capacité d'équipe restent où ils sont. |
| O3 | « Mon livrable attendu est un document Word signé par la direction. » | KySpectra n'est pas un traitement de texte. Vous pouvez exporter une documentation depuis la vue docs, mais si votre contrat exige une mise en page contractuelle avec suivi de modifications à la ligne, gardez votre traitement de texte pour cette étape-là et utilisez KySpectra comme source. C'est une limite assumée. |
| O4 | « Écrire en EARS, c'est une contrainte de plus. » | C'est une contrainte, oui — et c'est le but. Elle remplace la relecture manuelle qui, aujourd'hui, dépend de votre disponibilité. Le drapeau EARS_GENERATION_ENABLED est à vrai ; le métamodèle du projet vous permet en plus d'ajouter vos propres règles. Si votre organisation refuse par principe toute forme normée, l'outil ne changera rien. |
| O5 | « Le copilote va écrire mes exigences à ma place. » | Non. POST /api/v1/copilot/ask propose des objets ; ils sont relus via GET /api/v1/copilot/save-objects/{id} avant d'être écrits. Le copilote propose, un humain décide. C'est une règle de conception, pas une option de configuration. |
| O6 | « Vos chiffres de gain, vous les sortez d'où ? » | De nulle part, et nous le disons. Aucun pilote n'a encore mesuré ces gains. Les heures de la section 4 portent l'étiquette [Hypothèse] et les formules de la section 5 sont visibles pour que vous les contestiez — la formule 4 est délibérément laissée sans chiffre. Les seuls chiffres que nous publions sont ceux de notre propre dépôt : 255 commits, environ 30 services backend déployables, plus de 3 700 tests automatisés, 3 environnements en ligne. |
| O7 | « Vous n'avez aucun client de référence. » | Exact. Aucun témoignage n'existe à ce jour. [Gabarit : témoignage à collecter auprès d'un pilote de Phase 1]. Ce que nous avons, ce sont des preuves d'exécution sur notre propre production. Nous préférons vous montrer cela qu'un logo. |
| O8 | « Mes directions métier ne vont jamais ouvrir un outil technique. » | C'est le risque d'adoption principal, et nous le prenons au sérieux. Deux réponses concrètes : le tableau public /public/feedback est une route anonyme, sans compte, avec vote et changelog ; et le widget embarquable s'intègre dans vos propres interfaces métier. Pour la revue, il faut en revanche un compte et un rôle — la décision est réservée au rôle PUBLISHER. |
| O9 | « On travaille beaucoup depuis le téléphone. » | Les portails sont responsives et utilisables via navigateur mobile. Il n'existe aucune application mobile et aucun code mobile dans le dépôt. C'est Planifié. Ne comptez pas dessus pour votre décision. |
| O10 | « Et la place de marché de capacités dont vous parlez ? » | Elle est 🟡 En cours : le code existe et est testé, elle n'a jamais été déployée ni prouvée. Nous ne la vendons pas. |
| O11 | « Combien de temps avant que ce soit utile ? » | Un premier lot d'exigences structurées est produisible dès le premier atelier, via /projects/{id}/specify. La valeur de la traçabilité arrive quand vos exigences sont reliées à des cas de test, ce qui suppose une campagne de recette. Comptez une à deux campagnes pour que le ratio de couverture devienne parlant. [Gabarit : durée médiane avant premier ratio de couverture significatif, à mesurer en Phase 1] |
| O12 | « Qui peut décider quoi ? Je ne veux pas que n'importe qui valide une exigence. » | La hiérarchie est explicite : VIEWER lit, EDITOR crée, commente et soumet, PUBLISHER décide. Et la séparation des devoirs est appliquée par la machine à états : une personne ne peut pas approuver sa propre soumission — l'interface bloque le bouton et le serveur reste autoritatif. |
| O13 | « Est-ce que je peux travailler en français ? » | Oui, et pas comme une traduction tardive : le français est la langue par défaut du produit, l'anglais est de plein droit, avec parité stricte des clés de traduction. Un écart connu subsiste toutefois : une clé de navigation du portail d'administration est absente en français comme en anglais, et l'interface affiche encore SPECTRA comme nom applicatif. Ce sont des actions de pré-lancement identifiées. |
| O14 | « Et si je veux juste essayer ? » | Le palier Découverte à 0 $ CAD [Hypothèse] existe, avec plafond d'autonomie N1, sans compétences ni outils personnalisés, et 200 appels d'outil par jour. Un essai de 14 jours sans carte est prévu dans les profils configurés, avec rappels à J-7, J-3 et J-1 et rétrogradation vers le palier gratuit à l'expiration. |
#9. Offre recommandée
#9.1 Le plan
Palier Équipe — 49,00 $ CAD par mois [Hypothèse], plafond d'autonomie N2.
Le montant 49,00 $ CAD/mois (et 490,00 $ CAD en annuel) est la valeur réellement présente dans le catalogue de plans en base,
slug = team, devise CAD. La modalité « par utilisateur » est une hypothèse de travail à arrêter par le propriétaire avant toute publication (brief §10).
#9.2 Pourquoi ce palier pour cette persona
| Raison | Détail |
|---|---|
| Plafond d'autonomie N2 | Suffisant pour laisser le copilote proposer des objets de spécification sous supervision humaine, sans ouvrir le niveau N3 réservé aux organisations réglementées |
| Compétences et outils personnalisés | 25 compétences, 10 outils, 10 rôles — le palier Découverte n'en autorise aucun, ce qui interdit d'adapter la génération au vocabulaire de vos directions |
| Volume d'appels d'outil | 5 000 appels d'outil par jour, contre 200 au palier Découverte : c'est la différence entre évaluer et cadrer réellement trois directions |
| Taille d'équipe | Cible de 3 à 25 personnes, ce qui correspond au cercle de Camille : analystes, référents métier relecteurs, responsables de recette |
#9.3 Ce qui est inclus
| Inclus | Détail |
|---|---|
| Spécification exécutable | Objets versionnés, typés, reliés ; relations ; traçabilité bidirectionnelle ; analyse d'impact ; enregistrements de décision ; baselines |
| Validation de forme | Validation EARS et métamodèle par projet — validation d'un modèle propre au projet |
| Génération assistée | Copilote langage naturel → objets proposés, relus avant écriture, page /projects/{id}/specify |
| Analyse d'écarts | POST /api/v1/projects/{id}/spec/analyze et page /projects/{id}/analyze |
| Visualisation | Vue boards (Kanban par statut de cycle de vie) et vue graph |
| Artefacts | BPMN et modèle de données projetés depuis la spécification, plus UML, C4/TOGAF, DDD et artefacts de sécurité |
| Collaboration | Commentaires et revues, décision réservée au rôle PUBLISHER, séparation des devoirs appliquée |
| Retours utilisateurs | Page /projects/{id}/feedback, tableau public /public/feedback avec vote et changelog, widget de collecte embarquable |
| Continuité avec l'existant | Export vers vos outils de suivi depuis la vue delivery |
| Traçabilité | Journal d'audit à chaîne de hachage et vérification de chaîne |
| Bilingue | Français par défaut, anglais de plein droit, parité stricte des clés |
#9.4 Ce qui n'est pas inclus
| Exclu | Statut réel |
|---|---|
| Outil de suivi de tickets complet | ⚪ Hors périmètre assumé — KySpectra alimente le vôtre par export, il ne le remplace pas |
| Traitement de texte avec mise en page contractuelle | ⚪ Hors périmètre assumé — export de documentation seulement |
| Application mobile | ⚪ Planifié — aucun code mobile dans le dépôt |
| Place de marché de capacités | 🟡 En cours — non déployée, non prouvée |
| Recherche en ligne pour les agents | Réservée au palier Entreprise |
| Plafond d'autonomie N3 | Réservé au palier Entreprise |
| Volumes Entreprise | 1 000 compétences, 500 outils, 200 rôles, 1 000 000 d'appels d'outil par jour |
| Client de référence à citer | Aucun à ce jour — [Gabarit : témoignage à collecter auprès d'un pilote de Phase 1] |
#9.5 Chemin de montée en gamme
Aucun diagramme à afficher
Diagramme 3 — flowchart
| Étape | Déclencheur observable | Ce qui débloque |
|---|---|---|
| Découverte → Équipe | Le plafond de 200 appels d'outil par jour est atteint pendant un cadrage ; besoin d'un métamodèle et d'un vocabulaire propres au projet | 25 compétences, 10 outils, 10 rôles, 5 000 appels d'outil par jour, plafond N2 |
| Équipe → Entreprise | Rapports de conformité Loi 25 exigés sur période ; besoin du plafond N3 ; plus de trois directions métier et plusieurs locataires à isoler | 1 000 compétences, 500 outils, 200 rôles, 1 000 000 d'appels d'outil par jour, recherche en ligne activée, plafond N3 |
Essai : 14 jours sans carte, rappels à J-7, J-3 et J-1, rétrogradation vers le palier gratuit à l'expiration — conformément aux profils d'inscription configurés.
#10. Indicateurs de succès pour cette persona
#10.1 À 30 jours
| Indicateur | Cible [Hypothèse] |
Source de mesure réelle |
|---|---|---|
| Objets de spécification créés depuis un atelier réel | ≥ 40 | GET /api/v1/projects/{id}/spec-items |
| Propositions du copilote relues avant écriture | 100 % | GET /api/v1/copilot/save-objects/{id} — page /projects/{id}/specify |
| Exigences conformes à la validation EARS au premier passage | ≥ 70 % | spec-service, drapeau EARS_GENERATION_ENABLED à vrai |
| Métamodèle du projet défini et appliqué | 1 métamodèle actif | spec-service — validation de modèle propre au projet |
Directions métier ayant consulté la vue boards |
3 sur 3 | Journal d'audit — GET /api/v1/audit-compliance/audit/events |
#10.2 À 60 jours
| Indicateur | Cible [Hypothèse] |
Source de mesure réelle |
|---|---|---|
| Exigences reliées à au moins un cas de test | ≥ 60 % | Traçabilité spec-service croisée avec test-quality-service — formule 3 du §5.2 |
| Analyses d'écarts lancées avant une campagne de recette | ≥ 2 par campagne | POST /api/v1/projects/{id}/spec/analyze |
| Revues portant une décision consignée par un rôle PUBLISHER | ≥ 80 % des lots soumis | collaboration-service — /api/v1/reviews |
| Analyses d'impact lancées avant modification d'une exigence | ≥ 10 par mois | POST /api/v1/spec-items/{id}/impact |
| Retours utilisateurs entrés par le canal unique | ≥ 75 % du volume total | /projects/{id}/feedback et /public/feedback |
| Enregistrements de décision créés | ≥ 8 | spec-service — routeur /adrs |
#10.3 À 90 jours
| Indicateur | Cible [Hypothèse] |
Source de mesure réelle |
|---|---|---|
| Écarts demande/livraison découverts en recette | −30 % par rapport au point de départ | [Gabarit : mesure de référence à établir en semaine 1 du pilote, depuis l'outil de recette du client] |
| Réunions d'alignement hebdomadaires | −1 réunion par semaine | [Gabarit : comptage d'agenda avant/après, à collecter auprès des trois directions métier] |
| Doublons d'exigences détectés puis fusionnés | ≥ 10 | Relations GET /api/v1/spec-items/{id}/relationships + analyse d'écarts |
| Baseline de spécification produite avant chaque jalon | 100 % des jalons | GET /api/v1/projects/{id}/baselines |
| Exigences exportées vers l'outil de suivi de l'équipe | ≥ 90 % du périmètre engagé | Vue delivery — export vers outils de suivi |
| Vérification de la chaîne du journal d'audit | 1 vérification réussie | GET /api/v1/audit-compliance/audit/verify-chain |
#11. Accroches pour cette persona
Six accroches rédigées, avec canal recommandé. Ton : praticien à praticien, vouvoiement, aucun superlatif.
| # | Accroche | Canal recommandé | Intention |
|---|---|---|---|
| A1 | « Votre document d'exigences est périmé. Le nôtre n'est pas un document. » Une exigence versionnée, typée, reliée — interrogeable six mois plus tard, avec la décision qui l'a produite. |
Article de fond sur une publication professionnelle d'analyse d'affaires | Frapper la douleur dominante D1 sans promettre de gain chiffré |
| A2 | « Quelles de vos exigences sont réellement testées ? » Le ratio se lit dans le produit, pas dans une estimation : traçabilité de l'exigence vers le cas de test, dans les deux sens. |
Démonstration courte en vidéo, 90 secondes, sur réseau professionnel | Adresser D3 avec un indicateur non hypothétique |
| A3 | « L'écart, vous le voyez à l'analyse ou en recette ? » L'analyse d'écarts est un écran, pas une découverte de dernière minute. |
Atelier en ligne pour communautés d'analystes d'affaires | Adresser D4, la douleur la plus coûteuse |
| A4 | « Le copilote propose. Vous décidez. » Le langage naturel devient des objets de spécification proposés, relus avant écriture. Aucune exigence n'entre dans votre projet sans votre décision. |
Courriel de séquence d'activation, message 2 sur 5 | Désamorcer la crainte de l'IA qui écrit à votre place |
| A5 | « Nous ne remplaçons pas votre outil de suivi. Nous l'alimentons. » Vos sprints restent où ils sont. Ce qui change, c'est que ce qu'ils contiennent vient d'une exigence tracée. |
Page produit, section « Ce que nous ne faisons pas » | Construire la confiance par la limite assumée — différenciateur D5 du brief |
| A6 | « De l'intention au logiciel en production, gouverné. » Une exigence écrite en atelier, validée en EARS, reliée à son test, projetée en BPMN, décidée par un rôle habilité, journalisée. |
Bandeau de site, signature de courriel, affiche de salon | Slogan principal du brief, décliné pour un public d'analyse d'affaires |
#12. Ce que nous refusons de dire à cette persona
| Formulation interdite | Pourquoi |
|---|---|
| « Fini les documents d'exigences » | Faux : un export de documentation existe et reste utile ; la promesse porte sur la structure, pas sur la disparition du document |
| « Remplacez votre outil de suivi de tickets » | KySpectra l'alimente par export, il ne le remplace pas (§9.4) |
| « Notre traitement de texte collaboratif » | Ce n'est pas un traitement de texte — limite assumée (§8, O3) |
| « L'IA rédige vos exigences » | Le copilote propose, un humain décide et relit avant écriture |
| « Conformité automatique » | Non revendiqué (brief §7) |
| « Multipliez votre productivité » | Aucun gain de productivité chiffré n'est revendiqué (brief §7) |
| « Le meilleur outil de gestion des exigences » | Superlatif creux (brief §12) |
| « Nos clients constatent… » | Aucun témoignage n'existe (brief §15) |
| « Notre application mobile » | Aucun code mobile n'existe dans le dépôt |
| « Notre place de marché de capacités » | 🟡 En cours — jamais déployée ni prouvée |
| « Portail business » | Il n'existe pas de troisième portail ; « business » est une persona du portail client |
KySpectra — Plateforme agentique SDD/SDLC · par Kyrieva
Documentation : kyspectradoc.kyrieva.com ·
Dossier de lancement : Strategielancement/
Document interne de pré-lancement — version 1.0 du 2026-08-17. Les données marquées
« [Gabarit : … ] » doivent être renseignées ou revalidées avant diffusion externe.