#0. Résumé en dix lignes
| Élément | Contenu |
|---|---|
| Persona | Product Owner / Product Manager — persona n° 2 du brief commun (§9) |
| Douleur dominante | Écart entre ce qui a été demandé et ce qui est livré |
| Ce que KySpectra apporte | Une exigence qui est un objet versionné et relié, une analyse d'écart calculée, un lien vérifiable entre retour client, exigence, test et version livrée |
| Surfaces concernées | Portail client — /projects/{id}/specify, /analyze, /trace, /feedback ; vues spec, boards, review, delivery, docs |
| Services réels sollicités | spec-service (4107), copilot-service (4118), feedback-service (4130), sdlc-service (4108), integration-sync-service (4122), ingestion-service (4125), collaboration-service (4128) |
| Offre recommandée | Palier Équipe [Hypothèse] — plafond d'autonomie N2 |
| Ce qu'on ne promet pas | Un remplacement de l'outil de tickets ; une priorisation automatique ; une application mobile |
| Statut de la chaîne | Maillons 1 à 6 Livrés ; place de marché de capacités En cours ; pilotes nuage natifs Planifiés |
| Preuve la plus parlante | Le tableau public de retours, la feuille de route et le journal des changements sont servis en ligne, alimentés par le même moteur que la spécification |
| Risque d'adoption | La personne attend un outil de gestion de portefeuille ; KySpectra ne remplace pas le suivi de tickets, il rend la spécification opposable |
#1. Portrait
Naomi, 38 ans, responsable de produit. Iel pilote deux équipes de développement — dix-sept personnes au total — dans une entreprise de logiciel d'affaires de 60 salariés qui vend à des organisations réglementées. Iel est arrivé il y a trois ans, après huit ans dans le conseil, où iel a appris deux choses : les gens n'oublient jamais une promesse, et personne ne relit un document de plus de douze pages.
Iel n'est pas ingénieur. Iel lit du code sans le juger. Iel sait ce qu'est une API, une migration, un feature flag. Iel ne sait pas — et ne veut pas savoir — comment fonctionne un pipeline de construction. Ce qui l'intéresse, c'est la distance entre ce qui a été promis et ce qui arrive.
#1.1 Sa semaine réelle
Iel a onze réunions récurrentes. Iel écrit entre 15 et 25 tickets par sprint. Iel arbitre quatre à six demandes de changement de périmètre par mois. Iel prépare une démonstration client tous les quinze jours. Et iel passe environ un quart de son temps à répondre à une seule question, posée sous des formes différentes : « On avait bien dit que ça ferait ça, non ? »
#1.2 Sa boîte à outils actuelle
| Catégorie | Ce qu'iel utilise aujourd'hui |
|---|---|
| Suivi de travail | Outil de tickets d'entreprise, épopées, sprints, tableau de bord de vélocité |
| Spécification | Documents dans une suite bureautique, parfois un wiki, souvent une capture d'écran annotée |
| Feuille de route | Une présentation trimestrielle, refaite à chaque comité |
| Retours clients | Une adresse de courriel générique, un canal de messagerie, des notes d'entretien |
| Conception | Outil de maquettage, commentaires en fil |
| Analytique produit | Un outil de mesure d'usage, consulté surtout avant les comités |
| Communication | Messagerie d'équipe, où se prennent la moitié des arbitrages de périmètre — et où ils disparaissent |
#1.3 Ce qui le fait juger
- La prévisibilité : est-ce que ce qui était annoncé pour le trimestre est arrivé ?
- La qualité de la démonstration : est-ce que le client reconnaît ce qu'iel a demandé ?
- Le taux de retouche après livraison — les fameuses « précisions » qui sont en réalité des oublis de spécification.
- La capacité à dire non avec une justification tenable.
#1.4 Ce qui l'empêche de dormir
- La démonstration de vendredi. Iel découvrira en même temps que le client si l'interprétation était la bonne.
- La question du comité. « Pourquoi cette fonctionnalité a-t-elle coûté trois sprints ? » Iel n'a que sa mémoire pour répondre.
- Le retour client de mars dont iel se souvient vaguement et qui aurait dû changer une décision de juin.
- L'audit de conformité qui demandera de prouver que telle exigence réglementaire a été implémentée et testée.
- Le code produit par des agents IA dont iel ne sait pas s'il correspond à ce qui a été demandé.
Sa phrase à lui, telle qu'iel la dirait : « Je ne cherche pas à écrire plus de spécifications. Je cherche à ce que celles que j'écris survivent jusqu'à la livraison. »
#2. Douleurs — mécanisme de coût et fréquence
| # | Douleur | Mécanisme de coût | Fréquence |
|---|---|---|---|
| D1 | Écart demande / livraison découvert à la démonstration. L'interprétation du développeur ne correspond pas à l'intention. | Temps perdu : un à deux sprints de retouche. Risque : perte de crédibilité devant le client. | 1 à 2 fois par mois |
| D2 | Exigences dispersées. Une partie en document, une partie en ticket, une partie dans un fil de messagerie. | Temps perdu : reconstitution avant chaque arbitrage. Décision retardée : on n'ose pas trancher faute de vue complète. | Hebdomadaire |
| D3 | Impossible de dire ce qui est réellement couvert par des tests. Le taux de couverture est un pourcentage de lignes, pas d'exigences. | Risque encouru : livrer une exigence réglementaire non testée. Décision retardée : la mise en production est repoussée « par prudence ». | À chaque préparation de version |
| D4 | Retours clients qui se perdent. Ils arrivent par cinq canaux, aucun n'est relié à une exigence. | Temps perdu : re-collecte à chaque cycle de découverte. Valeur perdue : un retour utile meurt dans une boîte de réception. | Continue |
| D5 | Priorisation sans donnée d'impact. Iel ne sait pas ce qu'un changement va toucher. | Décision retardée : arbitrage reporté au sprint suivant. Risque : sous-estimation systématique du coût. | 4 à 6 fois par mois |
| D6 | Feuille de route publique impossible à tenir. Refaite manuellement, périmée trois jours après. | Temps perdu : une demi-journée par trimestre, plus les corrections. Risque : promesse publique non tenue. | Trimestrielle, plus corrections continues |
| D7 | Double saisie entre spécification et outil de tickets. Ce qui est écrit une fois est recopié deux fois. | Temps perdu : 2 à 4 heures par sprint. Risque : divergence entre les deux sources. | À chaque sprint |
| D8 | Traçabilité indémontrable devant un comité ou un auditeur. « Qui a validé ce changement de périmètre ? » | Décision retardée : préparation d'audit en urgence. Risque : constat d'écart. | 2 à 4 fois par an, avec pic avant certification |
| D9 | Critères d'acceptation ambigus. « Le formulaire doit être rapide. » | Temps perdu : allers-retours en revue. Risque : conflit en fin de sprint. | À chaque sprint |
| D10 | Changement de périmètre non tracé. Une décision prise oralement modifie une exigence sans laisser de trace. | Risque encouru : contestation ultérieure. Temps perdu : reconstitution de l'historique. | 2 à 3 fois par mois |
| D11 | Le document d'exigences produit est écrit une fois, jamais relu. Il vieillit sans que personne ne le sache. | Valeur perdue : l'effort de rédaction est consommé en pure perte. | À chaque nouveau chantier |
| D12 | Aucune visibilité sur ce que les agents IA ont produit. Le code arrive, l'intention n'est pas vérifiable. | Risque encouru : livrer une interprétation machine non validée. Décision retardée : refus d'étendre l'usage des agents. | Continue depuis dix-huit mois |
#3. Réponse produit — uniquement des fonctionnalités réelles
| Douleur | Fonctionnalité KySpectra qui y répond | Où c'est dans le produit | Statut | Ce que ça change concrètement |
|---|---|---|---|---|
| D1 Écart demande/livraison | Analyse des écarts entre l'intention et la spécification en place | spec-service (4107) — POST /api/v1/projects/{id}/spec/analyze ; portail : /projects/{id}/analyze, libellé « Analyse des écarts » |
🟢 Livré | L'écart devient un objet affiché avant la démonstration, pas une surprise pendant. |
| D1 Écart demande/livraison | Vue Revue : écarts, matrice de traçabilité, décision consignée | Vue review de l'espace de travail (capacité review:read) ; collaboration-service (4128) — /api/v1/reviews |
🟢 Livré | La revue devient le point de contrôle documenté que la démonstration ne peut plus être. |
| D2 Exigences dispersées | Spécification exécutable : objets versionnés, typés, reliés, avec explorateur et filtres | spec-service — GET /api/v1/projects/{id}/spec-items ; portail : /projects/{id}/spec, vue spec |
🟢 Livré | Une seule source, consultable, filtrable, versionnée. |
| D2 Exigences dispersées | Ingestion de documents vers spécification : Markdown, PDF, DOCX, image → classification → extraction → proposition → décision humaine | ingestion-service (4125) — /api/v1/ingestion ; portail : /imports |
🟢 Livré | Le document de 40 pages devient des objets de spécification, avec une barrière de renseignements personnels conforme Loi 25 en amont. |
| D3 Couverture non démontrable | Couverture des critères d'acceptation reliée aux objets de spécification | Vue test de l'espace de travail (capacité test:read) ; test-quality-service (4109) — /test-plans, /test-cases, /test-cycles, /runs |
🟢 Livré | Iel répond « cette exigence est couverte par ces cas de test », pas « on est à 78 % de couverture ». |
| D3 Couverture non démontrable | Portes de qualité et brèches de niveau de service | observability-board-service (4114) — GET /api/v1/observability/gates/breaches ; plan de contrôle : page /overview |
🟢 Livré | La décision de livrer s'appuie sur une porte, pas sur un ressenti. |
| D4 Retours perdus | Chaîne Retours → feuille de route → journal des changements : capture, votes, tableau public, sondages, bouclage à la version | feedback-service (4130) — /api/v1/feedback/public/board, feuille de route et journal des changements ; portail : /projects/{id}/feedback et page publique /public/feedback |
🟢 Livré | Le retour client devient un objet voté, relié, et visible publiquement. |
| D4 Retours perdus | Widget de collecte embarquable dans le produit du client | frontend/packages/feedback-widget — bundle autonome intégrable |
🟢 Livré | La collecte se fait là où l'utilisateur est, pas dans une boîte de réception. |
| D5 Priorisation sans impact | Analyse d'impact et graphe de traçabilité | spec-service — POST /api/v1/spec-items/{id}/impact, GET /api/v1/spec-items/{id}/traceability ; portail : vue graph et /projects/{id}/trace |
🟢 Livré | L'arbitrage s'appuie sur ce que le changement touche réellement. |
| D5 Priorisation sans impact | Graphe de dépendances de projet | dependency-graph-service (4117) — /api/v1/dependency-graph/... |
🟢 Livré | Les couplages entre chantiers deviennent visibles avant l'engagement. |
| D6 Feuille de route intenable | Feuille de route et journal des changements publics, alimentés par le même moteur que la spécification | feedback-service — surfaces publiques ; portail : /public/feedback (route exemptée d'authentification) |
🟢 Livré | La page publique n'est plus une présentation refaite à la main. |
| D7 Double saisie | Export vers Jira et Azure DevOps depuis la chaîne de livraison | integration-sync-service (4122) — /api/v1/integration-sync/... ; portail : vue delivery, description « pipeline BMAD → spec → tracker, PRD, acceptation avec humain dans la boucle, export Jira/Azure DevOps » |
🟢 Livré | L'exigence est écrite une fois, poussée vers l'outil de tickets. |
| D7 Double saisie | Remplacement de votre outil de tickets | — | ⚪ Planifié / hors périmètre assumé | KySpectra n'est pas un outil de gestion de projet. La spécification est la source de vérité, pas le ticket. |
| D8 Traçabilité indémontrable | Journal d'audit à chaîne de hachage + endpoint de vérification + rapport de conformité Loi 25 sur période | audit-compliance-service (4113) — GET /api/v1/audit-compliance/audit/events, GET …/audit/verify-chain, POST …/compliance/reports ; plan de contrôle : page /audit |
🟢 Livré | La réponse au comité est un rapport généré, pas une reconstitution. |
| D8 Traçabilité indémontrable | Baselines de spécification et enregistrements de décision | spec-service — GET /api/v1/projects/{id}/baselines, routeur /adrs |
🟢 Livré | On peut geler un état de référence et comparer. |
| D9 Critères ambigus | Validation EARS des exigences | spec-service — surface /api/v1/ears (drapeau EARS_GENERATION_ENABLED, à True) |
🟢 Livré | Une exigence mal formée est signalée à l'écriture, pas en revue de sprint. |
| D9 Critères ambigus | Métamodèle par projet : les types d'objets et leurs règles sont définis par le projet | collaboration-service — /api/v1/metamodel ; spec-service — POST /api/v1/projects/{id}/model/validate |
🟢 Livré | Vos types d'exigences sont les vôtres, et ils sont validés. |
| D10 Changement non tracé | Demandes de changement et cycle de vie | sdlc-service (4108) — /api/v1/sdlc/change-requests, /api/v1/sdlc/lifecycle, /api/v1/sdlc/promotions, /api/v1/sdlc/intake-requests |
🟢 Livré | Le changement de périmètre devient un objet avec un auteur et une date. |
| D10 Changement non tracé | Séparation des devoirs sur les décisions de revue | collaboration-service — rejet de submitted_by == reviewer_id, blocage du bouton côté interface |
🟢 Livré | Personne ne valide sa propre demande de changement. |
| D11 Document mort | PRD projeté depuis la spécification, consultable en arbre | spec-service — GET /api/v1/projects/{id}/prd, GET /api/v1/projects/{id}/prd/{prd_id}/tree ; portail : vue docs |
🟢 Livré | Le document produit est une projection, régénérable, pas un artefact figé. |
| D11 Document mort | Documentation-comme-code exportable | Vue docs, capacité docs:export ; artifact-service (4129) — /api/v1/documentation |
🟢 Livré | La documentation se régénère quand la spécification bouge. |
| D12 Agents opaques | Runs d'agents observables et copilote avec proposition relue avant écriture | Portail : vue agentops, page /agents ; copilot-service (4118) — POST /api/v1/copilot/ask, relecture GET /api/v1/copilot/save-objects/{id} |
🟢 Livré | Ce que l'agent propose passe par vos yeux avant d'exister. |
| D12 Agents opaques | Plafond d'autonomie N0→N3 plafonné par le plan commercial | extension-registry-service (4116) ; portail : /roles |
🟢 Livré (drapeau REGISTRY_VIRTUAL_ROLES_ENABLED, défaut False — activation d'exploitation requise) |
Vous décidez du niveau de latitude, par rôle. |
| Attente non couverte | Priorisation automatique par valeur d'affaires | — | ⚪ Planifié | Le produit fournit l'impact et les votes ; il ne classe pas votre carnet à votre place. |
| Attente non couverte | Application mobile pour consulter la feuille de route | — | ⚪ Planifié — aucun code mobile dans le dépôt | Les portails sont responsives via navigateur. |
| Attente non couverte | Place de marché de capacités avec audience ciblée | Code écrit et testé, non déployé | 🟡 En cours | Ne pas le présenter comme disponible. |
#4. Semaine type — avant / après
Méthode. Heures marquées [Hypothèse], aucune mesure client n'existe à ce jour. La colonne « Comment le mesurer » cite une source réellement disponible dans le produit.
#4.1 Avant KySpectra
| Jour | Activité dominante | Temps typique | Frottement |
|---|---|---|---|
| Lundi | Affinage du carnet, réunion de planification | 3 h | Exigences dispersées ; le contexte est reconstitué à chaque fois |
| Mardi | Rédaction de tickets et de critères d'acceptation | 3 h 30 | Double saisie entre le document et l'outil de tickets |
| Mercredi | Arbitrages de périmètre, réponses aux développeurs | 2 h 30 | Aucune donnée d'impact ; arbitrage à l'intuition |
| Jeudi | Préparation de démonstration, collecte de retours | 2 h | Découverte tardive des écarts d'interprétation |
| Vendredi | Comité, mise à jour de la feuille de route, préparation d'audit | 3 h | Feuille de route refaite à la main, traçabilité reconstituée |
#4.2 Après KySpectra
| Jour | Ce qui change | Heures déplacées [Hypothèse] |
Comment le mesurer |
|---|---|---|---|
| Lundi | Le carnet s'appuie sur l'explorateur de spécification filtré ; les retours votés remontent depuis feedback-service |
−45 min | Nombre d'objets de spécification ouverts ; nombre de retours reliés à une exigence |
| Mardi | L'exigence est écrite une fois dans /projects/{id}/specify, validée EARS, exportée vers l'outil de tickets |
−1 h 15 | Nombre d'exports integration-sync-service ; nombre d'exigences rejetées par la validation EARS |
| Mercredi | L'arbitrage s'appuie sur POST /api/v1/spec-items/{id}/impact et la vue graph |
−30 min, décisions mieux fondées | Nombre d'analyses d'impact avant arbitrage |
| Jeudi | L'écart est calculé avant la démonstration via POST /api/v1/projects/{id}/spec/analyze |
−30 min, et surtout moins de retouche après | Nombre d'analyses d'écart lancées ; nombre de retouches post-démonstration |
| Vendredi | Feuille de route et journal des changements publics servis par feedback-service ; rapport Loi 25 généré sur période |
−1 h 30 | Nombre de rapports générés ; date de dernière mise à jour de la feuille de route publique |
#4.3 Bilan hebdomadaire
| Poste | Avant | Après [Hypothèse] |
Écart [Hypothèse] |
|---|---|---|---|
| Reconstitution de contexte | 3 h | 2 h 15 | −0 h 45 |
| Rédaction et double saisie | 3 h 30 | 2 h 15 | −1 h 15 |
| Arbitrages | 2 h 30 | 2 h | −0 h 30 |
| Préparation de démonstration | 2 h | 1 h 30 | −0 h 30 |
| Feuille de route, comité, audit | 3 h | 1 h 30 | −1 h 30 |
| Total déplacé | — | — | ≈ 4 h 30 par semaine [Hypothèse] |
Le gain le plus important n'est pas dans ce tableau. C'est la retouche évitée : un à deux sprints par mois selon la douleur D1. Ce gain-là n'est pas une hypothèse de temps, c'est un risque déplacé.
[Gabarit : nombre de sprints de retouche par trimestre, à mesurer avant et après chez un pilote de Phase 1]
#5. Valeur créée
#5.1 Valeur qualitative
| Dimension | Ce qui change pour Naomi |
|---|---|
| Crédibilité | Devant un comité, la réponse est un rapport généré sur période, pas un souvenir |
| Prévisibilité | L'écart est calculé avant la démonstration, pas découvert pendant |
| Écoute client | Le retour capté dans le produit devient un objet voté, relié à une exigence, visible sur un tableau public |
| Arbitrage | La priorisation s'appuie sur l'impact réel du changement |
| Effort de rédaction | Ce qui est écrit une fois vit : le document produit est une projection régénérable, pas un fichier oublié |
| Rapport aux agents | Ce qu'un agent propose passe par une relecture avant d'exister comme objet de spécification |
#5.2 Valeur quantitative — formules visibles
#Formule 1 — Retouche évitée
GAIN_RETOUCHE = R_avant × T_sprint × E × C_sprint
| Variable | Signification | Valeur de travail |
|---|---|---|
R_avant |
Sprints de retouche par trimestre avant | [Gabarit : à extraire du suivi de sprints du client] |
T_sprint |
Personnes mobilisées par sprint de retouche | 4 [Hypothèse] |
E |
Part de retouche évitable par l'analyse d'écart préalable | 0,4 [Hypothèse] |
C_sprint |
Coût interne d'un sprint-personne | [Gabarit : coût interne, à établir avec le client] |
Tant que
R_avantetC_sprintne sont pas fournis, cette formule ne produit aucun chiffre publiable.
#Formule 2 — Temps de rédaction et de double saisie récupéré
GAIN_REDACTION = (H_redaction_avant − H_redaction_apres) × S × N_PO
| Variable | Signification | Valeur de travail |
|---|---|---|
H_redaction_avant |
Heures hebdomadaires de rédaction et recopie | 3,5 h [Hypothèse], §4.3 |
H_redaction_apres |
Heures après export automatisé vers l'outil de tickets | 2,25 h [Hypothèse] |
S |
Semaines travaillées par an | 44 [Hypothèse] |
N_PO |
Responsables de produit concernés | 2 [Hypothèse] |
Application : (3,5 − 2,25) × 44 × 2 = 110 heures-personnes par an [Hypothèse].
#Formule 3 — Préparation d'audit et de comité
GAIN_AUDIT = N_evenements × (H_avant − H_apres)
| Variable | Signification | Valeur de travail |
|---|---|---|
N_evenements |
Comités et audits par an nécessitant une preuve de traçabilité | 6 [Hypothèse] |
H_avant |
Heures de reconstitution manuelle | 8 h [Hypothèse] |
H_apres |
Heures avec rapport Loi 25 généré et journal vérifiable | 1,5 h [Hypothèse] |
Application : 6 × (8 − 1,5) = 39 heures-personnes par an [Hypothèse].
#Formule 4 — Valeur du retour client récupéré
VALEUR_RETOURS = N_retours_perdus × P_actionnables × V_moyenne
| Variable | Signification | Valeur de travail |
|---|---|---|
N_retours_perdus |
Retours reçus hors canal structuré par an | [Gabarit : volume réel à mesurer sur un trimestre] |
P_actionnables |
Part qui aurait modifié une décision de produit | 0,08 [Hypothèse] |
V_moyenne |
Valeur moyenne d'une décision de produit corrigée | [Gabarit : à établir avec la direction produit] |
#Formule 5 — Coût de la plateforme, à mettre en regard
COUT_ANNUEL = U × P_mensuel × 12
Avec P_mensuel = 49 $ CAD [Hypothèse] — valeur réellement présente en base pour le plan team (4 900 cents, devise CAD ; annuel 49 000 cents). Pour une équipe produit et développement de 17 personnes : 17 × 49 × 12 = 9 996 $ CAD par an [Hypothèse].
La modalité « par utilisateur » est une hypothèse de travail, pas une décision commerciale arrêtée (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 — Naomi, responsable de produit
#Tâches à accomplir
| Type | Tâche | Intensité |
|---|---|---|
| Fonctionnelle | Traduire un besoin flou en exigence exploitable par une équipe | Quotidienne |
| Fonctionnelle | Arbitrer un périmètre sous contrainte de délai | Hebdomadaire |
| Fonctionnelle | Vérifier que ce qui arrive correspond à ce qui a été demandé | À chaque livraison |
| Fonctionnelle | Tenir une feuille de route publique crédible | Trimestrielle |
| Fonctionnelle | Prouver à un auditeur qu'une exigence réglementaire est implémentée et testée | 2 à 4 fois par an |
| Sociale | Être la personne dont les engagements tiennent | Continue |
| Sociale | Défendre une décision de non-priorisation devant un client | Mensuelle |
| Émotionnelle | Ne pas découvrir un écart devant le client | Continue |
| Émotionnelle | Ne pas avoir écrit des documents que personne ne lit | Continue |
#Frustrations
| Frustration | Sévérité |
|---|---|
| Écart d'interprétation découvert en démonstration | Élevée |
| Exigences éparpillées sans source unique | Élevée |
| Couverture de test indémontrable par exigence | Élevée |
| Retours clients qui disparaissent | Moyenne |
| Arbitrage à l'intuition | Élevée |
| Feuille de route publique périmée | Moyenne |
| Recopie entre spécification et tickets | Moyenne |
| Traçabilité reconstituée en urgence avant audit | Élevée |
#Attentes et gains recherchés
| Gain attendu | Nature |
|---|---|
| Voir l'écart avant le client | Réduction de risque |
| Une seule source d'exigences, versionnée | Gain de temps et de fiabilité |
| Dire quelles exigences sont couvertes par des tests | Défendabilité |
| Un retour client qui survit jusqu'à la décision | Qualité produit |
| Un arbitrage adossé à des faits | Crédibilité |
| Une preuve de conformité générée, pas reconstituée | Sérénité d'audit |
#7.2 Carte de valeur — KySpectra
#Produits et services proposés
| Élément | Surface réelle | Statut |
|---|---|---|
| Spécifier avec assistance IA | /projects/{id}/specify — copilot-service |
🟢 Livré |
| Analyse des écarts | /projects/{id}/analyze |
🟢 Livré |
| Traçabilité et graphe | /projects/{id}/trace, vue graph |
🟢 Livré |
| Tableau Kanban par statut du cycle de vie | Vue boards |
🟢 Livré |
| Chaîne de livraison et export vers outil de tickets | Vue delivery |
🟢 Livré |
| Retours et feuille de route | /projects/{id}/feedback, /public/feedback |
🟢 Livré |
| Widget de collecte embarquable | frontend/packages/feedback-widget |
🟢 Livré |
| Documentation et PRD projetés | Vue docs |
🟢 Livré |
| Journal d'audit et rapports Loi 25 | Plan de contrôle — /audit |
🟢 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 |
|---|---|
| Écart en démonstration | Analyse d'écart calculée avant, vue review avec matrice de traçabilité |
| Exigences éparpillées | Objets de spécification versionnés + ingestion de documents vers spécification |
| Couverture indémontrable | Couverture par critère d'acceptation, portes de qualité, brèches de niveau de service |
| Retours perdus | Capture par widget, votes, tableau public, bouclage à la version |
| Arbitrage à l'intuition | Analyse d'impact, graphe de traçabilité, graphe de dépendances |
| Feuille de route périmée | Feuille de route et journal des changements servis depuis le même moteur |
| Recopie | Export Jira / Azure DevOps depuis la chaîne de livraison |
| Audit reconstitué | Journal à chaîne de hachage vérifiable + rapport Loi 25 sur période |
#Créateurs de gains
| Gain recherché | Créateur de gain KySpectra |
|---|---|
| Écrire une exigence exploitable | Validation EARS et métamodèle par projet |
| Écrire une fois | PRD et documentation projetés depuis la spécification |
| Décider avec des faits | Impact, traçabilité bidirectionnelle, votes de retours |
| Tenir une promesse publique | Tableau public, feuille de route et journal des changements en ligne |
| Encadrer les agents | Proposition du copilote relue avant écriture ; plafond d'autonomie par rôle |
| Faire confiance à l'outil | 501 Not Implemented explicite plutôt qu'un faux succès |
#7.3 Évaluation d'adéquation
| Tâche / frustration | Réponse produit | Niveau d'adéquation | Commentaire |
|---|---|---|---|
| Traduire un besoin en exigence | Copilote + validation EARS + métamodèle | Fort | Livré, au cœur du maillon « Spécifier » |
| Détecter l'écart avant livraison | Analyse d'écart + vue review |
Fort | Livré |
| Prouver la couverture par exigence | Vue test + test-quality-service |
Fort | Livré ; la vue test est réservée aux projets de type test_only |
| Capter et exploiter le retour client | feedback-service + widget |
Fort | Livré, avec surfaces publiques en ligne |
| Éviter la double saisie | Export Jira / Azure DevOps | Moyen à fort | Livré ; la synchronisation bidirectionnelle complète n'est pas revendiquée |
| Piloter un portefeuille de produits | — | Faible | KySpectra n'est pas un outil de gestion de projet |
| Prioriser automatiquement | — | Nul, assumé | Le produit fournit l'impact et les votes ; il ne classe pas à votre place |
| Consulter depuis un téléphone | — | Faible | Portails responsives, 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 tickets. Vous voulez le remplacer ? » | Non. Nous disons l'inverse : le ticket n'est pas la source de vérité, la spécification l'est. Votre outil de tickets reste votre outil d'exécution ; l'exigence est écrite une fois chez nous, puis exportée vers Jira ou Azure DevOps par integration-sync-service. Si vous cherchez à remplacer votre outil de tickets, ce n'est pas pour vous. |
| O2 | « Mes équipes ne rempliront jamais une spécification. » | C'est l'objection décisive, et elle est légitime. Deux leviers réels. Un : vous ne partez pas d'une page blanche — la rétro-ingénierie de votre dépôt produit des candidats d'exigences, et l'ingestion de vos documents existants aussi. Deux : le copilote transforme du langage naturel en objets proposés que vous relisez. Si malgré cela votre culture d'équipe rejette toute exigence écrite, l'outil ne renversera pas cette culture. |
| O3 | « Encore un endroit où écrire les choses. » | Le test est simple : est-ce que ce que vous écrivez produit quelque chose ? Ici, une exigence déclenche du travail d'agent, se relie à des cas de test, projette un document produit et un diagramme, et remonte les défauts vers elle. Si elle ne fait rien de tout cela, vous avez raison de refuser. |
| O4 | « Vos gains de temps, ils viennent d'où ? » | De nulle part, et c'est écrit. Toutes les heures de la section 4 portent l'étiquette [Hypothèse]. Aucun pilote n'a encore mesuré ces gains ; la Phase 1 de pilotes fermés commence le 2026-09-07. Les seuls chiffres que nous publions concernent notre propre produit : 255 commits, ~30 services backend, plus de 3 700 tests automatisés, 3 environnements en ligne. |
| O5 | « Montrez-moi un client qui l'utilise. » | Il n'y en a aucun. [Gabarit : témoignage à collecter auprès d'un pilote de Phase 1]. Ce que nous montrons, ce sont des preuves d'exécution sur notre propre production, pas des logos. |
| O6 | « Mes exigences sont confidentielles. » | L'isolation entre clients est stricte : un identifiant de locataire en désaccord avec le jeton renvoie 404, pas 403 — on ne révèle pas même l'existence de la ressource d'autrui. Les secrets vivent dans un coffre, jamais dans une source de projet : un secret inline est rejeté en 422. |
| O7 | « La feuille de route publique, c'est risqué. » | Elle est optionnelle. La route publique /public/feedback est explicitement exemptée d'authentification ; si vous ne l'exposez pas, elle n'existe pas pour vos utilisateurs. Vous pouvez n'utiliser que la capture interne et les votes. |
| O8 | « Et si l'IA écrit des exigences fausses ? » | Elle en propose. La proposition passe par une relecture avant écriture — GET /api/v1/copilot/save-objects/{id}. Sur le chemin de la rétro-ingénierie, la promotion d'une spécification exige une décision humaine de rôle PUBLISHER dans la file /validation-tasks. Rien ne devient une exigence sans qu'une personne l'ait décidé. |
| O9 | « Je ne veux pas apprendre un nouvel outil de plus. » | L'espace de travail projet a onze vues, dont vous en utiliserez probablement quatre : spec, boards, review, docs. Les vues sont gatées par capacité : celles que votre rôle ne permet pas ne s'affichent pas. Et l'interface est en français par défaut, pas traduite après coup. |
| O10 | « Vos rapports de conformité, ils valent quoi devant un auditeur ? » | Ils valent ce que vaut la chaîne de preuve : un journal d'audit à chaîne de hachage, vérifiable par un endpoint dédié, et un rapport de conformité Loi 25 généré sur une période donnée. Nous ne prétendons pas produire une conformité automatique — c'est explicitement hors de ce que nous revendiquons. |
| O11 | « Combien de temps avant la première valeur ? » | La première analyse d'écart peut tourner dès que vous avez des objets de spécification, ce qui arrive dès le premier lot promu depuis vos documents ou votre dépôt. Comptez une à deux semaines pour un projet de taille moyenne. [Gabarit : délai médian jusqu'à la première analyse d'écart, à mesurer en Phase 1] |
| O12 | « Le prix, c'est par utilisateur ou par organisation ? » | La valeur réellement présente en base est 49,00 $ CAD par mois pour le plan Équipe. La modalité par utilisateur est une hypothèse de travail que nous n'avons pas encore arrêtée, et nous préférons vous le dire plutôt que d'inventer une grille. |
| O13 | « Vos captures montrent le nom SPECTRA. » |
Oui. common.appName vaut encore SPECTRA dans l'interface livrée, et c'est un écart connu, inscrit au programme de pré-lancement. La marque publique est KySpectra, un seul mot. |
#9. Offre recommandée
#9.1 Le plan
Palier Équipe — 49 $ CAD par utilisateur et par mois [Hypothèse].
Le montant 49,00 $ CAD/mois (annuel 490,00 $ CAD) 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 à arrêter par le propriétaire (brief §10).
#9.2 Pourquoi ce palier
| Raison | Détail |
|---|---|
| Cible de 3 à 25 personnes | Correspond à une équipe produit et développement complète |
| Plafond d'autonomie N2 | Suffisant pour un copilote de spécification et des agents de vérification supervisés |
| Compétences et outils personnalisés | 25 compétences, 10 outils, 10 rôles — indisponibles au palier Découverte |
| Volume d'appels d'outil | 5 000 par jour contre 200 au palier Découverte |
#9.3 Ce qui est inclus
| Inclus | Détail |
|---|---|
| Spécification exécutable | Objets versionnés, relations, traçabilité, impact, baselines, enregistrements de décision |
| Copilote de spécification | Langage naturel vers objets proposés, relus avant écriture |
| Ingestion de documents | Markdown, PDF, DOCX, image ; barrière de renseignements personnels ; décision humaine avant création |
| Analyse d'écart et revue | Écarts calculés, matrice de traçabilité, séparation des devoirs |
| Vérification | Couverture par critère d'acceptation, portes de qualité, données de test synthétiques |
| Retours et feuille de route | Capture, votes, tableau public, feuille de route, journal des changements, widget embarquable |
| Livraison | Chaîne gouvernée, export Jira / Azure DevOps |
| Documentation | PRD et documentation projetés, exportables |
| Conformité | Journal d'audit chaîné, vérification de chaîne, rapport Loi 25 |
| Bilingue | Français par défaut, anglais de plein droit |
#9.4 Ce qui n'est pas inclus
| Exclu | Statut réel |
|---|---|
| Recherche en ligne pour les agents | Palier Entreprise uniquement |
| Plafond d'autonomie N3 | Palier Entreprise uniquement |
| Volumes Entreprise | 1 000 compétences, 500 outils, 200 rôles, 1 000 000 d'appels d'outil par jour |
| Gestion de portefeuille de produits | Hors périmètre assumé |
| Priorisation automatique | ⚪ Planifié |
| Application mobile | ⚪ Planifié — aucun code mobile dans le dépôt |
| Place de marché de capacités | 🟡 En cours — non déployée |
| Pilotes nuage natifs | ⚪ Planifié |
#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 | Plus de 200 appels d'outil par jour ; besoin d'une compétence ou d'un outil personnalisé ; plus de deux personnes | 25 compétences, 10 outils, 10 rôles, 5 000 appels/jour, plafond N2 |
| Équipe → Entreprise | Audit réglementaire récurrent ; recherche en ligne exigée pour les agents ; plus de 25 personnes | Volumes Entreprise, recherche en ligne, plafond N3 |
Essai : 14 jours sans carte, rappels à J-7, J-3 et J-1, rétrogradation vers le palier gratuit à l'expiration.
#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 ou promus | ≥ 40 | GET /api/v1/projects/{id}/spec-items |
| Documents existants ingérés vers spécification | ≥ 3 | ingestion-service — /api/v1/ingestion |
| Première analyse d'écart lancée | 1 | POST /api/v1/projects/{id}/spec/analyze |
| Retours capturés dans le canal structuré | ≥ 20 | feedback-service — /api/v1/feedback/... |
| Exigences rejetées par la validation EARS puis corrigées | ≥ 5 | Surface /api/v1/ears |
#10.2 À 60 jours
| Indicateur | Cible [Hypothèse] |
Source de mesure réelle |
|---|---|---|
| Part des tickets de sprint rattachés à un objet de spécification | ≥ 60 % | Export integration-sync-service |
| Analyses d'impact avant arbitrage de périmètre | ≥ 8 par mois | POST /api/v1/spec-items/{id}/impact |
| Exigences avec au moins un cas de test relié | ≥ 50 % | test-quality-service |
| Feuille de route publique mise à jour sans travail manuel | 100 % | Date de dernière publication sur /public/feedback |
| Décisions de revue consignées avec séparation des devoirs | 100 % | collaboration-service — /api/v1/reviews |
#10.3 À 90 jours
| Indicateur | Cible [Hypothèse] |
Source de mesure réelle |
|---|---|---|
| Sprints de retouche post-démonstration | −30 % par rapport au point de départ | [Gabarit : mesure de référence à établir en semaine 1 du pilote] |
| Rapport de conformité généré pour un comité | ≥ 1 | POST /api/v1/audit-compliance/compliance/reports, type loi25 |
| Part des retours clients reliés à une exigence | ≥ 70 % | feedback-service |
| Exigences couvertes par un cas de test | ≥ 75 % | test-quality-service |
| Écarts détectés avant démonstration plutôt que pendant | ≥ 80 % | Comparaison entre analyses d'écart et retouches déclarées |
#11. Accroches pour cette persona
| # | Accroche | Canal recommandé | Intention |
|---|---|---|---|
| A1 | « L'écart, vous le voyez avant le client. » Une analyse d'écart entre l'intention exprimée et la spécification en place, lancée quand vous voulez, pas découverte en démonstration. |
Publication de fond sur un média produit, ou infolettre spécialisée | Toucher D1 sans promettre de gain chiffré |
| A2 | « Une exigence n'est pas un paragraphe. C'est un objet versionné qui déclenche du travail. » Et contre lequel on vérifie le résultat. |
Réseau professionnel, publication courte reprenant le manifeste | Poser le différenciateur D1 du brief |
| A3 | « Le retour de mars ne doit pas mourir dans une boîte de réception. » Capture dans le produit, votes, tableau public, feuille de route et journal des changements — reliés à vos exigences. |
Démonstration vidéo de 90 secondes | Adresser D4 avec une surface visible et publique |
| A4 | « Quelles exigences sont couvertes par des tests ? » Pas un pourcentage de lignes. La liste, par exigence. |
Webinaire conjoint responsable de produit et responsable qualité | Adresser D3 avec un bénéfice partagé |
| A5 | « Écrivez une fois. Poussez vers Jira ou Azure DevOps. » L'exigence reste la source ; le ticket reste l'exécution. |
Courriel de séquence d'activation, message 3 sur 5 | Adresser D7 et désamorcer O1 |
| A6 | « De l'intention au logiciel en production, gouverné. » Chaque artefact reste relié à l'exigence qui l'a motivé — devant votre comité comme devant un auditeur. |
Bandeau de site, présentation d'entreprise, salon | Slogan principal du brief, décliné pour un public produit |
#12. Ce que nous refusons de dire à cette persona
| Formulation interdite | Pourquoi |
|---|---|
| « Vos livraisons seront conformes à 100 % » | Promesse de résultat non mesurée |
| « Remplacez Jira » | Faux ; nous exportons vers Jira |
| « Conformité automatique » | Non revendiqué (brief §7) |
| « Nos clients constatent… » | Aucun témoignage n'existe |
| « La meilleure plateforme de spécification » | Superlatif creux |
| « Feuille de route pilotée par l'IA » | Le produit fournit l'impact et les votes, il ne priorise pas à votre place |
| « Application mobile disponible » | Aucun code mobile n'existe |
| « Portail business » | Il n'existe pas de troisième portail |
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.