#0. Résumé en dix lignes
| Élément | Contenu |
|---|---|
| Persona | Développeur / ingénieur logiciel — persona n° 1 du brief commun (§9) |
| Douleur dominante | Reprendre du code généré dont l'intention est perdue |
| Ce que KySpectra apporte | Une exigence versionnée derrière chaque artefact, un graphe d'impact avant de toucher au code, des agents IA avec périmètre et journal |
| Surfaces concernées | Portail client — espace de travail projet, 11 vues canoniques ; vues spec, graph, agentops, artifacts, test, review, delivery |
| Services réels sollicités | spec-service (4107), reverse-engineering-service (4120), copilot-service (4118), agent-runtime-service (4119), deploy-service (4121), artifact-service (4129), test-quality-service (4109) |
| Offre recommandée | Palier Équipe [Hypothèse] — plafond d'autonomie N2 |
| Ce qu'on ne promet pas | Une meilleure complétion de code dans l'éditeur ; un gain de productivité chiffré ; une application mobile |
| Statut de la chaîne | Maillons 1 à 6 Livrés ; pilotes nuage natifs Planifiés ; place de marché de capacités En cours |
| Preuve la plus parlante | Dépôt public importé → rétro-ingénierie → spécifications promues → produit servi sur un sous-domaine avec TLS, prouvé en production |
| Risque d'adoption | La personne veut un outil dans son éditeur ; KySpectra gouverne le cycle autour de l'éditeur |
#1. Portrait
Malik, 34 ans, ingénieur logiciel senior. Iel travaille depuis quatre ans dans la même équipe produit — douze personnes, dont trois qui sont arrivées cette année — au sein d'une entreprise de logiciel d'affaires de 150 salariés. L'entreprise a onze ans, deux produits, une base de code qui a survécu à trois réorganisations et à deux changements de directeur technique.
Iel n'a pas commencé sa carrière ici. Iel est passé par une agence, puis par une jeune pousse qui a fermé. Ce parcours lui a donné une conviction : le code n'est pas le problème, c'est ce qu'on en sait qui l'est. Iel a repris trois systèmes écrits par d'autres. À chaque fois, la même scène : un module de 4 000 lignes, aucun commentaire utile, un nom de branche qui référence un ticket fermé depuis deux ans dans un outil qui n'existe plus.
#1.1 Sa journée réelle
Iel arrive vers 9 h 15. Iel ouvre son éditeur, son gestionnaire de tickets, sa messagerie d'équipe et un tableau de bord de supervision. Iel a en moyenne 2,5 tâches en cours. Iel passe plus de temps à comprendre qu'à écrire — et depuis dix-huit mois, ce déséquilibre s'aggrave, parce que la moitié du code qui arrive en revue a été produit avec une assistance générative, par lui ou par ses collègues.
#1.2 Sa boîte à outils actuelle
| Catégorie | Ce qu'iel utilise aujourd'hui |
|---|---|
| Édition et complétion | Éditeur moderne avec assistant de complétion de code intégré |
| Dépôt et revue | Forge Git avec demandes de tirage, revues obligatoires à deux |
| Suivi de travail | Outil de tickets d'équipe, tableau Kanban, sprints de deux semaines |
| Documentation | Un wiki d'entreprise, honnêtement à moitié périmé |
| Exécution | Conteneurs en local, orchestrateur Kubernetes géré par l'équipe d'exploitation |
| Observabilité | Tableaux de bord de métriques, journaux centralisés, alertes |
| Communication | Messagerie d'équipe, où se prennent 70 % des décisions techniques — et où elles disparaissent |
#1.3 Ce qui le fait juger — par ses pairs et par sa hiérarchie
- La qualité de ses revues de code, plus que le volume de ses propres livraisons.
- Sa capacité à reprendre un incident de production sans réveiller trois personnes.
- Le fait que les nouveaux arrivants deviennent autonomes rapidement sur ce qu'iel a construit.
- Le taux de retour de ses livraisons : combien de fois faut-il y revenir après la mise en production.
#1.4 Ce qui l'empêche de dormir
- La ligne qu'iel n'ose pas supprimer. Elle est là depuis quatre ans, personne ne sait pourquoi, et le jour où on la retire, quelque chose casse ailleurs.
- Le code qu'iel a fait générer. Il a passé les tests. Il est en production. Iel serait incapable d'en expliquer chaque décision devant un incident.
- La question du prochain audit. « Qui a validé ceci ? » Personne n'a la réponse.
- Le départ de la seule personne qui comprend le module de facturation.
Sa phrase à lui, telle qu'iel la dirait en entretien : « Je ne veux pas d'un outil qui écrit plus vite. Je veux un outil qui me dit pourquoi ce truc existe et ce qui pète si j'y touche. »
#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 | Intention perdue derrière le code généré. Le code fonctionne, personne ne sait quelle exigence l'a motivé. | Temps perdu : archéologie dans l'historique Git, le gestionnaire de tickets et la messagerie avant chaque modification non triviale. Risque : on réimplémente une règle métier déjà présente ailleurs. | Plusieurs fois par semaine, à chaque tâche touchant du code de plus de six mois |
| D2 | Impact d'un changement inconnu. Aucune carte fiable ne relie une exigence, un module, un test et un artefact d'architecture. | Risque encouru : régression détectée en production, pas en revue. Décision retardée : on repousse le refactoring « au prochain trimestre », indéfiniment. | À chaque changement structurant — environ deux fois par mois |
| D3 | Le ticket ne dit pas pourquoi. Il dit quoi faire, jamais la contrainte qui l'a produit. | Temps perdu : allers-retours avec le responsable de produit, souvent asynchrones, avec un délai de réponse d'une demi-journée. Décision retardée : la tâche stagne en « en cours ». | 3 à 6 tickets par sprint |
| D4 | Onboarding d'un service inconnu. Documentation périmée, pas de schéma d'architecture à jour, pas de modèle de données lisible. | Temps perdu : deux à quatre semaines avant qu'une nouvelle personne livre en confiance. Coût de dérivation : iel devient le goulot d'étranglement qui répond aux questions. | À chaque arrivée — 3 à 4 par an dans son équipe |
| D5 | Revue de code sans critère d'acceptation. On revoit un diff, pas une intention. | Risque : la revue valide la forme et laisse passer le fond. Temps perdu : discussions en boucle sur des choix qui auraient dû être tranchés en amont. | À chaque demande de tirage — 8 à 15 par semaine dans l'équipe |
| D6 | Agent IA sans périmètre ni journal. L'assistant a accès à tout, ne journalise rien d'opposable, et personne ne peut dire après coup ce qu'il a réellement fait. | Risque encouru : action non désirée sur un dépôt ou un secret. Décision retardée : la direction technique refuse d'élargir l'usage faute de garanties. | Permanent — c'est une posture, pas un incident |
| D7 | Pipeline CI/CD réécrit à chaque projet. Copier-coller d'un YAML d'un autre dépôt, adapté à la main. | Temps perdu : une demi-journée à une journée par nouveau service. Risque : dérive silencieuse entre pipelines. | À chaque nouveau service — 4 à 8 par an |
| D8 | Secrets qui circulent mal. Jetons dans un fichier .env partagé, clés collées dans la messagerie. |
Risque encouru : fuite, rotation impossible, audit défavorable. | Chaque fois qu'un nouveau service parle à un service externe |
| D9 | Tests non reliés aux exigences. Le taux de couverture est bon ; personne ne sait quelles exigences sont réellement couvertes. | Risque : faux sentiment de sécurité. Décision retardée : on ne sait pas quoi tester en priorité avant une mise en production. | À chaque préparation de version |
| D10 | Déploiement = ticket d'attente. Iel ne déploie pas ; iel demande. | Décision retardée : de quelques heures à plusieurs jours. Temps perdu : reprise de contexte à chaque relance. | 2 à 5 fois par semaine |
| D11 | Base de données opaque. Le schéma réel a divergé de ce que dit le code ; les index manquants se découvrent en incident. | Risque encouru : dégradation de performance en production. | 1 à 2 fois par trimestre |
| D12 | Décisions techniques dissoutes dans la messagerie. Aucun enregistrement de décision d'architecture. | Temps perdu : la même discussion recommence six mois plus tard. | Mensuel |
#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 le statut Planifié.
| Douleur | Fonctionnalité KySpectra qui y répond | Où c'est dans le produit | Statut | Ce que ça change concrètement |
|---|---|---|---|---|
| D1 Intention perdue | Rétro-ingénierie d'un dépôt existant vers sept familles d'artefacts, puis promotion automatique de spécifications après décision humaine | reverse-engineering-service (4120) — POST /api/v1/reverse-engineering/jobs, GET …/jobs/{id}/emit ; file de validation GET …/validation-tasks, décision POST …/validation-tasks/{id}/decision (rôle PUBLISHER) ; portail : /projects/{id}/sources et /imports |
🟢 Livré — prouvé en production | Le code existant produit des exigences opposables au lieu d'un wiki mort. La décision d'accepter reste humaine. |
| D1 Intention perdue | Spécification exécutable : objets versionnés, typés, reliés ; détail d'un objet avec son historique | 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é | Avant de modifier, iel ouvre l'objet de spécification, pas un ticket clos. |
| D2 Impact inconnu | Graphe de traçabilité et analyse d'impact avant modification | spec-service — GET /api/v1/spec-items/{id}/traceability, GET /api/v1/spec-items/{id}/relationships, POST /api/v1/spec-items/{id}/impact ; portail : vue graph de l'espace de travail et page /projects/{id}/trace |
🟢 Livré | La question « qu'est-ce qui casse si j'y touche ? » a une réponse affichable en revue. |
| D2 Impact inconnu | Graphe de dépendances au niveau du projet | dependency-graph-service (4117), monté sous /api/v1/dependency-graph/... |
🟢 Livré | Vue des couplages réels, pas supposés. |
| D3 Le ticket ne dit pas pourquoi | Analyse des é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é, pas une intuition à défendre en réunion. |
| D3 Le ticket ne dit pas pourquoi | Copilote spécification : du langage naturel vers des objets de spécification proposés, avec revue 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é | Le « pourquoi » se capture au moment où il est encore dans la tête de quelqu'un. |
| D4 Onboarding | Artefacts d'architecture projetés : DDD, C4/TOGAF, UML, BPMN, modèle de données, artefacts de sécurité, dépendances | artifact-service (4129) — /api/v1/artifacts, /api/v1/diagrams, /api/v1/togaf, /api/v1/sec-artifacts, /api/v1/documentation ; portail : vue artifacts |
🟢 Livré | Une carte du système générée depuis la spécification, pas dessinée à la main puis oubliée. |
| D4 Onboarding | Documentation-comme-code exportable | Vue docs de l'espace de travail, gatée par la capacité docs:export |
🟢 Livré | La documentation se régénère au lieu de se périmer. |
| D5 Revue sans critère | Vue de revue : écarts, matrice de traçabilité, décision consignée | Vue review (capacité review:read) ; collaboration-service (4128) — /api/v1/reviews, /api/v1/comments |
🟢 Livré | On revoit un diff et l'exigence qu'il sert. |
| D5 Revue sans critère | Séparation des devoirs : impossible d'approuver sa propre soumission | collaboration-service — machine à états de revue, rejet de submitted_by == reviewer_id ; l'interface bloque le bouton avant l'appel serveur |
🟢 Livré | La règle est dans le produit, pas dans une consigne d'équipe. |
| D6 Agent sans périmètre | Moteur de politique en liste d'autorisations : toute action non couverte est refusée et journalisée sous policy_id="deny-by-default" |
agent-runtime-service (4119), table app_policy_check ; administration : /policies du plan de contrôle |
🟢 Livré | L'agent ne peut faire que ce qui a été explicitement autorisé. |
| D6 Agent sans périmètre | Runs d'agents observables en direct et interruption d'un run | Portail : vue agentops et page /agents ; agent-runtime-service — GET /api/v1/agent-runtime/runs, POST …/runs/{id}/interrupt |
🟢 Livré | On voit ce que fait l'agent pendant qu'il le fait, et on peut l'arrêter. |
| D6 Agent sans périmètre | Plafond d'autonomie N0→N3, plafonné par le plan commercial, dégradé vers N1 en cas d'incertitude | extension-registry-service (4116) — cap_autonomy ; portail : /roles ; administration : /roles |
🟢 Livré (drapeau REGISTRY_VIRTUAL_ROLES_ENABLED, défaut False — activation requise) |
Le niveau d'autonomie est une décision explicite, révocable. |
| D7 Pipeline réécrit | Génération de pipeline CI/CD pour quatre fournisseurs, avec commit réel dans le dépôt | deploy-service (4121) — POST /api/v1/deploy/cicd/generate, POST /api/v1/deploy/cicd/setup |
🟢 Livré (prouvé en développement — commit réel dans un dépôt Gitea) | Le pipeline arrive avec le service, pas trois jours après. |
| D7 Pipeline réécrit | Déclencheurs CI externes (relance d'un pipeline hébergé chez un tiers depuis KySpectra) | — | ⚪ Planifié — n'existe pas aujourd'hui, à dire franchement | À la feuille de route ; ne pas le vendre. |
| D8 Secrets qui circulent | Coffre de secrets par projet : dépôt réel, relecture indépendante, jamais de secret inline | deploy-service — POST /api/v1/deploy/credentials/deposit ; portail : /credentials ; côté sources, un secret inline est rejeté en 422 |
🟢 Livré — prouvé en développement et en production | Plus de jeton dans la messagerie ; une référence de coffre circule à la place. |
| D9 Tests non reliés | Couverture des critères d'acceptation rattachée aux objets de spécification | Vue test de l'espace de travail (capacité test:read, projets de type test_only) ; test-quality-service (4109) — /test-plans, /test-cases, /test-suites, /test-cycles, /runs |
🟢 Livré | On sait quelles exigences sont couvertes, pas seulement quel pourcentage de lignes. |
| D9 Tests non reliés | Test navigateur réel et jeux de données de test synthétiques | deploy-service — POST /api/v1/deploy/uat/browser, POST /api/v1/deploy/uat/run ; test-data-factory-service (4110) — /api/v1/test-data-factory/test-datasets |
🟢 Livré (navigateur : prouvé en développement) | Les tests tournent sur un vrai navigateur et sur des données qui n'exposent aucun renseignement personnel. |
| D10 Déploiement = attente | Déploiement gouverné : approbation, exécution, retour arrière, mise en ligne sur sous-domaine avec TLS | deploy-service — POST /api/v1/deploy/go-live/{project} (drapeau GOLIVE_ENABLED), rollout in-cluster avec approbation DEPLOY_REQUIRE_APPROVAL ; portail : vue delivery et page /approvals |
🟢 Livré pour Kubernetes — prouvé en production | Le déploiement devient une décision tracée, pas un ticket dans une file. |
| D10 Déploiement = attente | Pilotes nuage natifs — Azure Container Apps, Cloud Run, ECS | — | ⚪ Planifié — seul le mécanisme générique par interface en ligne de commande nuage est prouvé | Ne jamais présenter les pilotes natifs comme disponibles. |
| D11 Base opaque | Analyse réelle d'une base PostgreSQL en exploitation et conseil de conception | deploy-service — POST /api/v1/deploy/db/analyze, POST /api/v1/deploy/db/advise |
🟢 Livré — prouvé en développement et en production | Le schéma réel et ses statistiques deviennent lisibles sans passer par l'exploitation. |
| D12 Décisions dissoutes | Enregistrements de décision d'architecture rattachés au projet | spec-service — routeur /adrs, avec surface avancée ; baselines de spécification GET /api/v1/projects/{id}/baselines |
🟢 Livré | La décision devient un objet daté, pas un fil de messagerie. |
| Attente non couverte | Assistant de complétion dans l'éditeur | — | ⚪ Planifié / hors périmètre assumé | KySpectra ne concurrence pas un outil de complétion ligne à ligne ; il gouverne le cycle qui entoure cette ligne. À dire dès le premier échange. |
| 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 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. 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 | Reprise de contexte, tri de tickets, réunion de planification | 2 h de compréhension avant la première ligne | Le ticket n'explique pas la contrainte d'origine |
| Mardi | Développement d'une fonctionnalité sur un module ancien | 2 h 30 d'archéologie, 3 h de code | Historique Git peu bavard, wiki périmé |
| Mercredi | Revue de code de trois collègues | 2 h de revue, dont 45 min à chercher l'intention | On revoit un diff sans critère d'acceptation |
| Jeudi | Nouveau service : mise en place du pipeline, des secrets, de l'environnement | 4 h à 6 h | Copier-coller de YAML, secrets partagés à la main |
| Vendredi | Préparation de version, correction d'un défaut remonté | 1 h 30 d'attente sur la file de déploiement | Iel demande, iel n'exécute pas |
#4.2 Après KySpectra
| Jour | Ce qui change | Heures déplacées [Hypothèse] |
Comment le mesurer |
|---|---|---|---|
| Lundi | Le ticket est adossé à un objet de spécification versionné ; le « pourquoi » est lisible dans /projects/{id}/spec/{itemId} |
−45 min de reprise de contexte | Nombre d'objets de spécification consultés avant ouverture d'une branche — journal d'audit audit-compliance-service, GET /api/v1/audit-compliance/audit/events |
| Mardi | Avant de modifier, iel ouvre la vue graph et lance POST /api/v1/spec-items/{id}/impact |
−1 h 30 d'archéologie, +15 min de lecture de graphe | Nombre d'appels d'impact par semaine ; comparaison du délai entre ouverture de tâche et première livraison |
| Mercredi | La revue affiche l'exigence, la matrice de traçabilité et les écarts (vue review) |
−30 min de revue, qualité de revue en hausse | Nombre de revues portant une décision consignée dans collaboration-service /api/v1/reviews |
| Jeudi | Pipeline généré et commité par POST /api/v1/deploy/cicd/setup ; secret déposé au coffre par POST /api/v1/deploy/credentials/deposit |
−3 h sur la mise en place d'un nouveau service | Compte des pipelines générés ; compte des dépôts de secret réussis |
| Vendredi | Déploiement demandé et approuvé dans /approvals, exécuté par deploy-service, retour arrière disponible |
−1 h d'attente, traçabilité complète | Délai entre demande et approbation ; nombre de retours arrière déclenchés |
#4.3 Bilan hebdomadaire
| Poste | Avant | Après [Hypothèse] |
Écart [Hypothèse] |
|---|---|---|---|
| Compréhension / archéologie | 6 h 15 | 3 h 30 | −2 h 45 |
| Mise en place d'environnement et de pipeline | 5 h (amorti sur 4 semaines : 1 h 15/sem.) | 0 h 30/sem. | −0 h 45 |
| Revue de code | 2 h | 1 h 30 | −0 h 30 |
| Attente de déploiement | 1 h 30 | 0 h 30 | −1 h |
| Total déplacé | — | — | ≈ 5 h par semaine et par développeur [Hypothèse] |
Honnêteté sur le chiffre. Ces 5 heures 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 compréhension 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 Malik |
|---|---|
| Confiance | Iel peut expliquer, six mois après, pourquoi une ligne existe — parce qu'elle est reliée à une exigence versionnée. |
| Autonomie | Iel n'attend plus l'exploitation pour déployer : iel demande, un approbateur distinct décide, la plateforme exécute et trace. |
| Sécurité mentale | Le graphe d'impact remplace l'intuition. Le refactoring redevient possible. |
| Qualité de revue | La revue porte sur une intention, pas seulement sur un diff. |
| Rapport aux agents | L'agent devient un collaborateur avec un périmètre, un plafond d'autonomie et un journal — pas une boîte noire à surveiller du coin de l'œil. |
| Transmissibilité | Ce qu'iel construit reste explicable devant la personne qui prendra sa suite. C'est la promesse du manifeste, mot pour mot. |
#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 compréhension récupéré
GAIN_COMPREHENSION = D × H_arch × R × S
| Variable | Signification | Valeur de travail |
|---|---|---|
D |
Nombre de développeurs concernés | 8 [Hypothèse] |
H_arch |
Heures hebdomadaires d'archéologie avant | 6,25 h [Hypothèse], §4.3 |
R |
Part récupérée grâce à la traçabilité | 0,44 [Hypothèse], §4.3 |
S |
Semaines travaillées par an | 44 [Hypothèse] |
Application : 8 × 6,25 × 0,44 × 44 = 968 heures-personnes par an [Hypothèse].
#Formule 2 — Coût évité de mise en place de service
GAIN_SETUP = N_services × (H_avant − H_apres)
| Variable | Signification | Valeur de travail |
|---|---|---|
N_services |
Nouveaux services par an | 6 [Hypothèse] |
H_avant |
Heures de mise en place manuelle — pipeline, secrets, environnement | 5 h [Hypothèse] |
H_apres |
Heures avec génération de pipeline et dépôt de secret | 1 h [Hypothèse] |
Application : 6 × (5 − 1) = 24 heures-personnes par an [Hypothèse].
#Formule 3 — Risque de régression évité
VALEUR_RISQUE = F_regression × C_incident × P_evitement
| Variable | Signification | Valeur de travail |
|---|---|---|
F_regression |
Régressions structurelles par an | [Gabarit : nombre de régressions par an, à extraire du gestionnaire d'incidents du client] |
C_incident |
Coût moyen d'un incident — heures de mobilisation + indisponibilité | [Gabarit : coût moyen d'incident, à établir avec le client] |
P_evitement |
Part évitable grâce à l'analyse d'impact préalable | 0,3 [Hypothèse] |
Interdiction assumée. Tant que
F_regressionetC_incidentne sont pas fournis par le client, cette formule ne produit aucun chiffre publiable. On la présente vide, on la remplit ensemble.
#Formule 4 — Coût de la plateforme, à mettre en regard
COUT_ANNUEL = U × P_mensuel × 12
Avec U = utilisateurs et P_mensuel = 49 $ CAD [Hypothèse] — montant réellement présent dans le catalogue de plans en base (slug = team, 4 900 cents, devise CAD ; annuel 49 000 cents). Pour 8 développeurs : 8 × 49 × 12 = 4 704 $ 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, 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 — Malik, ingénieur logiciel
#Tâches à accomplir
| Type | Tâche | Intensité |
|---|---|---|
| Fonctionnelle | Livrer une fonctionnalité conforme sans casser l'existant | Quotidienne |
| Fonctionnelle | Comprendre un module qu'iel n'a pas écrit | Hebdomadaire |
| Fonctionnelle | Revoir le code de ses pairs avec un jugement défendable | Quotidienne |
| Fonctionnelle | Mettre en place un nouveau service : dépôt, pipeline, secrets, environnement | Trimestrielle |
| Fonctionnelle | Diagnostiquer un incident de production | Mensuelle |
| Sociale | Être la personne à qui on confie le module critique | Continue |
| Sociale | Ne pas être celle qui a cassé la production | Continue |
| Sociale | Laisser derrière soi un système que d'autres peuvent reprendre | À l'échelle de l'année |
| Émotionnelle | Travailler sans la crainte diffuse de l'effet de bord inconnu | Continue |
| Émotionnelle | Assumer publiquement le code produit avec une assistance générative | Continue |
#Frustrations
| Frustration | Sévérité |
|---|---|
| Archéologie avant chaque modification | Élevée |
| Absence de carte d'impact fiable | Élevée |
| Documentation qui ment | Élevée |
| Revue qui ne porte que sur la forme | Moyenne |
| Attente sur la file de déploiement | Moyenne |
| Agents IA à qui on ne peut rien reprocher parce qu'on ne sait rien d'eux | Élevée |
| Secrets partagés à la main | Moyenne |
| Décisions techniques évaporées | Moyenne |
#Attentes et gains recherchés
| Gain attendu | Nature |
|---|---|
| Savoir en trente secondes pourquoi un morceau de code existe | Gain de temps |
| Voir ce qui casse avant de modifier | Réduction de risque |
| Déployer sans quémander, mais avec une trace | Autonomie encadrée |
| Utiliser des agents sans craindre le hors-piste | Confiance |
| Une documentation qui se régénère | Durabilité |
| Une revue qui améliore réellement le produit | Fierté professionnelle |
#7.2 Carte de valeur — KySpectra
#Produits et services proposés
| Élément | Surface réelle | Statut |
|---|---|---|
| Espace de travail projet à 11 vues canoniques | Portail client — /projects/{id}/workspace?view=… |
🟢 Livré |
| Explorateur et détail de spécification | /projects/{id}/spec, /projects/{id}/spec/{itemId} |
🟢 Livré |
| Graphe de traçabilité et d'impact | Vue graph, /projects/{id}/trace |
🟢 Livré |
| Rétro-ingénierie et sources de projet | /projects/{id}/sources, /imports |
🟢 Livré |
| Observation des agents en direct | Vue agentops, /agents |
🟢 Livré |
| Chaîne de livraison gouvernée | Vue delivery, /approvals |
🟢 Livré (Kubernetes) |
| Coffre d'identifiants | /credentials |
🟢 Livré |
| Consommation et budgets | /usage |
🟢 Livré |
| Personnel virtuel IA | Vue workforce |
🟢 Livré — phase 1 |
| Place de marché de capacités | — | 🟡 En cours |
| Application mobile | — | ⚪ Planifié |
#Solutions aux problèmes
| Frustration visée | Mécanisme produit qui la traite |
|---|---|
| Archéologie | Promotion automatique de spécifications depuis un dépôt réel, avec décision humaine obligatoire |
| Impact inconnu | POST /api/v1/spec-items/{id}/impact et vue graph |
| Documentation qui ment | Artefacts projetés depuis la spécification, régénérables |
| Revue sur la forme | Vue review : écarts + matrice + séparation des devoirs appliquée par la machine à états |
| Attente de déploiement | Déploiement gouverné avec approbation par un tiers et retour arrière |
| Agents opaques | Refus par défaut journalisé, registre central d'agents, interruption de run, budget de jetons |
| Secrets à la main | Dépôt au coffre, rejet 422 de tout secret inline dans une source de projet |
#Créateurs de gains
| Gain recherché | Créateur de gain KySpectra |
|---|---|
| Comprendre vite | Sept familles d'artefacts de rétro-ingénierie reconstruites à la demande |
| Modifier sans peur | Traçabilité bidirectionnelle : les défauts remontent vers l'exigence |
| Déployer soi-même, proprement | Approbation séparée, exécution tracée, retour arrière, TLS automatique sur sous-domaine |
| Agents utilisables | Plafond d'autonomie N0→N3, plafonné par le plan, dégradé vers N1 en cas d'incertitude |
| Documentation vivante | Documentation-comme-code exportable depuis la vue docs |
| Honnêteté d'outil | 501 Not Implemented explicite plutôt qu'un faux succès ; DEPLOY_LIVE=false par défaut |
#7.3 Évaluation d'adéquation
| Tâche / frustration | Réponse produit | Niveau d'adéquation | Commentaire |
|---|---|---|---|
| Comprendre un module inconnu | Rétro-ingénierie + artefacts + spécification | Fort | C'est le cœur de la proposition, prouvé en production |
| Voir l'impact avant de modifier | Graphe + endpoint d'impact | Fort | Livré et central dans l'interface |
| Revue avec critère | Vue review + séparation des devoirs |
Fort | Livré, appliqué serveur et interface |
| Gouverner un agent | Refus par défaut + registre + plafond d'autonomie | Fort | Livré ; le plafond exige l'activation d'un drapeau aujourd'hui à False |
| Mettre en place un service | Génération de pipeline + coffre | Moyen à fort | Livré et prouvé en développement ; pas encore de preuve production sur ce maillon précis |
| Déployer sans attendre | Déploiement gouverné Kubernetes | Fort sur Kubernetes, faible hors Kubernetes | Les pilotes nuage natifs sont Planifiés |
| Écrire du code plus vite dans l'éditeur | — | Nul, assumé | KySpectra n'est pas un assistant de complétion. À dire d'emblée. |
| 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 assistant de complétion, pourquoi un outil de plus ? » | Ce n'est pas le même problème. Un assistant de complétion vous aide à écrire la ligne suivante. KySpectra gouverne le cycle autour de cette ligne : d'où vient l'exigence, quel agent a produit quoi, qui a approuvé, ce qui casse si on modifie. Les deux cohabitent. Si votre seul besoin est d'écrire plus vite, ce n'est pas pour vous. |
| O2 | « Écrire des spécifications, c'est du temps que je n'ai pas. » | C'est l'objection la plus juste. Deux réponses. D'abord, vous n'écrivez pas la spécification depuis une page blanche : la rétro-ingénierie la produit depuis votre dépôt, vous décidez ce que vous acceptez. Ensuite, le copilote POST /api/v1/copilot/ask transforme du langage naturel en objets proposés, que vous relisez avant écriture. Si votre équipe refuse par principe toute forme de spécification, l'outil ne changera rien. |
| O3 | « Encore une couche de gouvernance qui va me ralentir. » | La gouvernance est configurable et par défaut minimale : DEPLOY_REQUIRE_APPROVAL vaut False. Vous l'activez si votre contexte l'exige. En revanche, le refus par défaut du moteur de politique n'est pas désactivable, et c'est délibéré : c'est ce qui rend l'usage d'agents défendable devant votre direction. |
| O4 | « 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. Les seuls chiffres que nous publions sont ceux de notre propre dépôt : 255 commits, ~30 services backend, plus de 3 700 tests automatisés, 3 environnements en ligne. |
| O5 | « Vous n'avez aucun client de référence. » | Exact. [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 : dépôt public importé, rétro-ingénierie, spécifications promues, produit servi sur un sous-domaine avec TLS. Nous préférons vous montrer ça qu'un logo. |
| O6 | « Le code va être enfermé dans votre plateforme. » | Non. Le résultat est du vrai code, dans un vrai dépôt, avec un vrai pipeline — le pipeline est même commité chez vous par POST /api/v1/deploy/cicd/setup. Il n'y a pas de moteur d'exécution propriétaire. Si vous partez, votre dépôt et votre pipeline restent fonctionnels. Ce que vous perdez, c'est le graphe de traçabilité et le journal. |
| O7 | « Vos agents vont faire n'importe quoi dans mon dépôt. » | C'est précisément ce que le produit empêche. Le moteur de politique est une liste d'autorisations : toute action non explicitement couverte est refusée et journalisée sous policy_id="deny-by-default", dans la table app_policy_check. Chaque run est observable et interruptible via POST /api/v1/agent-runtime/runs/{id}/interrupt. Et le plafond d'autonomie dégrade vers N1 en cas d'incertitude. |
| O8 | « Mon organisation est sur Azure, pas sur Kubernetes. » | Alors soyons clairs : le déploiement gouverné est prouvé sur Kubernetes. Le mécanisme générique « interface en ligne de commande nuage dans une tâche éphémère » est prouvé, avec un déploiement AWS réel. Les pilotes natifs Azure Container Apps, Cloud Run et ECS sont Planifiés, pas disponibles. Si votre besoin est un pilote natif Azure aujourd'hui, ce n'est pas pour vous aujourd'hui. |
| O9 | « On travaille beaucoup depuis le téléphone. » | Les deux 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 | « Combien de temps avant que ce soit utile ? » | La rétro-ingénierie d'un dépôt existant donne des artefacts dès le premier job — c'est le maillon « Comprendre », prouvé en production. La valeur du graphe d'impact arrive quand vos exigences sont promues, ce qui suppose des décisions humaines dans la file GET /api/v1/reverse-engineering/validation-tasks. Comptez une à deux semaines de va-et-vient pour un dépôt de taille moyenne. [Gabarit : durée médiane de promotion sur un dépôt réel, à mesurer en Phase 1] |
| O11 | « 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. |
| O12 | « Vos interfaces affichent encore SPECTRA. » |
Oui, et c'est un écart connu, listé dans le brief : common.appName vaut encore SPECTRA et il n'existe aucun fichier de logo dans le dépôt. C'est une action de pré-lancement identifiée, pas une découverte que vous nous faites. Nous préférons vous le dire avant que vous le voyiez. |
| O13 | « Le drapeau des rôles virtuels est désactivé par défaut. Donc le plafond d'autonomie ne marche pas ? » | Le mécanisme est livré et testé. Le drapeau REGISTRY_VIRTUAL_ROLES_ENABLED vaut False par défaut et n'est activé dans aucun manifeste de déploiement du dépôt : son activation est une opération d'exploitation, pas un développement. Nous ne prétendons pas qu'il est actif partout. |
#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 (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 des agents produire et tester sous supervision, 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 |
| 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 travailler |
| Taille d'équipe | Cible de 3 à 25 personnes, ce qui correspond à l'équipe de Malik |
#9.3 Ce qui est inclus
| Inclus | Détail |
|---|---|
| Espace de travail projet complet | 11 vues canoniques, gatées par capacité |
| Rétro-ingénierie | Jobs, sept familles d'artefacts, file de validation humaine, promotion de spécifications |
| Spécification exécutable | Objets versionnés, relations, traçabilité, analyse d'impact, enregistrements de décision, baselines |
| Artefacts d'architecture | DDD, C4/TOGAF, UML, BPMN, modèle de données, artefacts de sécurité |
| Agents gouvernés | Registre central, refus par défaut, séparation des devoirs, journal d'audit chaîné, interruption de run |
| Livraison | Génération et commit de pipeline CI/CD, déploiement gouverné Kubernetes, retour arrière, sous-domaine avec TLS |
| Vérification | Génération de tests, données de test synthétiques, test navigateur réel, portes de qualité, analyse de base de données |
| Coffre | Dépôt de secrets par projet |
| 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 |
|---|---|
| Recherche en ligne pour les agents | Réservée au palier Entreprise — registry.online_search à false au palier Équipe |
| 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 |
| Pilotes nuage natifs | ⚪ Planifié — hors de tout palier aujourd'hui |
| Application mobile | ⚪ Planifié — aucun code mobile dans le dépôt |
| Place de marché de capacités | 🟡 En cours — non déployée |
| Provisionnement automatique de fournisseur d'identité | ⚪ Planifié — bloqué par des droits d'administration, action d'exploitation requise |
| Assistant de complétion de code | Hors périmètre assumé |
#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 ; besoin d'une compétence ou d'un outil personnalisé | 25 compétences, 10 outils, 10 rôles, 5 000 appels/jour, plafond N2 |
| Équipe → Entreprise | Exigence de recherche en ligne pour les agents ; besoin du plafond N3 ; contrainte réglementaire sur le journal d'audit et les rapports Loi 25 | 1 000 compétences, 500 outils, 200 rôles, 1 000 000 d'appels/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 |
|---|---|---|
| Un dépôt réel importé et rétro-ingéniéré | 1 dépôt | GET /api/v1/reverse-engineering/jobs — job en statut ready |
| Artefacts d'architecture consultés | ≥ 4 des 7 familles | Vue artifacts de l'espace de travail |
| Objets de spécification promus après décision humaine | ≥ 20 | GET /api/v1/reverse-engineering/validation-tasks en statut approved |
| Développeurs ayant ouvert l'espace de travail au moins 3 fois | ≥ 60 % de l'équipe | Journal d'audit audit-compliance-service |
| Premier pipeline CI/CD généré | 1 | POST /api/v1/deploy/cicd/generate |
#10.2 À 60 jours
| Indicateur | Cible [Hypothèse] |
Source de mesure réelle |
|---|---|---|
| Analyses d'impact lancées avant modification | ≥ 15 par mois | POST /api/v1/spec-items/{id}/impact |
| Revues portant une décision consignée | ≥ 70 % des demandes de tirage | collaboration-service — /api/v1/reviews |
Runs d'agents observés dans la vue agentops |
≥ 30 | GET /api/v1/agent-runtime/runs |
| Secrets déposés au coffre plutôt que partagés à la main | 100 % des nouveaux secrets | POST /api/v1/deploy/credentials/deposit |
Refus deny-by-default examinés et arbitrés |
100 % | Table app_policy_check, panneau /policies du plan de contrôle |
#10.3 À 90 jours
| Indicateur | Cible [Hypothèse] |
Source de mesure réelle |
|---|---|---|
| Délai médian « ouverture de tâche → première livraison » | −20 % par rapport au point de départ | [Gabarit : mesure de référence à établir en semaine 1 du pilote] |
| Part des livraisons rattachées à un objet de spécification | ≥ 80 % | Traçabilité spec-service |
| Déploiements passés par la chaîne gouvernée | ≥ 50 % | deploy-service — runs de déploiement, page /approvals |
| Retours arrière déclenchés sans incident prolongé | 100 % de succès | Journal de deploy-service |
| Nouvelle personne autonome sur un service inconnu | −30 % de délai [Hypothèse] |
[Gabarit : durée d'onboarding avant/après, à collecter auprès du responsable d'équipe] |
#11. Accroches pour cette persona
Six accroches rédigées, avec canal recommandé. Ton : praticien à praticien, vouvoiement, aucun superlatif.
| # | Accroche | Canal recommandé | Intention |
|---|---|---|---|
| A1 | « La ligne que vous n'osez pas supprimer a une raison d'exister. Nous vous la montrons. » Importez votre dépôt, obtenez le graphe qui relie chaque module à l'exigence qui l'a motivé. |
Publication technique longue sur un carnet de développement ou une plateforme de veille pour ingénieurs | Toucher la douleur D1 sans promettre de gain chiffré |
| A2 | « Avant de modifier : qu'est-ce qui casse ? » Une analyse d'impact avant chaque changement structurant, adossée à une spécification versionnée — pas à votre mémoire. |
Démonstration courte en vidéo, 90 secondes, sur réseau professionnel | Montrer la vue graph en action |
| A3 | « Vos agents IA ont-ils un journal opposable ? » Chez nous, toute action non explicitement autorisée est refusée et journalisée sous deny-by-default. Vous pouvez interrompre un run en cours. |
Fil court sur réseau social technique, ou intervention en conférence développeurs | Adresser D6 avec une preuve vérifiable |
| A4 | « Le pipeline arrive avec le service, pas trois jours après. » Génération pour quatre fournisseurs, et le fichier est commité dans votre dépôt. |
Courriel de séquence d'activation, message 2 sur 5 | Adresser D7 avec un bénéfice immédiat et mesurable |
| A5 | « Nous répondons 501 plutôt que de simuler. » Une fonctionnalité non configurée le dit. Aucun déploiement n'est simulé : DEPLOY_LIVE vaut false par défaut. C'est notre définition de l'honnêteté d'ingénierie. |
Page produit, section « Ce que nous ne faisons pas » ; reprise en présentation technique | Construire la confiance par la limite assumée — différenciateur D5 du brief |
| A6 | « De l'intention au logiciel en production, gouverné. » Dépôt importé, spécifications promues, code construit, image publiée, produit servi sur un sous-domaine avec TLS. Prouvé en production, chez nous, avant de vous le proposer. |
Bandeau de site, signature de courriel, affiche de salon | Slogan principal du brief, décliné pour un public d'ingénieurs |
#12. Ce que nous refusons de dire à cette persona
| Formulation interdite | Pourquoi |
|---|---|
| « Multipliez votre productivité » | Aucun gain de productivité chiffré n'est revendiqué (brief §7) |
| « Remplacez vos développeurs » | Interdit explicitement (brief §2) |
| « Conformité automatique » | Non revendiqué |
| « Le meilleur outil de spécification » | Superlatif creux (brief §12) |
| « Nos clients constatent… » | Aucun témoignage n'existe (brief §15) |
| « Déployez sur n'importe quel nuage » | Les pilotes natifs sont Planifiés |
| « Notre application mobile » | 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.