#0. Résumé en dix lignes
| Élément | Contenu |
|---|---|
| Persona | Architecte logiciel / d'entreprise — persona n° 4 du brief commun (§9) |
| Douleur dominante | Architecture réelle inconnue et divergente du plan |
| Ce que KySpectra apporte | Une architecture reconstruite depuis le code réel, des artefacts régénérables au lieu de schémas dessinés à la main, un graphe de couplages, des décisions d'architecture consignées et des baselines opposables |
| Surfaces concernées | Portail client — espace de travail projet, 11 vues canoniques ; vues artifacts, graph, docs, spec, review, delivery ; plan de contrôle d'administration — destinations policies, registry, governance |
| Services réels sollicités | reverse-engineering-service (4120), artifact-service (4129), dependency-graph-service (4117), spec-service (4107), deploy-service (4121), platform-config (4112), collaboration-service (4128) |
| Offre recommandée | Palier Équipe — 49,00 $ CAD/mois [Hypothèse] ; Entreprise dès trois équipes ou une contrainte réglementaire ; plafond d'autonomie N2 → N3 |
| Ce qu'on ne promet pas | Des pilotes nuage natifs ; une application mobile ; une place de marché de capacités ; un provisionnement automatique de fournisseur d'identité |
| Statut de la chaîne | Maillons 1 à 6 Livrés ; pilotes nuage natifs ⚪ Planifiés ; place de marché 🟡 En cours ; provisionnement de fournisseur d'identité 🔴 Bloqué |
| Preuve la plus parlante | Dépôt public importé → rétro-ingénierie vers sept familles d'artefacts → spécifications promues après décision humaine, prouvé en production |
| Risque d'adoption | La personne possède déjà un outil de modélisation et craint un doublon ; KySpectra reconstruit depuis le code, il ne remplace pas la planche à dessin |
#1. Portrait
Nour, 41 ans, architecte logiciel devenue architecte d'entreprise il y a trois ans. Iel exerce dans une organisation qui exploite une soixantaine de services et deux grappes Kubernetes — une de développement et de qualification, une de production. Trois équipes produit y travaillent en parallèle, plus une équipe d'exploitation transverse et deux prestataires externes qui livrent par vagues.
Iel n'a pas toujours été architecte. Iel a écrit du code pendant douze ans, puis a pris la responsabilité d'un domaine, puis de trois. Ce parcours lui a laissé une méfiance durable envers les schémas : un diagramme est vrai le jour où il est dessiné, et faux le lendemain. Iel a hérité d'un dossier d'architecture de 180 pages produit par un cabinet, jamais mis à jour, dont plus personne n'ose se servir mais que tout le monde cite en réunion.
Depuis dix-huit mois, une nouvelle variable est apparue : une part croissante du code arrive dans les dépôts sans avoir été explicitement conçue par quelqu'un. Il a été produit avec une assistance générative. Il passe les tests. Il fonctionne. Et il n'est rattaché à aucune décision d'architecture que Nour puisse retrouver.
#1.1 Sa journée réelle
Iel arrive vers 8 h 45. Iel ouvre un outil de modélisation, deux tableaux de bord de supervision, un dépôt de documentation d'entreprise et sa messagerie. Iel passe entre 40 % et 60 % de son temps en réunion — comités d'architecture, arbitrages inter-équipes, revues de conception. Le reste se répartit entre la lecture de code qu'iel n'a pas écrit, la mise à jour de schémas qui seront périmés dans trois semaines, et la rédaction de notes que peu de gens liront.
Iel n'a jamais, à aucun moment, une vue exacte du système. Iel a une vue plausible.
#1.2 Sa boîte à outils actuelle
| Catégorie | Ce qu'iel utilise aujourd'hui |
|---|---|
| Modélisation | Outil de diagrammes généraliste, plus un outil de modélisation d'entreprise acheté il y a quatre ans, peu utilisé par les équipes |
| Documentation | Dépôt de documentation d'entreprise, pages en Markdown dans les dépôts, un tableur de suivi des services |
| Inventaire | Un tableur maintenu à la main, une liste d'espaces de noms Kubernetes, un registre d'images |
| Décisions | Un dossier d'enregistrements de décision d'architecture dans un dépôt Git — quatorze fichiers, dont le dernier date de huit mois |
| Supervision | Tableaux de bord de métriques, traces distribuées partielles, journaux centralisés |
| Revue | Comité d'architecture bimensuel, présentation en diapositives, compte rendu en messagerie |
| Communication | Messagerie d'équipe, où se prennent la majorité des arbitrages techniques — et où ils se dissolvent |
#1.3 Ce qui le fait juger — par ses pairs et par sa hiérarchie
- La capacité de l'organisation à absorber un changement structurant sans arrêt de service.
- Le fait que les équipes appliquent les principes d'architecture sans qu'iel ait à intervenir.
- La qualité de la réponse quand un auditeur, un client grand compte ou un comité demande : « Comment ce système est-il construit et pourquoi ainsi ? »
- Le délai avant qu'un nouveau service soit conforme aux règles transverses — sécurité, observabilité, sortie réseau.
- Le nombre de décisions qu'iel doit reprendre parce qu'elles ont été prises sans lui.
#1.4 Ce qui l'empêche de dormir
- L'écart entre le plan et le réel. Iel sait qu'il existe. Iel ne sait pas où, ni de combien.
- Le couplage qu'iel ignore. Deux services qui se parlent sans passer par le contrat prévu, découvert le jour d'un incident.
- Le service que personne ne revendique. Il tourne, il consomme, il a un propriétaire nominal parti l'an dernier.
- La question du comité. « Pouvez-vous prouver que ce choix respecte notre politique ? » Iel a une conviction, pas une preuve.
- La production assistée par IA. Du code qui s'ajoute plus vite que la capacité de l'organisation à le comprendre.
Sa phrase à lui, telle qu'iel la dirait en entretien : « Mon problème n'est pas de dessiner l'architecture cible. Mon problème est que je ne connais pas l'architecture actuelle, et que je dois quand même arbitrer. »
#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 | Divergence entre le plan et le réel. L'architecture documentée décrit une intention ; le système déployé décrit autre chose. | Risque encouru : un arbitrage rendu sur une carte fausse. Décision retardée : chaque décision structurante commence par une phase de vérification manuelle de plusieurs jours. | Permanent — s'aggrave à chaque livraison non documentée |
| D2 | Aucun inventaire de couplages. Personne ne peut lister ce qui dépend de quoi, dans quel sens, avec quelle criticité. | Temps perdu : reconstitution manuelle par lecture de code et de configuration avant chaque migration. Risque : un service tiers casse à la mise hors service d'un autre. | À chaque projet de migration ou de retrait — 4 à 8 par an |
| D3 | Décisions d'architecture évaporées. L'arbitrage a eu lieu en messagerie ou en réunion ; il ne reste ni contexte, ni alternatives écartées, ni conséquence assumée. | Temps perdu : la même discussion recommence six à douze mois plus tard, avec des personnes différentes. Risque : une décision est silencieusement annulée par méconnaissance. | Mensuel |
| D4 | Artefacts dessinés à la main puis périmés. Diagrammes C4, UML, BPMN, modèle de données : produits une fois, jamais régénérés. | Temps perdu : 1 à 3 jours par mise à jour de dossier d'architecture. Risque : une personne prend une décision sur un schéma faux, en toute bonne foi. | À chaque dossier d'architecture — 6 à 12 par an |
| D5 | Revue d'architecture sans preuve. Le comité juge sur une présentation, pas sur l'état vérifiable du système. | Décision retardée : approbation conditionnelle, retour au comité suivant. Risque : validation d'un dossier qui ne décrit pas la réalité. | À chaque comité — 2 fois par mois |
| D6 | Dette d'intelligibilité créée par la génération assistée. Du code apparaît sans décision traçable derrière lui. | Risque encouru : personne ne peut expliquer une partie croissante du système. Décision retardée : la direction technique freine l'usage des agents faute de garanties. | Continu, en croissance |
| D7 | Aucune vue transverse multi-équipes. Chaque équipe documente à sa façon, dans son outil, avec son vocabulaire. | Temps perdu : agrégation manuelle avant chaque comité. Risque : deux équipes réimplémentent la même capacité sans le savoir. | Mensuel, et à chaque planification trimestrielle |
| D8 | Base de données divergente. Le schéma réel en exploitation a dérivé de ce que décrivent le code et le modèle de données. | Risque encouru : dégradation de performance découverte en incident, index manquants, colonnes orphelines. Temps perdu : dépendance à l'équipe d'exploitation pour toute inspection. | 1 à 3 fois par trimestre |
| D9 | Impossibilité de démontrer la conformité d'un choix. Aucun élément opposable ne relie une décision, une règle interne et l'état déployé. | Risque encouru : constat d'audit, exigence contractuelle non démontrable auprès d'un client grand compte. Décision retardée : mise en attente d'un contrat. | 2 à 4 fois par an, avec un enjeu élevé à chaque fois |
| D10 | Hétérogénéité des pipelines. Chaque équipe a son fichier de pipeline, dérivé d'un autre, adapté à la main. | Risque : dérive silencieuse des contrôles — un pipeline sans analyse de sécurité, un autre sans porte de qualité. Temps perdu : audit manuel des pipelines avant chaque campagne de mise en conformité. | Semestriel, plus à chaque nouveau service |
| D11 | Agents IA sans périmètre. Des agents opèrent sur les dépôts et les environnements sans que l'architecture n'ait défini ce qu'ils ont le droit de toucher. | Risque encouru : action non désirée sur une ressource critique, sans journal opposable. Décision retardée : refus d'élargir l'usage des agents à l'échelle de l'organisation. | Permanent — c'est une posture, pas un incident |
#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 Divergence plan / réel | Rétro-ingénierie d'un dépôt existant vers sept familles d'artefacts, puis promotion 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 | L'architecture décrite provient du code déployé, pas d'un souvenir. La décision d'accepter reste humaine. |
| D1 Divergence plan / réel | Analyse d'écarts entre l'intention exprimée et la spécification en place | spec-service (4107) — POST /api/v1/projects/{id}/spec/analyze ; portail : /projects/{id}/analyze |
🟢 Livré | L'écart devient un objet affiché et discutable, pas une intuition à défendre en comité. |
| D2 Aucun inventaire de couplages | Graphe de dépendances au niveau du projet | dependency-graph-service (4117), monté sous /api/v1/dependency-graph/... ; portail : vue graph |
🟢 Livré | Les couplages réels remplacent les couplages supposés. |
| D2 Aucun inventaire de couplages | Traçabilité et analyse d'impact avant toute modification structurante | spec-service — GET /api/v1/spec-items/{id}/traceability, GET …/{id}/relationships, POST /api/v1/spec-items/{id}/impact ; portail : /projects/{id}/trace |
🟢 Livré | « Qu'est-ce qui casse si on retire ce service ? » a une réponse affichable en séance. |
| D3 Décisions évaporées | Enregistrements de décision d'architecture rattachés au projet, et baselines de spécification | spec-service — routeur /adrs ; GET /api/v1/projects/{id}/baselines |
🟢 Livré | La décision devient un objet daté et relié, pas un fil de messagerie. La baseline fige un état de référence. |
| D4 Artefacts périmés | 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é | Les diagrammes se régénèrent depuis la spécification au lieu d'être redessinés. |
| D4 Artefacts périmés | Documentation-comme-code exportable | Vue docs de l'espace de travail, gatée par la capacité docs:export |
🟢 Livré | Le dossier d'architecture se reconstruit ; il ne se recopie plus. |
| D5 Revue sans preuve | 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é | Le comité juge un état vérifiable, pas une présentation. |
| D5 Revue sans preuve | 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 d'arbitrage est dans le produit, pas dans une consigne de comité. |
| D6 Dette d'intelligibilité | Spécification exécutable : objets versionnés, typés, reliés, avec historique | spec-service — GET /api/v1/projects/{id}/spec-items, GET /api/v1/spec-items/{id} ; portail : /projects/{id}/spec, /projects/{id}/spec/{itemId} |
🟢 Livré | Chaque élément produit, y compris avec assistance générative, se rattache à une exigence versionnée. |
| D6 Dette d'intelligibilité | Métamodèle par projet : les types d'objets et les relations autorisées sont définis par le projet | spec-service — métamodèles ; validation à l'écriture |
🟢 Livré | L'architecture impose sa grammaire aux équipes plutôt que de la subir. |
| D7 Pas de vue transverse | Espace de travail projet à 11 vues canoniques, gatées par capacité, identiques d'une équipe à l'autre | Portail client — /projects/{id}/workspace?view=… ; vues spec, graph, boards, config, agentops, test, review, docs, artifacts, delivery, workforce |
🟢 Livré | Le même vocabulaire et les mêmes vues pour toutes les équipes. |
| D7 Pas de vue transverse | Agrégat d'exécutions inter-locataires au plan de contrôle | — | ⚪ Planifié — absent, écart affiché dans l'interface d'administration | À dire franchement : il n'existe pas de tableau consolidé inter-locataires aujourd'hui. |
| D8 Base divergente | Analyse réelle d'une base PostgreSQL en exploitation et conseil de conception | deploy-service (4121) — 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, ses statistiques et ses manques deviennent lisibles sans passer par l'exploitation. |
| D9 Conformité indémontrable | Journal d'audit à chaîne de hachage + vérification de chaîne + rapports de conformité Loi 25 sur période | audit-compliance-service (4113) — GET /api/v1/audit-compliance/audit/events, GET …/audit/verify-chain, GET|POST …/compliance/reports (genre loi25) |
🟢 Livré | La preuve est un artefact vérifiable, pas une affirmation. |
| D9 Conformité indémontrable | Baselines et enregistrements de décision reliés aux objets de spécification | spec-service — /adrs, GET /api/v1/projects/{id}/baselines |
🟢 Livré | On peut montrer l'état de référence sur lequel la décision a été prise. |
| D10 Pipelines hétérogènes | Génération de pipeline CI/CD pour quatre fournisseurs, avec commit réel dans le dépôt | deploy-service — 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 devient un gabarit gouverné, pas un héritage de copier-coller. |
| D10 Pipelines hétérogènes | Politiques d'exécution au plan de contrôle : une politique réseau doit commencer par deny-, une liste d'autorisation de sortie encadre le trafic sortant |
platform-config (4112) — /execution-policies, /guardrail-policies (+ POST /guardrail-policies/evaluate) ; administration : destination policies |
🟢 Livré | La règle transverse est appliquée par la plateforme, pas rappelée en réunion. |
| D11 Agents 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 : destination policies |
🟢 Livré | L'agent ne peut faire que ce que l'architecture a explicitement autorisé. |
| D11 Agents 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 = min(plafond du rôle, maximum du plan) ; portail : /roles ; administration : roles |
🟢 Livré — drapeau REGISTRY_VIRTUAL_ROLES_ENABLED, défaut False, activé dans aucun manifeste |
Le niveau d'autonomie devient une décision d'architecture explicite et révocable. Son activation reste une opération d'exploitation. |
| Attente non couverte | Pilotes nuage natifs — Azure Container Apps, Cloud Run, ECS, Amplify | — | ⚪ Planifié — seul le mécanisme générique « interface en ligne de commande nuage dans une tâche éphémère » est prouvé | Ne jamais présenter les pilotes natifs comme disponibles. |
| 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é ni prouvé | 🟡 En cours | Ne pas le présenter comme disponible. |
| Attente non couverte | Provisionnement automatique de fournisseur d'identité | — | 🔴 Bloqué — 403 Keycloak vérifiés : le compte de service n'a ni create-realm ni manage-identity-providers ; le déblocage est une action d'exploitation |
À annoncer avant la question, pas après. |
| Attente non couverte | Import depuis un outil de modélisation d'entreprise existant | — | ⚪ Planifié | Aucun connecteur de modélisation tierce n'existe aujourd'hui. |
#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 | Comité d'architecture, arbitrage sur deux dossiers | 3 h de réunion, 1 h de préparation | Le dossier décrit une intention, pas l'état déployé |
| Mardi | Cartographie manuelle d'un domaine avant une migration | 4 h de lecture de code et de configuration | Aucun inventaire de couplages ; reconstitution à la main |
| Mercredi | Mise à jour de diagrammes C4 et du modèle de données | 3 h | Redessin complet ; le schéma sera faux dans trois semaines |
| Jeudi | Revue de conception avec deux équipes, plus un point avec un prestataire | 3 h 30 | Trois vocabulaires différents, aucune vue commune |
| Vendredi | Réponse à une demande de conformité d'un client grand compte | 2 h 30 | Conviction argumentée, aucune preuve opposable |
#4.2 Après KySpectra
| Jour | Ce qui change | Heures déplacées [Hypothèse] |
Comment le mesurer |
|---|---|---|---|
| Lundi | Le comité ouvre la vue review : écarts, matrice de traçabilité, décision consignée en séance |
−45 min de préparation, décision consignée immédiatement | Nombre de revues portant une décision consignée — collaboration-service, /api/v1/reviews |
| Mardi | Cartographie obtenue par rétro-ingénierie et lue dans la vue graph ; impact vérifié par POST /api/v1/spec-items/{id}/impact |
−2 h 30 de reconstitution manuelle, +20 min de lecture de graphe | Nombre de jobs de rétro-ingénierie en statut ready ; nombre d'appels d'impact par semaine |
| Mercredi | Diagrammes régénérés depuis la spécification dans la vue artifacts ; export depuis la vue docs |
−2 h de redessin | Nombre de familles d'artefacts générées sur les sept disponibles ; exports réalisés depuis la capacité docs:export |
| Jeudi | Les trois équipes lisent les mêmes 11 vues canoniques ; le métamodèle du projet impose les types et relations | −1 h d'alignement de vocabulaire | Part des projets disposant d'un métamodèle actif ; consultations de la vue spec par équipe |
| Vendredi | La demande de conformité est servie par un rapport Loi 25 sur période et une vérification de chaîne d'audit | −1 h 30, et une réponse opposable au lieu d'une conviction | GET /api/v1/audit-compliance/audit/verify-chain ; GET|POST /api/v1/audit-compliance/compliance/reports (genre loi25) |
#4.3 Bilan hebdomadaire
| Poste | Avant | Après [Hypothèse] |
Écart [Hypothèse] |
|---|---|---|---|
| Cartographie et reconstitution manuelle | 4 h | 1 h 30 | −2 h 30 |
| Production et mise à jour d'artefacts | 3 h | 1 h | −2 h |
| Préparation de comité d'architecture | 1 h | 0 h 15 | −0 h 45 |
| Alignement inter-équipes | 3 h 30 | 2 h 30 | −1 h |
| Réponse aux demandes de conformité | 2 h 30 (amortie : 0 h 45/sem.) | 0 h 15/sem. | −0 h 30 |
| Total déplacé | — | — | ≈ 6 h 45 par semaine et par architecte [Hypothèse] |
Honnêteté sur le chiffre. Ces 6 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 cartographie et de production d'artefacts 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 Nour |
|---|---|
| Justesse | Iel arbitre sur l'architecture réelle, reconstruite depuis le code déployé, et non sur une carte plausible. |
| Opposabilité | Une décision d'architecture devient un objet daté, relié à des exigences et adossé à une baseline. |
| Durabilité | Les artefacts se régénèrent. La péremption cesse d'être fatale ; elle devient une commande à relancer. |
| Autorité sans friction | Le métamodèle par projet et les politiques d'exécution appliquent les règles transverses sans qu'iel ait à les rappeler en réunion. |
| Maîtrise des agents | L'agent devient un composant d'architecture avec un périmètre, un plafond d'autonomie et un journal — pas un acteur invisible. |
| Transmissibilité | Ce que l'organisation construit reste explicable devant la personne qui prendra la 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 cartographie récupéré
GAIN_CARTOGRAPHIE = A × H_carto × R × S
| Variable | Signification | Valeur de travail |
|---|---|---|
A |
Nombre d'architectes concernés | 2 [Hypothèse] |
H_carto |
Heures hebdomadaires de cartographie et de reconstitution manuelle | 4 h [Hypothèse], §4.3 |
R |
Part récupérée grâce à la rétro-ingénierie et au graphe de dépendances | 0,62 [Hypothèse], §4.3 |
S |
Semaines travaillées par an | 44 [Hypothèse] |
Application : 2 × 4 × 0,62 × 44 = 218,24 heures-personnes par an [Hypothèse].
#Formule 2 — Production d'artefacts d'architecture
GAIN_ARTEFACTS = N_dossiers × (H_manuel − H_regenere)
| Variable | Signification | Valeur de travail |
|---|---|---|
N_dossiers |
Dossiers d'architecture produits ou mis à jour par an | 9 [Hypothèse] |
H_manuel |
Heures de production manuelle d'un dossier — diagrammes, modèle de données, sécurité | 14 h [Hypothèse] |
H_regenere |
Heures avec artefacts régénérés depuis la spécification et export documentaire | 5 h [Hypothèse] |
Application : 9 × (14 − 5) = 81 heures-personnes par an [Hypothèse].
#Formule 3 — Coût évité de dérive d'architecture
VALEUR_DERIVE = F_derive × C_correction × P_detection_precoce
| Variable | Signification | Valeur de travail |
|---|---|---|
F_derive |
Nombre de dérives structurelles constatées par an — couplage non prévu, contrat contourné, service orphelin | [Gabarit : nombre de dérives par an, à extraire du registre d'incidents et des comptes rendus de comité du client] |
C_correction |
Coût moyen de correction d'une dérive — heures de conception, de développement et de coordination | [Gabarit : coût moyen de correction, à établir avec le client] |
P_detection_precoce |
Part détectable en amont grâce au graphe de dépendances et à l'analyse d'écarts | 0,35 [Hypothèse] |
Interdiction assumée. Tant que
F_deriveetC_correctionne sont pas fournis par le client, cette formule ne produit aucun chiffre publiable. On la présente vide, on la remplit ensemble.
#Formule 4 — Effort de réponse à une demande de conformité
GAIN_CONFORMITE = N_demandes × (H_dossier_manuel − H_rapport_genere)
| Variable | Signification | Valeur de travail |
|---|---|---|
N_demandes |
Demandes de conformité ou d'audit par an — client grand compte, auditeur interne, comité | 3 [Hypothèse] |
H_dossier_manuel |
Heures de constitution manuelle d'un dossier de preuve | 20 h [Hypothèse] |
H_rapport_genere |
Heures avec rapport de conformité sur période et vérification de chaîne d'audit | 6 h [Hypothèse] |
Application : 3 × (20 − 6) = 42 heures-personnes par an [Hypothèse].
#Formule 5 — 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 2 architectes et 12 personnes des équipes produit : 14 × 49 × 12 = 8 232 $ 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 — Nour, architecte
#Tâches à accomplir
| Type | Tâche | Intensité |
|---|---|---|
| Fonctionnelle | Connaître l'état réel du système avant d'arbitrer | Quotidienne |
| Fonctionnelle | Cartographier les couplages avant une migration ou un retrait | Trimestrielle |
| Fonctionnelle | Produire et maintenir un dossier d'architecture lisible | Mensuelle |
| Fonctionnelle | Faire appliquer des règles transverses par trois équipes et deux prestataires | Continue |
| Fonctionnelle | Répondre à une demande de conformité avec des éléments opposables | Trimestrielle |
| Fonctionnelle | Définir le périmètre d'action des agents IA dans les environnements | Continue, en croissance |
| Sociale | Être la personne dont l'arbitrage n'est pas contesté six mois plus tard | Continue |
| Sociale | Ne pas être celle qui a validé un dossier faux | Continue |
| Sociale | Laisser une architecture qu'un successeur peut reprendre | À l'échelle de l'année |
| Émotionnelle | Cesser d'arbitrer avec le sentiment de ne pas tout savoir | Continue |
| Émotionnelle | Assumer devant un comité que le système est explicable | Continue |
#Frustrations
| Frustration | Sévérité |
|---|---|
| Écart inconnu entre le plan et le déployé | Élevée |
| Couplages découverts en incident | Élevée |
| Décisions d'architecture introuvables | Élevée |
| Diagrammes périmés dès leur publication | Élevée |
| Comité qui juge une présentation, pas un état | Moyenne |
| Vocabulaires divergents entre équipes | Moyenne |
| Schéma de base de données opaque | Moyenne |
| Conformité argumentée sans preuve | Élevée |
| Pipelines dérivant sans contrôle | Moyenne |
| Agents IA hors de tout périmètre défini | Élevée |
#Attentes et gains recherchés
| Gain attendu | Nature |
|---|---|
| Obtenir une carte du système issue du code déployé | Justesse de décision |
| Voir ce qui dépend de quoi avant de décider | Réduction de risque |
| Conserver une décision avec son contexte et ses alternatives | Mémoire organisationnelle |
| Régénérer un dossier d'architecture au lieu de le redessiner | Gain de temps |
| Imposer une grammaire commune sans réunion supplémentaire | Autorité sans friction |
| Produire une preuve de conformité sur demande | Sérénité face à l'audit |
| Encadrer les agents IA comme des composants d'architecture | Maîtrise |
#7.2 Carte de valeur — KySpectra
#Produits et services proposés
| Élément | Surface réelle | Statut |
|---|---|---|
| Rétro-ingénierie vers sept familles d'artefacts | /projects/{id}/sources, /imports |
🟢 Livré — prouvé en production |
| Vue Artefacts — DDD, C4/TOGAF, UML, BPMN, modèle de données, sécurité, dépendances | Vue artifacts |
🟢 Livré |
| Graphe de traçabilité, d'impact et de dépendances | Vue graph, /projects/{id}/trace |
🟢 Livré |
| Documentation-comme-code exportable | Vue docs (capacité docs:export) |
🟢 Livré |
| Enregistrements de décision d'architecture et baselines | spec-service — /adrs, /baselines |
🟢 Livré |
| Métamodèle par projet | spec-service — métamodèles |
🟢 Livré |
| Analyse d'écarts | /projects/{id}/analyze |
🟢 Livré |
| Analyse de base PostgreSQL réelle | deploy-service — /deploy/db/analyze, /deploy/db/advise |
🟢 Livré |
| Politiques d'exécution et garde-fous | Administration — destination policies |
🟢 Livré |
| Journal d'audit chaîné et rapports Loi 25 | audit-compliance-service |
🟢 Livré |
| Registre central d'agents et plafond d'autonomie | /roles, administration — registry, agents |
🟢 Livré — drapeau REGISTRY_VIRTUAL_ROLES_ENABLED à False par défaut |
| Place de marché de capacités | — | 🟡 En cours |
| Pilotes nuage natifs | — | ⚪ Planifié |
| Application mobile | — | ⚪ Planifié |
| Provisionnement de fournisseur d'identité | — | 🔴 Bloqué |
#Solutions aux problèmes
| Frustration visée | Mécanisme produit qui la traite |
|---|---|
| Écart plan / déployé | Rétro-ingénierie depuis un dépôt réel, promotion de spécifications après décision humaine, puis POST /api/v1/projects/{id}/spec/analyze |
| Couplages inconnus | dependency-graph-service et POST /api/v1/spec-items/{id}/impact |
| Décisions introuvables | Routeur /adrs et baselines de spécification |
| Diagrammes périmés | artifact-service — artefacts projetés et régénérables depuis la spécification |
| Comité sans preuve | Vue review : écarts, matrice de traçabilité, séparation des devoirs appliquée par la machine à états |
| Vocabulaires divergents | Métamodèle par projet et 11 vues canoniques identiques pour toutes les équipes |
| Base opaque | POST /api/v1/deploy/db/analyze et POST /api/v1/deploy/db/advise |
| Conformité sans preuve | Journal chaîné, GET /audit/verify-chain, rapports Loi 25 sur période |
| Pipelines dérivants | Génération de pipeline avec commit réel, plus politiques d'exécution au plan de contrôle |
| Agents sans périmètre | Refus par défaut journalisé sous deny-by-default, plafond d'autonomie plafonné par le plan |
#Créateurs de gains
| Gain recherché | Créateur de gain KySpectra |
|---|---|
| Connaître le réel | Sept familles d'artefacts reconstruites à la demande depuis le dépôt |
| Décider sur des faits | Traçabilité bidirectionnelle et analyse d'impact avant modification |
| Conserver la mémoire | Enregistrements de décision datés, reliés, et baselines figées |
| Ne plus redessiner | Artefacts projetés depuis la spécification, export documentaire |
| Faire appliquer la règle | Politique réseau devant commencer par deny-, liste d'autorisation de sortie, garde-fous évaluables |
| Prouver | Chaîne de hachage vérifiable et rapport de conformité sur période |
| Encadrer l'IA | Registre central, refus par défaut, cap_autonomy = min(plafond du rôle, maximum du plan), dégradation vers N1 en cas d'incertitude |
| 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 |
|---|---|---|---|
| Connaître l'architecture réelle | Rétro-ingénierie + artefacts + spécification | Fort | Cœur de la proposition, prouvé en production |
| Inventorier les couplages | Graphe de dépendances + analyse d'impact | Fort | Livré et central dans l'interface |
| Conserver les décisions | /adrs + baselines |
Fort | Livré |
| Régénérer un dossier d'architecture | Vue artifacts + vue docs |
Fort | Livré ; l'export dépend de la capacité docs:export |
| Tenir un comité sur des preuves | Vue review + séparation des devoirs |
Fort | Livré, appliqué serveur et interface |
| Inspecter la base de données | /deploy/db/analyze et /deploy/db/advise |
Fort | Livré, prouvé en développement et en production |
| Encadrer les agents | Refus par défaut + registre + plafond d'autonomie | Moyen à fort | Livré ; le plafond exige l'activation d'un drapeau aujourd'hui à False |
| Vue consolidée inter-locataires | — | Faible | L'agrégat inter-locataires est absent, écart affiché dans l'interface d'administration |
| Gouverner un parc hors Kubernetes | Mécanisme générique par interface en ligne de commande nuage | Faible à moyen | Les pilotes nuage natifs sont ⚪ Planifiés |
| Importer un modèle depuis un outil de modélisation d'entreprise | — | Nul, assumé | Aucun connecteur tiers ; à dire dès le premier échange |
| 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 modélisation d'entreprise. » | Il modélise ce que vous décidez. KySpectra reconstruit ce qui existe : la rétro-ingénierie part de votre dépôt et produit sept familles d'artefacts, puis promeut des spécifications après décision humaine. Les deux répondent à des questions différentes. Si votre besoin est de dessiner une cible et rien d'autre, ce n'est pas pour vous. |
| O2 | « Vos artefacts générés vont être approximatifs. » | Ils sont générés depuis le code et la spécification, pas devinés. Et rien n'entre dans votre référentiel sans passage par la file de validation GET /api/v1/reverse-engineering/validation-tasks, dont la décision exige le rôle PUBLISHER. Vous restez l'autorité ; nous fournissons la matière première. |
| O3 | « Je n'ai pas de connecteur vers mon outil de modélisation existant. » | Exact, et il n'y en a pas. Aucun import depuis un outil de modélisation tiers n'existe aujourd'hui. Vous exportez de la documentation-comme-code depuis la vue docs et des artefacts depuis artifact-service. Si votre organisation impose un aller-retour bidirectionnel avec un outil tiers, ce n'est pas pour vous aujourd'hui. |
| O4 | « Nous avons soixante services et deux grappes. Votre outil suit-il ? » | Le produit est multi-locataire et scopé par projet. Il n'existe pas aujourd'hui d'agrégat d'exécutions inter-locataires au plan de contrôle : c'est un écart réel, affiché comme tel dans l'interface d'administration. Vous obtenez une vue par projet homogène sur les 11 vues canoniques, pas un tableau consolidé de tout le parc. À dire avant la démonstration, pas pendant. |
| O5 | « D'où sortent vos chiffres de gain ? » | 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 3 est délibérément laissée vide faute de vos données. 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, 34 agents au registre central en production. |
| O6 | « 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 en six étapes sur six, spécifications promues, produit servi sur un sous-domaine avec TLS. Nous préférons vous montrer cela qu'un logo. |
| O7 | « Vos agents vont opérer hors du périmètre que j'ai défini. » | 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. Au plan de contrôle, une politique réseau doit commencer par deny- et une liste d'autorisation de sortie encadre le trafic sortant. Enfin, cap_autonomy = min(plafond du rôle, maximum du plan), et une valeur inconnue dégrade vers N1. |
| O8 | « Le plafond d'autonomie dépend d'un drapeau désactivé. » | Oui. REGISTRY_VIRTUAL_ROLES_ENABLED vaut False par défaut et n'est activé dans aucun manifeste du dépôt ; tant qu'un exploitant ne l'active pas, GET /api/v1/entitlements répond 404. Le mécanisme est livré et testé, son activation est une opération d'exploitation. Nous ne prétendons pas qu'il est actif partout. |
| O9 | « Notre parc est sur un nuage public, 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 en développement. Les pilotes natifs Azure Container Apps, Cloud Run, ECS et Amplify sont ⚪ Planifiés. Si votre besoin est un pilote natif dès maintenant, ce n'est pas pour vous aujourd'hui. |
| O10 | « Nous voulons brancher notre fournisseur d'identité automatiquement. » | Ce n'est pas possible en l'état. Le provisionnement automatique de fournisseur d'identité est 🔴 Bloqué : des 403 Keycloak ont été vérifiés, le compte de service n'a ni create-realm ni manage-identity-providers. Le déblocage est une action d'exploitation, pas un développement. Le raccordement se fait manuellement en attendant. |
| O11 | « Une couche de gouvernance de plus va ralentir mes équipes. » | La gouvernance est configurable et par défaut minimale : DEPLOY_REQUIRE_APPROVAL vaut False, DEPLOY_LIVE vaut False. Vous activez ce que votre contexte exige. En revanche, le refus par défaut du moteur de politique et la séparation des devoirs ne sont pas désactivables — c'est ce qui rend l'usage d'agents défendable devant un comité. |
| O12 | « Combien de temps avant que ce soit utile pour moi ? » | La rétro-ingénierie d'un dépôt donne des artefacts dès le premier job — 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 de validation. Comptez une à deux semaines de va-et-vient pour un dépôt de taille moyenne, et davantage pour une soixantaine de services traités par vagues. [Gabarit : durée médiane de promotion sur un parc réel de plusieurs dizaines de services, à mesurer en Phase 1] |
| O13 | « 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. |
| O14 | « Votre place de marché de capacités nous intéresse. » | Elle est 🟡 En cours : le code existe et il est testé, elle n'a jamais été déployée ni prouvée. Nous ne la comptons pas dans votre décision d'achat, et vous ne devriez pas non plus. |
#9. Offre recommandée
#9.1 Le plan
Palier Équipe — 49,00 $ CAD par mois [Hypothèse], avec montée vers Entreprise dès trois équipes ou une contrainte réglementaire.
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). Le palier Entreprise est sur devis.
#9.2 Pourquoi ce palier pour cette persona
| Raison | Détail |
|---|---|
| Plafond d'autonomie N2 | Suffisant pour laisser des agents produire des artefacts et analyser un dépôt sous supervision, sans ouvrir le niveau N3 réservé aux organisations réglementées |
| Compétences, outils et rôles | 25 compétences, 10 outils, 10 rôles — le palier Découverte n'en autorise aucun, ce qui interdit toute règle d'architecture personnalisée |
| 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 un dépôt et traiter un parc |
| Bascule vers Entreprise | Dès trois équipes simultanées ou une contrainte réglementaire sur le journal d'audit et les rapports Loi 25, le palier Entreprise devient le bon choix : plafond N3, 1 000 compétences, 500 outils, 200 rôles, 1 000 000 d'appels par jour, recherche en ligne activée |
#9.3 Ce qui est inclus
| Inclus | Détail |
|---|---|
| Espace de travail projet complet | 11 vues canoniques, gatées par capacité, dont artifacts, graph, docs, spec, review |
| 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, métamodèle par projet |
| Artefacts d'architecture | DDD, C4/TOGAF, UML, BPMN, modèle de données, artefacts de sécurité, dépendances |
| Analyse d'écarts | POST /api/v1/projects/{id}/spec/analyze |
| Analyse de base de données | POST /api/v1/deploy/db/analyze, POST /api/v1/deploy/db/advise |
| Agents gouvernés | Registre central, refus par défaut, séparation des devoirs, journal d'audit chaîné, interruption de run |
| Politiques | Garde-fous évaluables, politiques d'exécution avec préfixe deny- et liste d'autorisation de sortie |
| Livraison | Génération et commit de pipeline CI/CD, déploiement gouverné Kubernetes, retour arrière, sous-domaine avec TLS |
| 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 |
| 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é | 🔴 Bloqué — droits Keycloak manquants, action d'exploitation requise |
| Agrégat d'exécutions inter-locataires | ⚪ Planifié — écart affiché dans l'interface d'administration |
| Import depuis un outil de modélisation tiers | ⚪ Planifié — aucun connecteur |
#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, d'un outil ou d'un rôle personnalisé pour appliquer une règle d'architecture | 25 compétences, 10 outils, 10 rôles, 5 000 appels/jour, plafond N2 |
| Équipe → Entreprise | Trois équipes travaillent simultanément sur le parc ; ou une contrainte réglementaire impose le journal d'audit vérifiable et les rapports Loi 25 ; ou les agents doivent effectuer de la recherche en ligne | 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 |
|---|---|---|
| Dépôts réels importés et rétro-ingéniérés | ≥ 3 dépôts | GET /api/v1/reverse-engineering/jobs — jobs en statut ready |
| Familles d'artefacts générées | ≥ 5 des 7 | Vue artifacts de l'espace de travail ; /api/v1/artifacts |
| Objets de spécification promus après décision humaine | ≥ 40 | GET /api/v1/reverse-engineering/validation-tasks en statut approved |
| Graphe de dépendances consulté sur au moins un domaine | 1 domaine | Vue graph ; dependency-graph-service (4117) |
| Premier enregistrement de décision d'architecture consigné | 1 | spec-service — routeur /adrs |
#10.2 À 60 jours
| Indicateur | Cible [Hypothèse] |
Source de mesure réelle |
|---|---|---|
| Analyses d'impact lancées avant décision structurante | ≥ 12 par mois | POST /api/v1/spec-items/{id}/impact |
| Analyses d'écarts exécutées sur les projets actifs | ≥ 1 par projet et par mois | POST /api/v1/projects/{id}/spec/analyze |
| Baselines de spécification figées | ≥ 2 | GET /api/v1/projects/{id}/baselines |
| Bases PostgreSQL réelles analysées | ≥ 2 | POST /api/v1/deploy/db/analyze, POST /api/v1/deploy/db/advise |
| Revues d'architecture portant une décision consignée | ≥ 70 % des dossiers passés en comité | collaboration-service — /api/v1/reviews |
Refus deny-by-default examinés et arbitrés |
100 % | Table app_policy_check ; destination policies du plan de contrôle |
#10.3 À 90 jours
| Indicateur | Cible [Hypothèse] |
Source de mesure réelle |
|---|---|---|
| Part du parc couverte par un projet KySpectra avec artefacts générés | ≥ 50 % des services | GET /api/v1/projects/{id}/spec-items par projet, rapporté à l'inventaire de services du client |
| Part des dossiers d'architecture régénérés au lieu d'être redessinés | ≥ 80 % | Exports de la vue docs (capacité docs:export) ; /api/v1/documentation |
| Politiques d'exécution appliquées à l'ensemble des projets | 100 % des projets actifs | platform-config (4112) — /execution-policies, destination policies |
| Vérification de chaîne d'audit exécutée sans rupture | 100 % de succès | GET /api/v1/audit-compliance/audit/verify-chain |
| Rapport de conformité Loi 25 produit sur période | ≥ 1 | GET|POST /api/v1/audit-compliance/compliance/reports (genre loi25) |
| Délai médian « question d'architecture posée → réponse documentée » | −30 % par rapport au point de départ [Hypothèse] |
[Gabarit : mesure de référence à établir en semaine 1 du pilote, à partir des comptes rendus de comité d'architecture] |
#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 architecture cible est écrite. Votre architecture réelle, non. » Importez un dépôt et obtenez sept familles d'artefacts reconstruites depuis le code déployé, avec décision humaine avant promotion. |
Publication technique longue sur un carnet d'architecture ou une revue d'ingénierie logicielle | Toucher la douleur D1 sans promettre de gain chiffré |
| A2 | « Qu'est-ce qui dépend de ce service ? » Un graphe de dépendances et une analyse d'impact avant chaque migration ou retrait — pas un tableur maintenu à la main. |
Démonstration courte en vidéo, 90 secondes, sur réseau professionnel | Montrer la vue graph et l'endpoint d'impact en action |
| A3 | « Un diagramme se redessine. Un artefact se régénère. » DDD, C4/TOGAF, UML, BPMN, modèle de données, sécurité, dépendances : projetés depuis la spécification, pas dessinés une fois pour toutes. |
Article de fond, section « Documentation-comme-code », et atelier en communauté d'architectes | Adresser D4 avec un mécanisme vérifiable |
| A4 | « Vos décisions d'architecture survivent-elles à six mois de messagerie ? » Enregistrements de décision datés et reliés, baselines de spécification figées, historique consultable. |
Courriel de séquence d'activation, message 2 sur 5 ; intervention en comité d'architecture d'entreprise | Adresser D3 avec un bénéfice organisationnel durable |
| 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. Une politique réseau doit commencer par deny-. 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é, artefacts reconstruits, spécifications promues, décisions consignées, déploiement approuvé et tracé. 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'architectes |
#12. Ce que nous refusons de dire à cette persona
| Formulation interdite | Pourquoi |
|---|---|
| « Votre architecture est documentée automatiquement » | La promotion d'une spécification exige une décision humaine avec le rôle PUBLISHER |
| « Conformité automatique » | Non revendiqué (brief §7) |
| « Le meilleur outil d'architecture d'entreprise » | Superlatif creux (brief §12) |
| « Nos clients constatent… » | Aucun témoignage n'existe (brief §15) |
| « Déployez sur n'importe quel nuage » | Les pilotes nuage natifs sont ⚪ Planifiés |
| « Notre application mobile » | Aucun code mobile n'existe dans le dépôt |
| « Vue consolidée de tout votre parc » | L'agrégat d'exécutions inter-locataires est absent, écart affiché dans l'interface |
| « Branchez votre fournisseur d'identité en un clic » | Le provisionnement automatique est 🔴 Bloqué |
| « Portail business » | Il n'existe pas de troisième portail |
| « Remplacez vos développeurs » | Interdit explicitement (brief §2) |
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.