#0. Comment lire ce document
Ce document décrit trente workflows de bout en bout de la plateforme KySpectra. Chacun est décrit par son déclencheur, ses acteurs, les rôles RBAC exigés, ses préconditions, un diagramme, un déroulé numéroté dont chaque étape cite une route, un endpoint ou un service réel, les portes de gouvernance traversées, les cas d'erreur avec leur code HTTP réel, les postconditions et un statut honnête.
#0.1 Conventions
| Convention | Règle appliquée |
|---|---|
| Chemins d'API | Chemin client, tel que le portail l'appelle, c'est-à-dire après la passerelle. La passerelle est la source de vérité du routage : backend/api-gateway/src/core/registry.py. |
| Services scopés | Un service de vague 2 est atteint sous /api/v1/<slug>/… et la passerelle réécrit le chemin vers la route native de l'amont. |
| Statut | 🟢 Livré · 🟡 En cours · ⚪ Planifié · 🔴 Bloqué. Un statut porte toujours l'environnement où la capacité est prouvée. |
| Rôles | Hiérarchie VIEWER 0 < EDITOR 1 < PUBLISHER 2 < ADMIN 3 < OWNER 4. Un rang supérieur satisfait toujours l'exigence d'un rang inférieur. |
| Isolation | Un identifiant de locataire en désaccord avec la revendication du jeton renvoie 404, jamais 403. |
#0.2 Nuances vérifiées qui s'appliquent à plusieurs workflows
| Nuance | Réalité vérifiée au 2026-08-17 |
|---|---|
| Rétro-ingénierie | L'analyse profonde du code source est Python uniquement. JavaScript, TypeScript, Go, Java, Ruby et C# sont détectés puis rangés en unsupported — jamais analysés de façon fabriquée. |
| Diagrammes UML | 14 types acceptés, mais 5 générateurs spécialisés seulement : classe, machine à états, séquence, composant, déploiement. Les 9 autres retombent sur un flowchart générique. |
| Surfaces | Il n'existe pas de portail « business » distinct : « business » est une persona à l'intérieur du portail client. Aucune application mobile n'existe dans le dépôt. |
| Interrupteurs de livraison | DEPLOY_LIVE et GOLIVE_ENABLED valent false par défaut dans le code. Sans eux, la plateforme répond 501 Not Implemented explicite — elle ne simule jamais un déploiement. |
| Rôles virtuels | REGISTRY_VIRTUAL_ROLES_ENABLED vaut false par défaut et n'est positionné dans aucun manifeste : les routes concernées répondent 404 tant qu'il n'est pas activé. |
#0.3 Carte des trente workflows
Aucun diagramme à afficher
Diagramme 1 — flowchart
#0.4 Index
| ID | Nom | Maillon | Statut |
|---|---|---|---|
| WF-01 | Découverte publique et inscription | Entrée | 🟢 Livré |
| WF-02 | Création d'organisation et invitation d'équipe | Entrée | 🟢 Livré |
| WF-03 | Création d'un projet | Entrée | 🟢 Livré |
| WF-04 | Import d'un dépôt public et rétro-ingénierie complète | 1 · Comprendre | 🟢 Livré, prouvé en production |
| WF-05 | Promotion automatique de spécifications | 1 · Comprendre | 🟢 Livré |
| WF-06 | Rédaction de spécification assistée par IA | 2 · Spécifier | 🟢 Livré |
| WF-07 | Validation EARS | 2 · Spécifier | 🟢 Livré |
| WF-08 | Analyse d'impact et traçabilité | 2 · Spécifier | 🟢 Livré |
| WF-09 | Génération de PRD et d'artefacts UML | 3 · Concevoir | 🟢 Livré |
| WF-10 | Modélisation DDD et métamodèle par projet | 3 · Concevoir | 🟢 Livré |
| WF-11 | Cycle de revue et approbation | 3 · Concevoir | 🟢 Livré |
| WF-12 | Recrutement de personnel virtuel et affectation de tâche | 4 · Fabriquer | 🟢 Livré, phase 1 |
| WF-13 | Exécution d'agent avec approbation humaine | 4 · Fabriquer | 🟢 Livré |
| WF-14 | Génération de tests depuis les critères d'acceptation | 5 · Vérifier | 🟢 Livré |
| WF-15 | Exécution de tests navigateur réels | 5 · Vérifier | 🟢 Livré, développement |
| WF-16 | Analyse d'une base de données en exploitation | 5 · Vérifier | 🟢 Livré, développement et production |
| WF-17 | Génération de pipeline CI/CD et commit dans le dépôt | 6 · Livrer | 🟢 Livré, développement |
| WF-18 | Construction et publication d'image | 6 · Livrer | 🟢 Livré, développement |
| WF-19 | Déploiement gouverné avec approbation et retour arrière | 6 · Livrer | 🟢 Livré, production |
| WF-20 | Mise en ligne sur sous-domaine avec TLS | 6 · Livrer | 🟢 Livré, production |
| WF-21 | Collecte de retours et vote | Boucle | 🟢 Livré |
| WF-22 | Publication de feuille de route et journal des changements | Boucle | 🟢 Livré |
| WF-23 | Traitement d'un défaut jusqu'à la spécification d'origine | Boucle | 🟢 Livré |
| WF-24 | Dépassement de budget et plafonnement | Plan de contrôle | 🟢 Livré |
| WF-25 | Montée en gamme de plan | Plan de contrôle | 🟡 En cours |
| WF-26 | Enregistrement d'un outil MCP et permission d'appel | Plan de contrôle | 🟢 Livré |
| WF-27 | Publication d'une compétence globale | Plan de contrôle | 🟢 Livré |
| WF-28 | Provisionnement du locataire de démonstration | Plan de contrôle | 🟢 Livré |
| WF-29 | Production d'un rapport de conformité Loi 25 | Plan de contrôle | 🟢 Livré |
| WF-30 | Dépôt d'un secret au coffre par projet | Plan de contrôle | 🟢 Livré, développement et production |
| WF-31 | Publication d'un front statique | 6 · Livrer | 🟢 Livré, développement |
| WF-32 | Cycle spécification-première complet | 2 · Spécifier | 🟢 Livré |
#WF-01 · Découverte publique et inscription
| Élément | Valeur |
|---|---|
| Déclencheur | Une personne arrive sur https://spectra.kyrieva.com ou sur la documentation https://kyspectradoc.kyrieva.com. |
| Acteurs | Visiteur anonyme · Keycloak · user-service |
| Rôles RBAC requis | Aucun pour la lecture publique. À l'issue de l'inscription, le compte reçoit au minimum VIEWER. |
| Préconditions | Le realm Keycloak est provisionné, le client public kyspectra-client-portal existe avec PKCE S256 et l'URL de retour <origine>/auth/callback. |
| Surfaces | Portail client, routes /, /auth/callback · catalogue de plans public |
| Statut honnête | 🟢 Livré sur les trois environnements. Écart connu : le catalogue de plans expose encore trois jeux de données de démarrage incompatibles, dont un porte du vocabulaire hérité d'un autre domaine — nettoyage préalable bloquant au lancement. |
Aucun diagramme à afficher
Diagramme 2 — flowchart
Déroulé
| # | Étape | Écran ou endpoint réel | Donnée produite | Décision ou porte |
|---|---|---|---|---|
| 1 | Le visiteur consulte la documentation publique | kyspectradoc.kyrieva.com |
— | — |
| 2 | Il ouvre le portail client | Route / du portail client |
— | Le garde d'authentification exempte les routes /public/* |
| 3 | Le portail lit le catalogue commercial | GET /api/v1/billing/plans — lecture publique, sans jeton |
Liste de paliers, prix en cents, devise CAD |
Aucune |
| 4 | Le visiteur démarre l'authentification | Redirection vers Keycloak, flux Authorization Code + PKCE S256 | Code d'autorisation | Politique de mot de passe du realm, protection contre la force brute |
| 5 | Retour applicatif | Route /auth/callback du portail client |
Jeton d'accès et jeton de rafraîchissement | Le portail ne détient aucun secret client |
| 6 | Résolution du locataire | En-tête X-Tenant-ID, sinon revendication tenant_id du jeton, sinon paramètre tenant_id |
Contexte de locataire | Désaccord ⇒ 404 |
| 7 | Atterrissage | Route / — Tableau de bord |
Vue personnalisée | Capacités dérivées du rôle |
Portes de gouvernance : limite de débit 5/minute sur POST /api/v1/auth/* à la passerelle · limite générale 300/minute par utilisateur ou par adresse · politique de mot de passe du realm.
Cas d'erreur
| Cas | Code HTTP réel | Comportement |
|---|---|---|
| Trop de tentatives d'authentification | 429 |
La passerelle refuse, la fenêtre est fixe d'une minute. |
| Jeton absent sur une route protégée | 401 |
Le portail redirige vers Keycloak, sauf sur /public/*. |
| Locataire de l'en-tête en désaccord avec le jeton | 404 |
Masquage d'existence, jamais 403. |
Postconditions : une identité Keycloak existe, un utilisateur applicatif est résolu, un locataire est attaché au contexte de session.
#WF-02 · Création d'organisation et invitation d'équipe
| Élément | Valeur |
|---|---|
| Déclencheur | Le premier utilisateur d'un locataire veut constituer son équipe. |
| Acteurs | Propriétaire du locataire · membres invités · user-service · Keycloak |
| Rôles RBAC requis | ADMIN ou OWNER pour inviter et pour gérer les rôles. VIEWER suffit pour lire l'équipe. |
| Préconditions | WF-01 accompli. Le proxy d'administration Keycloak est configuré, sans quoi les opérations d'annuaire répondent un 501 typé et assumé. |
| Surfaces | Portail client /team, /organization/capabilities · portail d'administration /tenants, /users |
| Statut honnête | 🟢 Livré. Écart connu : la suspension de locataire n'est pas exposée par le service utilisateurs, le portail d'administration l'affiche explicitement comme un écart. |
Aucun diagramme à afficher
Diagramme 3 — flowchart
Déroulé
| # | Étape | Écran ou endpoint réel | Donnée produite | Décision ou porte |
|---|---|---|---|---|
| 1 | Créer l'organisation | POST /api/v1/organizations |
Ligne app_organizations, slug unique |
Unicité du slug vérifiée par GET /api/v1/organizations/check-slug/{slug} |
| 2 | Inviter un membre | POST /api/v1/users/invite |
Ligne app_org_invitations, jeton à durée de vie 7 jours |
Garde manage:users |
| 3 | Le destinataire résout son invitation | GET /api/v1/invitations/{token} — route publique |
Métadonnées d'invitation | Une invitation expirée ou inconnue renvoie 404, sans divulgation |
| 4 | Acceptation | POST /api/v1/invitations/{token}/accept — route publique |
Utilisateur Keycloak + utilisateur applicatif + appartenance active | Transaction unique |
| 5 | Attribution du rang | PUT /api/v1/users/{user_id}/roles |
Assignation dans app_user_role_assignments |
Séparation des devoirs appliquée sur la mise à jour |
| 6 | Vérification des capacités | GET /api/v1/permissions/effective |
Ensemble de capacités effectives | Moteur en refus par défaut |
| 7 | Dérogation ponctuelle si nécessaire | POST /api/v1/permissions/overrides |
Ligne app_permission_overrides avec priorité et motif |
Motif obligatoire, écriture auditée |
| 8 | Suivi côté administration | Portail d'administration /users |
Matrice rôle vers capacité | Capacités users:manage et rbac:edit réservées au rôle plateforme administrateur |
Portes de gouvernance : manage:users exigé pour toute invitation · toute évaluation de permission écrit une ligne dans app_permission_audit_log · l'échec par défaut est le refus.
Cas d'erreur
| Cas | Code HTTP réel | Comportement |
|---|---|---|
| Invitation expirée ou déjà consommée | 404 |
Aucune fuite : la plateforme ne dit pas si le jeton a existé. |
| Proxy d'administration Keycloak non configuré | 501 |
Message typé « non raccordé dans cet environnement », reconnu par le portail d'administration. |
| Rôle insuffisant | 403 |
Le rôle est présent mais ne satisfait pas l'exigence. |
| Aucun rôle porté | 401 |
Le contexte d'authentification est vide. |
Postconditions : l'organisation existe, les membres sont actifs, chaque membre porte un rang RBAC explicite et vérifiable.
#WF-03 · Création d'un projet
| Élément | Valeur |
|---|---|
| Déclencheur | Une équipe veut ouvrir un espace de travail pour un produit. |
| Acteurs | Product Owner ou Architecte · spec-service |
| Rôles RBAC requis | EDITOR pour créer, VIEWER pour lire. |
| Préconditions | WF-02 accompli. Le service de spécification possède l'entité projet nue. |
| Surfaces | Portail client /projects, /projects/[projectId], /projects/[projectId]/workspace |
| Statut honnête | 🟢 Livré sur les trois environnements. |
Aucun diagramme à afficher
Diagramme 4 — flowchart
Déroulé
| # | Étape | Écran ou endpoint réel | Donnée produite | Décision ou porte |
|---|---|---|---|---|
| 1 | Ouvrir la liste | Route /projects · GET /api/v1/projects |
Liste scopée par locataire | Isolation stricte |
| 2 | Créer le projet | POST /api/v1/projects |
Identifiant canonique de projet | Garde EDITOR |
| 3 | Ouvrir l'aperçu | Route /projects/[projectId] |
Fiche projet | L'identifiant réel est lu côté client, le portail étant exporté en statique |
| 4 | Amorcer l'espace de travail | GET /api/v1/projects/{id}/app-sdd/bootstrap |
Jeu initial de vues et de compteurs | — |
| 5 | Naviguer entre les vues | Route /projects/[projectId]/workspace?view=<vue>&item=<objet> |
État partageable par lien profond | Chaque vue déclare la capacité qui la garde |
| 6 | Persistance du confort | Miroir localStorage par projet |
Dernière vue ouverte | N'amorce que le premier atterrissage |
Portes de gouvernance : chacune des onze vues canoniques déclare sa capacité gatante — par exemple spec:read, agentops:read, docs:export, workforce:read. Une valeur de vue invalide dans l'URL est neutralisée vers la vue spec.
Cas d'erreur
| Cas | Code HTTP réel | Comportement |
|---|---|---|
| Projet d'un autre locataire | 404 |
Masquage d'existence. |
| Capacité manquante pour une vue | — | La vue n'apparaît pas dans le sélecteur ; l'appel serveur reste autoritatif. |
Rôle VIEWER tentant une création |
403 |
Refus explicite. |
Postconditions : un projet existe, son espace de travail à onze vues est accessible et chaque vue est adressable par lien profond.
#WF-04 · Import d'un dépôt public et rétro-ingénierie complète
| Élément | Valeur |
|---|---|
| Déclencheur | Une équipe reprend un système existant dont la documentation manque. |
| Acteurs | Architecte ou développeur · reverse-engineering-service · spec-service |
| Rôles RBAC requis | EDITOR pour créer un travail d'analyse et déclarer une source · ADMIN pour supprimer une source · PUBLISHER pour décider d'une validation humaine. |
| Préconditions | Un projet existe. En production, une politique réseau dédiée autorise la sortie sur le port 443 depuis le pod de rétro-ingénierie — sans elle, le clonage est bloqué par le refus par défaut. |
| Surfaces | Portail client /projects/[projectId]/sources · vue Artefacts de l'espace de travail |
| Statut honnête | 🟢 Livré et prouvé en production sur la moitié amont du parcours. Nuance décisive : l'analyse profonde est Python uniquement. |
Aucun diagramme à afficher
Diagramme 5 — flowchart
Déroulé
| # | Étape | Écran ou endpoint réel | Donnée produite | Décision ou porte |
|---|---|---|---|---|
| 1 | Déclarer une source durable | POST /api/v1/reverse-engineering/projects/{project_id}/sources |
Ligne app_project_source |
Un secret en clair est rejeté en 422 ; seul un chemin de coffre circule |
| 2 | Créer le travail d'analyse | POST /api/v1/reverse-engineering/jobs |
Travail en état queued + ses références de source |
Un mode reverse sans source est rejeté en 422 |
| 3 | Planification | Tâche de fond run_job_pipeline, réponse 201 immédiate |
— | La session ouvre son propre contexte d'isolation par locataire |
| 4 | Clonage | git clone --depth 1 --single-branch, jeton injecté par en-tête HTTP éphémère |
Arbre temporaire supprimé en fin de traitement | Le jeton n'est jamais écrit dans l'URL ni dans la configuration du dépôt |
| 5 | Ingestion | Dispatch par système : git, db_schema, openapi, graphql, iac, docs, git_history |
Faits objectifs avec locateur fichier:ligne |
grpc, ci et runtime sont acceptés au vocabulaire mais sans analyseur ⇒ 422 |
| 6 | Analyse statique | Analyseur Python fondé sur l'arbre syntaxique de la bibliothèque standard | Modules, classes, fonctions, complexité cyclomatique, endpoints, entités, événements, code mort | Les autres langages sont signalés unsupported, jamais devinés |
| 7 | Inférence | Moteur sémantique, seuil de confiance 0.5 |
Candidats FR, BR, ENT, NFR, DEC avec preuve obligatoire |
Un candidat sans preuve est structurellement refusé |
| 8 | Ouverture de la porte humaine | Ligne app_validation_task en pending |
File de validation | GET /api/v1/reverse-engineering/validation-tasks |
| 9 | Émission d'artefacts | GET /api/v1/reverse-engineering/jobs/{id}/emit ou …/emit/{artefact} |
Les sept familles d'artefacts | Lecture seule, aucune promotion ; artefact inconnu ⇒ 422 |
| 10 | Lectures dérivées | …/ddd, …/architecture, …/security, …/modernization |
Contextes bornés, vues C4 et TOGAF, surface d'attaque, plan de modernisation | — |
Portes de gouvernance : politique réseau de sortie dédiée en production · secret par référence de coffre uniquement · sanitisation double des messages d'erreur, à l'écriture et à la lecture · toute promotion passe par la porte humaine, garantie jusque dans un déclencheur de base de données.
Cas d'erreur
| Cas | Code HTTP réel | Comportement |
|---|---|---|
| Dépôt distant injoignable ou refusé | 502 reverse/remote-clone-failed |
Message d'erreur caviardé du jeton et tronqué à 200 caractères. |
| Identifiants déclarés mais introuvables au coffre | 502 reverse/git-credentials-not-configured |
Refus explicite, jamais de tentative anonyme silencieuse. |
| Système de source non pris en charge | 422 reverse/source-system-unsupported |
Le vocabulaire est plus large que les analyseurs, et le dit. |
| Source distante autre que git | 422 reverse/remote-source-unfetched |
— |
| Chemin de coffre contenant une adresse | 422 reverse/cred-not-a-path |
Un secret en clair est refusé. |
| Artefact d'émission inconnu | 422 reverse/emit-artifact-unknown |
Liste des sept valeurs admises. |
Postconditions : le travail est en état ready, ses faits sont persistés, sept artefacts sont reconstructibles à la demande, une file de validation humaine est ouverte.
Limite assumée : le clonage s'exécute sans délai maximal et sans plafond de taille de dépôt ; les seuls garde-fous sont la profondeur 1, la liste de répertoires ignorés et la limite de 200 commits d'historique.
#WF-05 · Promotion automatique de spécifications
| Élément | Valeur |
|---|---|
| Déclencheur | Un travail de rétro-ingénierie atteint l'état ready. |
| Acteurs | Le pipeline lui-même · spec-service · réviseur humain pour le reste de la file |
| Rôles RBAC requis | Aucun pour le chemin automatique — il est attribué à un réviseur sentinelle. PUBLISHER pour le chemin humain. |
| Préconditions | AUTO_PROMOTE_ENABLED vaut true par défaut, seuil de confiance 0.7. SPEC_SERVICE_URL vaut None par défaut et n'est pas positionné dans le manifeste de développement : sans lui, la promotion est un no-op honnête. |
| Surfaces | Vue Spéc de l'espace de travail · file de validation |
| Statut honnête | 🟢 Livré. La promotion réelle exige que l'adresse du service de spécification soit configurée dans l'environnement. |
Aucun diagramme à afficher
Diagramme 6 — flowchart
Déroulé
| # | Étape | Écran ou endpoint réel | Donnée produite | Décision ou porte |
|---|---|---|---|---|
| 1 | Fin de l'analyse | Le travail est ready et commité |
Résumé du travail | Une panne de promotion ne peut jamais annuler un travail déjà réussi |
| 2 | Vérification des drapeaux | AUTO_PROMOTE_ENABLED, AUTO_PROMOTE_MIN_CONFIDENCE, SPEC_SERVICE_URL |
Note explicite si désactivé | Trois no-op honnêtes possibles |
| 3 | Sélection | Candidats non promus, confiance ≥ 0.7, tâche de validation pending |
Liste triée par confiance décroissante | Le reste demeure dans la file humaine |
| 4 | Approbation machine | Même fonction de décision qu'un humain, réviseur sentinelle fixe et note « auto-promoted by reverse pipeline » | Tâche passée à approved, attribuable et auditable |
Le déclencheur de base de données interdit toute promotion sans tâche approuvée |
| 5 | Création de l'objet | POST chez spec-service via son client interne |
Objet de spécification en statut draft, provenance reverse:<mode> |
Le type de candidat est traduit par une table de correspondance ; un type non mappé ⇒ 422 |
| 6 | Bilan | Champs auto_promoted et auto_promote_deferred du résumé |
Compteurs | Le statut du travail reste inchangé |
| 7 | Chemin humain | POST /api/v1/reverse-engineering/validation-tasks/{task_id}/decision |
Décision approve ou reject |
Garde PUBLISHER ; une panne du service de spécification annule la transaction et laisse la tâche rejouable |
Portes de gouvernance : seuil de confiance explicite · réviseur sentinelle distinct d'un humain · déclencheur de base de données comme filet de sécurité · une décision par tâche, la seconde renvoie un conflit.
Cas d'erreur
| Cas | Code HTTP réel | Comportement |
|---|---|---|
| Tâche déjà décidée | 409 |
Rejeu impossible, décision unique. |
| Type de candidat non traduisible | 422 reverse/candidate-type-unmapped |
Aucun objet de spécification n'est créé. |
| Service de spécification indisponible sur le chemin humain | Problème typé, transaction annulée | La tâche reste pending, donc rejouable ; jamais d'approbation orpheline. |
Postconditions : des objets de spécification versionnés existent, chacun porte sa provenance de rétro-ingénierie et son statut draft.
#WF-06 · Rédaction de spécification assistée par IA
| Élément | Valeur |
|---|---|
| Déclencheur | Un analyste décrit une intention en langage naturel. |
| Acteurs | Analyste d'affaires ou Product Owner · copilot-service · passerelle LLM |
| Rôles RBAC requis | EDITOR pour proposer et enregistrer les objets. |
| Préconditions | Un projet existe. Une configuration de modèle est active dans le plan de contrôle. |
| Surfaces | Portail client /projects/[projectId]/specify · page Activité des agents du projet |
| Statut honnête | 🟢 Livré sur les trois environnements. Les propositions atterrissent en objets proposés, jamais directement en source de vérité. |
Aucun diagramme à afficher
Diagramme 7 — flowchart
Déroulé
| # | Étape | Écran ou endpoint réel | Donnée produite | Décision ou porte |
|---|---|---|---|---|
| 1 | Saisir l'intention | Route /projects/[projectId]/specify |
Texte libre | — |
| 2 | Lancer la génération | POST /api/v1/copilot/specify |
Exécution tracée, identifiant de run | Garde EDITOR · limite 20/minute sur les endpoints d'IA à la passerelle |
| 3 | Suivre en direct | GET /api/v1/copilot/runs/{run_id}/events — flux d'événements serveur |
Événements llm.completed, step.completed, tool.completed |
— |
| 4 | Consulter la proposition | GET /api/v1/copilot/save-objects/{proposal_id} |
Ensemble d'objets proposés, typés | Rien n'est écrit en spécification à ce stade |
| 5 | Relire et trancher | Écran de proposition | Décision objet par objet | Porte humaine explicite |
| 6 | Enregistrer | Écriture des objets retenus | Objets de spécification draft, provenance copilote |
Garde EDITOR |
| 7 | Enrichir | POST /api/v1/copilot/enrich |
Attributs complétés sur un objet existant | — |
| 8 | Interrompre si nécessaire | POST /api/v1/copilot/runs/{run_id}/stop |
Exécution arrêtée, trace conservée | Voir WF-13 et le workflow d'exception EX-03 |
Portes de gouvernance : budget de jetons contrôlé avant appel · plafond d'autonomie du rôle virtuel appliqué au minimum avec le plafond du plan · journalisation de chaque décision de politique.
Cas d'erreur
| Cas | Code HTTP réel | Comportement |
|---|---|---|
| Budget de jetons épuisé | 402 |
Refus explicite, aucun appel de modèle. |
| Limite de débit d'IA atteinte | 429 |
Fenêtre d'une minute, 20 requêtes. |
| Aucun locataire résolu | 428 tenant_required |
Refus local avant appel réseau. |
| Modèle non configuré | 501 |
Message honnête « non raccordé », jamais de réponse simulée. |
Postconditions : des objets de spécification typés existent en statut draft, chacun rattaché à une exécution tracée et attribuable.
#WF-07 · Validation EARS
| Élément | Valeur |
|---|---|
| Déclencheur | Une exigence est rédigée ou générée et doit respecter une grammaire contrôlée. |
| Acteurs | Analyste · spec-service |
| Rôles RBAC requis | EDITOR. |
| Préconditions | EARS_GENERATION_ENABLED vaut true. La surface EARS est sans état et gardée par drapeau. |
| Surfaces | Écran Spécifier · vue Spéc de l'espace de travail |
| Statut honnête | 🟢 Livré. La validation est syntaxique et structurelle, elle ne juge pas la pertinence métier. |
Aucun diagramme à afficher
Diagramme 8 — flowchart
Déroulé
| # | Étape | Écran ou endpoint réel | Donnée produite | Décision ou porte |
|---|---|---|---|---|
| 1 | Soumettre la formulation | POST /api/v1/ears/validate-generated |
Verdict de conformité | Route gardée par drapeau, sans état |
| 2 | Lire le verdict | Écran Spécifier | Patron reconnu ou écart nommé | La validation intervient à la génération, pas en revue tardive |
| 3 | Reformuler | Édition manuelle ou appel au copilote | Nouvelle formulation | Boucle jusqu'à conformité |
| 4 | Enregistrer | POST /api/v1/projects/{project_id}/spec-items |
Objet de spécification typé et versionné | Garde EDITOR |
| 5 | Relier | POST /api/v1/spec-items/{item_id}/relationships |
Arête de traçabilité | Le métamodèle du projet peut restreindre les liens autorisés |
Portes de gouvernance : le métamodèle actif du projet impose les types et les relations admissibles — voir WF-10.
Cas d'erreur
| Cas | Code HTTP réel | Comportement |
|---|---|---|
| Drapeau EARS désactivé | 404 |
La route se comporte comme absente, la surface publique reste identique. |
| Charge utile invalide | 422 |
Erreur de validation typée. |
| Objet d'un autre locataire | 404 |
Masquage d'existence. |
Postconditions : l'exigence enregistrée est conforme à un patron EARS identifié, ce qui la rend vérifiable et testable.
#WF-08 · Analyse d'impact et traçabilité
| Élément | Valeur |
|---|---|
| Déclencheur | Quelqu'un veut savoir ce que casserait une modification d'exigence. |
| Acteurs | Architecte · Product Owner · spec-service · dependency-graph-service |
| Rôles RBAC requis | VIEWER pour lire, EDITOR pour modifier ensuite. |
| Préconditions | Des objets de spécification reliés existent. |
| Surfaces | Routes /projects/[projectId]/trace, /projects/[projectId]/analyze · vues Graphe et Revue de l'espace de travail |
| Statut honnête | 🟢 Livré. Le graphe est servi par des requêtes récursives PostgreSQL sûres vis-à-vis des cycles ; Dgraph n'est pas implémenté dans le dépôt, seule la couture existe. |
Aucun diagramme à afficher
Diagramme 9 — flowchart
Déroulé
| # | Étape | Écran ou endpoint réel | Donnée produite | Décision ou porte |
|---|---|---|---|---|
| 1 | Ouvrir l'objet | Route /projects/[projectId]/spec/[itemId] · GET /api/v1/spec-items/{item_id} |
Fiche d'objet versionné | — |
| 2 | Demander l'impact | POST /api/v1/spec-items/{item_id}/impact |
Rapport d'impact | Lecture seule |
| 3 | Lire la traçabilité | GET /api/v1/spec-items/{item_id}/traceability?direction=… |
Chaînes amont et aval | Direction paramétrable |
| 4 | Ouvrir la matrice du projet | GET /api/v1/projects/{project_id}/traceability-matrix |
Matrice exigence vers preuve | Vue Revue de l'espace de travail |
| 5 | Croiser avec les tests | GET /api/v1/test-quality/projects/{project_id}/coverage |
Couverture des critères d'acceptation | Une exigence sans test est un trou nommé |
| 6 | Consulter le graphe de dépendances | GET /api/v1/dependency-graph/projects/{project_id} |
Arêtes portant chacune une origine et une preuve | Origine et preuve sont non nulles, contraintes en base |
| 7 | Décider | Écran Analyse des écarts | Demande de changement ou abandon | — |
Portes de gouvernance : chaque arête du graphe porte une origine et une preuve, imposées par la base ; aucune arête ne peut être fabriquée.
Cas d'erreur
| Cas | Code HTTP réel | Comportement |
|---|---|---|
| Objet inexistant ou hors locataire | 404 |
Masquage d'existence. |
| Graphe vide | 200 avec ensemble vide |
Aucune arête inventée pour meubler la vue. |
Postconditions : l'ensemble impacté est connu, chiffré et opposable ; les trous de couverture sont nommés.
#WF-09 · Génération de PRD et d'artefacts UML
| Élément | Valeur |
|---|---|
| Déclencheur | L'équipe veut projeter la spécification en documents de conception. |
| Acteurs | Product Owner · Architecte · artifact-service |
| Rôles RBAC requis | EDITOR pour générer, capacité docs:export pour les vues Docs et Artefacts. |
| Préconditions | Des objets de spécification existent dans le projet. |
| Surfaces | Vues Docs et Artefacts de l'espace de travail |
| Statut honnête | 🟢 Livré. Nuance : 14 types UML sont acceptés mais 5 seulement disposent d'un générateur spécialisé. La sortie graphique est du texte Mermaid — aucun PlantUML, aucun SVG, aucun PNG. |
Aucun diagramme à afficher
Diagramme 10 — flowchart
Déroulé
| # | Étape | Écran ou endpoint réel | Donnée produite | Décision ou porte |
|---|---|---|---|---|
| 1 | Générer le document d'exigences | POST /api/v1/artifacts/prd |
Document structuré projeté depuis la spécification | Garde EDITOR |
| 2 | Lire l'arborescence | GET /api/v1/projects/{project_id}/prd/{prd_id}/tree |
Structure hiérarchique | — |
| 3 | Générer un diagramme UML | POST /api/v1/diagrams/uml |
Texte Mermaid déterministe | Un type inconnu renvoie 422 uml/type-unknown en listant les 14 valeurs admises |
| 4 | Générer un processus métier | POST /api/v1/diagrams/bpmn |
Flowchart Mermaid avec couloirs | Les sous-types process, collaboration, choreography partagent le même rendu |
| 5 | Générer un modèle de données | POST /api/v1/diagrams/erd |
Diagramme entité-relation Mermaid | — |
| 6 | Lire les vues d'entreprise | GET /api/v1/togaf?project_id={id} |
Vues d'architecture d'entreprise | — |
| 7 | Lire les artefacts de sécurité | GET /api/v1/sec-artifacts?project_id={id} |
Surfaces, contrôles, points d'exposition | — |
| 8 | Exporter la documentation | GET /api/v1/documentation/{doc_id}/export?format=… |
Markdown exportable, diagrammes rendus | Capacité docs:export |
| 9 | Contrôler la dérive documentaire | GET /api/v1/documentation/{doc_id}/drift |
Écarts entre document et spécification | Boucle de retour vers le maillon Spécifier |
| 10 | Reprojeter | POST /api/v1/documentation/{doc_id}/reproject |
Document régénéré | La documentation est projetée, jamais source |
Portes de gouvernance : la documentation est un artefact projeté depuis la spécification ; toute reprojection écrase la version dérivée, jamais la spécification.
Cas d'erreur
| Cas | Code HTTP réel | Comportement |
|---|---|---|
| Type UML hors vocabulaire | 422 uml/type-unknown |
Les 14 valeurs admises sont retournées. |
| Projet vide | 200 avec modèle honnêtement vide |
Rien n'est inventé pour remplir un diagramme. |
Capacité docs:export absente |
403 |
L'export est refusé côté serveur. |
Postconditions : un jeu d'artefacts de conception cohérent existe, reproductible et déterministe, et sa dérive par rapport à la spécification est mesurable.
#WF-10 · Modélisation DDD et métamodèle par projet
| Élément | Valeur |
|---|---|
| Déclencheur | L'équipe veut imposer au projet un vocabulaire et des liens autorisés. |
| Acteurs | Architecte · collaboration-service |
| Rôles RBAC requis | EDITOR pour activer un métamodèle, VIEWER pour lire. |
| Préconditions | Un projet existe. Des jeux de métamodèles par défaut sont disponibles. |
| Surfaces | Vue Config de l'espace de travail · onglet métamodèle du projet |
| Statut honnête | 🟢 Livré, prouvé en développement. |
Aucun diagramme à afficher
Diagramme 11 — flowchart
Déroulé
| # | Étape | Écran ou endpoint réel | Donnée produite | Décision ou porte |
|---|---|---|---|---|
| 1 | Lister les métamodèles disponibles | GET /api/v1/metamodel/defaults |
Catalogue de méthodes | — |
| 2 | Lire un métamodèle | GET /api/v1/metamodel/defaults/{key} |
Types, relations, contraintes | — |
| 3 | Activer pour le projet | POST /api/v1/metamodel/projects/{project_id}/activate-defaults |
Méthodes actives du projet | Garde EDITOR |
| 4 | Lire la résolution effective | GET /api/v1/metamodel/projects/{project_id}/resolved |
Métamodèle résolu | — |
| 5 | Vérifier la conformité du projet | POST /api/v1/projects/{project_id}/model/validate |
Verdict et liste d'écarts | Porte de qualité de modélisation |
| 6 | Explorer les contextes bornés | GET /api/v1/ddd/projects/{project_id}/context-map |
Carte de contexte | — |
| 7 | Lire un agrégat | GET /api/v1/ddd/contexts/{context_id}/aggregates puis GET /api/v1/ddd/aggregates/{aggregate_id}/mermaid |
Diagramme Mermaid de l'agrégat | — |
Portes de gouvernance : le métamodèle actif restreint les types d'objets et les relations autorisées, ce qui rend la spécification vérifiable par construction.
Cas d'erreur
| Cas | Code HTTP réel | Comportement |
|---|---|---|
| Métamodèle inconnu | 404 |
— |
| Modèle non conforme | 200 avec verdict négatif |
Les écarts sont listés objet par objet, sans blocage silencieux. |
| Rôle insuffisant | 403 |
— |
Postconditions : le projet porte un métamodèle explicite, et la conformité de sa spécification à ce métamodèle est mesurable à la demande.
#WF-11 · Cycle de revue et approbation
| Élément | Valeur |
|---|---|
| Déclencheur | Un objet de spécification ou un artefact est prêt à être validé formellement. |
| Acteurs | Auteur · réviseur distinct · collaboration-service |
| Rôles RBAC requis | EDITOR pour créer, soumettre et commenter · PUBLISHER pour la décision. |
| Préconditions | Un espace de collaboration existe pour le projet. |
| Surfaces | Vue Revue de l'espace de travail · page Approbations du portail client |
| Statut honnête | 🟢 Livré. La séparation des devoirs est portée par une machine à états testée : le soumissionnaire ne peut pas être le décideur. |
Aucun diagramme à afficher
Diagramme 12 — flowchart
Déroulé
| # | Étape | Écran ou endpoint réel | Donnée produite | Décision ou porte |
|---|---|---|---|---|
| 1 | Créer la revue | POST /api/v1/reviews |
Objet de revue rattaché au sujet | Garde EDITOR |
| 2 | Soumettre | POST /api/v1/reviews/{review_id}/submit |
Identité du soumissionnaire enregistrée | La soumission fige l'auteur pour la règle de séparation |
| 3 | Discuter | POST /api/v1/reviews/{review_id}/comment · POST /api/v1/comments/threads |
Fils de discussion | Garde EDITOR |
| 4 | Décider | POST /api/v1/reviews/{review_id}/decision |
Verdict approved ou rejected |
Garde PUBLISHER + séparation des devoirs |
| 5 | Clore les fils | POST /api/v1/comments/threads/{thread_id}/resolve · …/reopen |
Fils résolus ou rouverts | — |
| 6 | Lire l'historique | GET /api/v1/reviews/{review_id} |
Chronologie complète | — |
Portes de gouvernance : la machine à états rejette toute décision dont l'auteur est aussi le soumissionnaire · l'interface bloque le bouton avant même l'appel serveur, avec un motif nommé · le serveur reste autoritatif.
Cas d'erreur
| Cas | Code HTTP réel | Comportement |
|---|---|---|
| Auto-approbation tentée | 409 |
Refus typé, décision non enregistrée. |
Rang inférieur à PUBLISHER |
403 |
Le commentaire reste possible, la décision non. |
| Revue inexistante ou d'un autre locataire | 404 |
Masquage d'existence. |
Postconditions : le sujet porte un verdict formel, attribuable à une personne distincte de l'auteur, et journalisé.
#WF-12 · Recrutement de personnel virtuel et affectation de tâche
| Élément | Valeur |
|---|---|
| Déclencheur | Une équipe veut confier un travail récurrent à un membre de personnel virtuel. |
| Acteurs | Responsable d'équipe · agentic-core-service |
| Rôles RBAC requis | EDITOR pour recruter, affecter et modifier · VIEWER pour lire l'effectif. Capacité de vue workforce:read. |
| Préconditions | Un projet existe. Le registre central d'agents est alimenté. |
| Surfaces | Vue Personnel IA de l'espace de travail · portail d'administration /workforce |
| Statut honnête | 🟢 Livré en phase 1, prouvé en navigateur réel sur développement et production : recrutement par l'interface, affectation de tâche, file de travail, flux d'activité et organigramme. Phases 2 et 3 — autonomie déléguée, escalade, chaîne d'imputabilité, console de direction — sont ⚪ Planifiées, à l'état de conception seule. |
Aucun diagramme à afficher
Diagramme 13 — flowchart
Déroulé
| # | Étape | Écran ou endpoint réel | Donnée produite | Décision ou porte |
|---|---|---|---|---|
| 1 | Créer une équipe | POST /api/v1/agentic-core/workforce/teams |
Entité équipe | Garde EDITOR |
| 2 | Recruter un membre | POST /api/v1/agentic-core/workforce/staff — bouton Recruter de l'interface |
Membre de personnel virtuel avec rôle et plafond d'autonomie N0 à N3 | Garde EDITOR |
| 3 | Lire l'effectif | GET /api/v1/agentic-core/workforce/staff |
Roster : rôle, autonomie, équipe, statut, tâches ouvertes | Capacité workforce:read |
| 4 | Affecter une tâche | POST /api/v1/agentic-core/workforce/staff/{staff_id}/tasks — modale d'affectation |
Tâche en file | Garde EDITOR |
| 5 | Suivre la file | GET /api/v1/agentic-core/workforce/staff/{staff_id}/tasks |
File de travail par membre | Rafraîchissement automatique après affectation |
| 6 | Faire avancer | PATCH /api/v1/agentic-core/workforce/tasks/{task_id} |
Statut de tâche | Garde EDITOR |
| 7 | Superviser | GET /api/v1/agentic-core/workforce/overview |
Compteurs, flux d'activité, organigramme | — |
| 8 | Mettre en pause | PATCH /api/v1/agentic-core/workforce/staff/{staff_id} — portail d'administration /workforce |
Membre suspendu ou repris | Capacité de plan de contrôle |
Portes de gouvernance : le plafond d'autonomie effectif est le minimum entre le plafond du rôle virtuel et le plafond du plan commercial ; en cas de valeur inconnue ou de dégradation du service d'entitlements, la plateforme retombe sur N1 — un repli vers le bas, jamais vers le haut.
Cas d'erreur
| Cas | Code HTTP réel | Comportement |
|---|---|---|
| Rôles virtuels désactivés par drapeau | 404 registry/virtual-roles-disabled |
La route se comporte comme absente ; le portail traite ce 404 honnêtement. |
| Rang insuffisant | 403 |
— |
| Aucune identité d'acteur | 428 actor_required |
Refus local avant appel réseau. |
Postconditions : l'effectif virtuel existe, chaque membre porte un plafond d'autonomie explicite, chaque tâche est traçable dans une file et dans le flux d'activité.
Écart connu : deux libellés français concurrents désignent cette vue — « Personnel IA » dans le sélecteur, « Effectifs IA » dans le titre. Côté portail d'administration, la clé de traduction de la destination Personnel IA est absente en français et en anglais.
#WF-13 · Exécution d'agent avec approbation humaine
| Élément | Valeur |
|---|---|
| Déclencheur | Un agent doit accomplir une action à effet de bord. |
| Acteurs | Demandeur · approbateur distinct · ai-orchestrator · agent-runtime-service · extension-registry-service |
| Rôles RBAC requis | EDITOR pour lancer · ADMIN pour approuver une action gardée · capacité plateforme fleet:interrupt pour interrompre. |
| Préconditions | L'agent existe au registre central. Une politique de garde-fou peut exiger une approbation. |
| Surfaces | Page Opérations agents et vue AgentOps du portail client · portail d'administration /fleet et /policies |
| Statut honnête | 🟢 Livré sur les trois environnements. Le registre central est la source de vérité unique ; rien n'est accordé implicitement. |
Aucun diagramme à afficher
Diagramme 14 — flowchart
Déroulé
| # | Étape | Écran ou endpoint réel | Donnée produite | Décision ou porte |
|---|---|---|---|---|
| 1 | Résoudre le bundle de l'agent | POST /api/v1/extension-registry/catalog/resolve/bundle |
Compétences, invite, liste d'outils autorisés, palier de modèle, portée mémoire | Une capacité non offerte est invisible : elle doit être approuvée, liée et non révoquée |
| 2 | Évaluer la politique | POST /api/v1/platform-config/guardrail-policies/evaluate |
Effet allow ou deny, priorité, exigence d'approbation |
Refus par défaut : toute action non couverte est refusée et journalisée |
| 3 | Demander l'approbation si requise | Page /approvals du portail client |
Demande en attente | — |
| 4 | Approuver | Décision humaine | Décision horodatée et attribuable | L'approbateur doit différer du demandeur |
| 5 | Exécuter | Tâche Kubernetes éphémère dans un espace de noms dédié, RBAC dédié, politique réseau dédiée | Sortie, artefacts, journal | Politique d'exécution : réseau en refus par défaut, liste d'autorisations de sortie, durée maximale, politique de système de fichiers |
| 6 | Contrôler le budget | Garde de crédits avant appel puis règlement avec les jetons réels | Reçu de consommation | Sans service de facturation joignable, le reçu porte metered=false — jamais un montant inventé |
| 7 | Suivre | GET /api/v1/agent-runtime/runs?limit=200 · portail d'administration /fleet |
Graphe d'exécution, tiroir de détail | — |
| 8 | Interrompre | POST /api/v1/agent-runtime/runs/{run_id}/interrupt |
Exécution arrêtée | Capacité plateforme fleet:interrupt, confirmation modale |
Portes de gouvernance : refus par défaut · séparation des devoirs sur l'approbation · plafond d'autonomie N0 à N3 · budget de jetons · journal d'audit chaîné.
Cas d'erreur
| Cas | Code HTTP réel | Comportement |
|---|---|---|
| Action non couverte par une règle | 403 avec policy_id="deny-by-default" |
Refus journalisé. |
| Auto-approbation tentée | 409 |
Refus typé. |
| Budget de jetons épuisé | 402 |
Aucun appel de modèle. |
| Outil appelé sans permission explicite | 403 + ligne d'audit blocked |
La permission d'outil a l'effet deny par défaut. |
| Quota d'appels d'outil dépassé | 402 |
Voir WF-24 et l'exception EX-10. |
Postconditions : l'exécution est tracée de bout en bout, sa décision d'autorisation est journalisée et sa consommation est mesurée ou explicitement non mesurée.
#WF-14 · Génération de tests depuis les critères d'acceptation
| Élément | Valeur |
|---|---|
| Déclencheur | Des critères d'acceptation existent et doivent devenir des tests. |
| Acteurs | Responsable de test · test-quality-service · test-data-factory-service |
| Rôles RBAC requis | EDITOR pour générer et exécuter · VIEWER pour lire la couverture. Capacité de vue test:read. |
| Préconditions | Le projet porte des objets de spécification avec critères d'acceptation. La vue Tests est la seule des onze vues à porter la nature de projet test_only. |
| Surfaces | Vue Tests de l'espace de travail |
| Statut honnête | 🟢 Livré sur les trois environnements : éditeur Gherkin intégré, carte de chaleur de couverture, données de test synthétiques. |
Aucun diagramme à afficher
Diagramme 15 — flowchart
Déroulé
| # | Étape | Écran ou endpoint réel | Donnée produite | Décision ou porte |
|---|---|---|---|---|
| 1 | Déclarer une cible de test | POST /api/v1/test-quality/test-targets |
Cible rattachée au projet | Garde EDITOR |
| 2 | Générer les cas | POST /api/v1/test-quality/test-targets/{target_id}/cases:generate |
Cas de test reliés aux critères d'acceptation | Une exécution sans cas est refusée par une erreur typée |
| 3 | Éditer | Éditeur Gherkin de la vue Tests | Scénarios lisibles | — |
| 4 | Produire des données de test | POST /api/v1/test-data-factory/… |
Jeux de données synthétiques | Aucune donnée personnelle réelle n'est utilisée |
| 5 | Exécuter | POST /api/v1/test-quality/projects/{project_id}/test-runs |
Exécution de test | — |
| 6 | Lire les résultats | GET /api/v1/test-quality/test-runs/{run_id}/results · …/report |
Verdicts par cas | — |
| 7 | Lire la couverture | GET /api/v1/test-quality/projects/{project_id}/coverage |
Carte de chaleur des critères couverts | Un critère sans test est un trou nommé |
| 8 | Lire la matrice | GET /api/v1/test-quality/{project_id}/traceability-matrix et son export .csv |
Matrice exigence vers test | Capacité d'export |
| 9 | Trier les échecs | POST /api/v1/test-quality/projects/{project_id}/failure-triage |
Classement défaut produit contre test obsolète | Alimente WF-23 |
Portes de gouvernance : portes de qualité et brèches de niveau de service visibles dans le portail d'administration · le regroupement automatique d'échecs est gardé par un drapeau désactivé par défaut.
Cas d'erreur
| Cas | Code HTTP réel | Comportement |
|---|---|---|
| Exécution sans cas | 422 |
Un plan vide ne peut pas être vert. |
| Cible d'un autre locataire | 404 |
Masquage d'existence. |
Capacité test:read absente |
403 |
La vue n'apparaît pas et l'appel serveur refuse. |
Postconditions : chaque critère d'acceptation est soit couvert par un test nommé, soit identifié comme trou de couverture.
#WF-15 · Exécution de tests navigateur réels
| Élément | Valeur |
|---|---|
| Déclencheur | Un produit est servi à une adresse et doit être vérifié en conditions réelles. |
| Acteurs | Responsable de test · deploy-service · exécuteur en tâche Kubernetes |
| Rôles RBAC requis | EDITOR. |
| Préconditions | Le service tourne dans le cluster avec un jeton de compte de service monté. Sans cluster, la route répond un 501 honnête. |
| Surfaces | Vue Livraison de l'espace de travail · assistants du portail |
| Statut honnête | 🟢 Livré, prouvé en développement avec un Chromium réel. Aucune persistance : le rapport est renvoyé dans la réponse HTTP, il n'existe ni table ni modèle de recette. |
Aucun diagramme à afficher
Diagramme 16 — flowchart
Déroulé
| # | Étape | Écran ou endpoint réel | Donnée produite | Décision ou porte |
|---|---|---|---|---|
| 1 | Vérification HTTP rapide | POST /api/v1/deploy/uat/run |
Rapport avec latence par vérification | Critère : le plan doit contenir au moins une vérification et toutes doivent passer |
| 2 | Lancer le test navigateur | POST /api/v1/deploy/uat/browser |
Tâche Kubernetes Playwright | Garde EDITOR |
| 3 | Navigation réelle | Chromium dans la tâche | Statut, titre, texte, erreurs de page | Assertions réelles, jamais simulées |
| 4 | Verdict | Statut terminal de la tâche réinterrogé | passed ou failed |
Le journal du pod est l'évidence |
| 5 | Boucler | Retour vers WF-14 ou WF-23 | Défaut ou test obsolète | L'acceptation est hors machine à états du pipeline : elle ne fait avancer aucune étape |
Portes de gouvernance : la recette n'écrit rien en base et ne franchit aucune porte de pipeline ; la seule barrière humaine formalisée reste l'approbation de déploiement de WF-19.
Cas d'erreur
| Cas | Code HTTP réel | Comportement |
|---|---|---|
| Hors cluster ou compte de service absent | 501 |
Refus explicite d'agir sans capacité réelle. |
| Adresse injoignable | Réponse 200 avec verdict négatif |
La cause est rapportée, jamais masquée. |
| Plan de vérification vide | Réponse 200 avec verdict négatif |
Un plan vide ne peut pas être vert. |
Postconditions : un verdict de recette existe, adossé à une exécution navigateur réelle et à un journal consultable.
#WF-16 · Analyse d'une base de données en exploitation
| Élément | Valeur |
|---|---|
| Déclencheur | Une équipe veut connaître l'état réel de sa base avant de faire évoluer un schéma. |
| Acteurs | Développeur ou architecte · deploy-service |
| Rôles RBAC requis | EDITOR. |
| Préconditions | Un identifiant de connexion est déposé au coffre — voir WF-30 — ou une référence de coffre est fournie. |
| Surfaces | Assistant Conseil base de données du portail client |
| Statut honnête | 🟢 Livré, prouvé en développement et en production contre PostgreSQL en exploitation. |
Aucun diagramme à afficher
Diagramme 17 — flowchart
Déroulé
| # | Étape | Écran ou endpoint réel | Donnée produite | Décision ou porte |
|---|---|---|---|---|
| 1 | Fournir la référence de coffre | Assistant du portail | Chemin de coffre, jamais un secret en clair | Le secret ne circule que par référence |
| 2 | Lancer l'analyse | POST /api/v1/deploy/db/analyze |
Connexion réelle et lectures de statistiques | Garde EDITOR |
| 3 | Lire les diagnostics | Réponse structurée | Index manquants, index inutilisés, tables sans clé primaire, taux de cache, relations les plus volumineuses | Un diagnostic impossible est marqué skipped |
| 4 | Demander conseil sur un schéma | POST /api/v1/deploy/db/advise |
Recommandations heuristiques | — |
| 5 | Reboucler | Vue Spéc | Exigences non fonctionnelles créées ou mises à jour | — |
Portes de gouvernance : identifiants lus au coffre uniquement · aucun secret renvoyé dans la réponse.
Cas d'erreur
| Cas | Code HTTP réel | Comportement |
|---|---|---|
| Base injoignable | 502 |
Aucun diagnostic n'est inventé. |
| Secret introuvable au coffre | 503 |
Refus explicite, pas de repli. |
| Rang insuffisant | 403 |
— |
Postconditions : l'état réel de la base est documenté et peut alimenter des exigences non fonctionnelles.
#WF-17 · Génération de pipeline CI/CD et commit dans le dépôt
| Élément | Valeur |
|---|---|
| Déclencheur | Une équipe veut industrialiser la construction et le déploiement de son produit. |
| Acteurs | Ingénieur d'exploitation · deploy-service · dépôt de code |
| Rôles RBAC requis | EDITOR pour générer · PUBLISHER pour commiter. |
| Préconditions | Une référence de coffre contenant le jeton du dépôt existe. |
| Surfaces | Assistant CI/CD du portail client · vue Livraison |
| Statut honnête | 🟢 Livré, prouvé en développement avec un commit réel dans un dépôt. Quatre fournisseurs générés, deux cibles de commit seulement ; la troisième est honnêtement déclarée non prise en charge pour l'écriture. Les déclencheurs d'intégration continue externes sont ⚪ Planifiés. |
Aucun diagramme à afficher
Diagramme 18 — flowchart
Déroulé
| # | Étape | Écran ou endpoint réel | Donnée produite | Décision ou porte |
|---|---|---|---|---|
| 1 | Choisir le fournisseur | Assistant CI/CD | github, gitlab, azure ou jenkins |
Un fournisseur inconnu est rejeté en 422 |
| 2 | Générer | POST /api/v1/deploy/cicd/generate |
Nom de fichier et contenu, émission déterministe | Garde EDITOR · module pur, aucun effet de bord |
| 3 | Choisir le mode de déploiement | Paramètre de la demande | kubectl ou kyspectra-golive |
Chacun exige ses paramètres, validés avant génération |
| 4 | Relire | Écran de prévisualisation | Contenu complet | Les secrets sont référencés par nom de secret du fournisseur, jamais par valeur |
| 5 | Commiter | POST /api/v1/deploy/cicd/setup |
Identifiant de commit réel dans le dépôt | Garde PUBLISHER · jeton lu au coffre |
| 6 | Vérifier | Historique du dépôt | Fichier présent | — |
Portes de gouvernance : aucun secret dans le contenu généré · jeton de dépôt lu au coffre uniquement · l'écriture exige un rang supérieur à la génération.
Cas d'erreur
| Cas | Code HTTP réel | Comportement |
|---|---|---|
| Fournisseur de dépôt non pris en charge pour l'écriture | 422 cicd/vcs-provider |
Refus honnête plutôt qu'un commit approximatif. |
| Jeton absent | 422 cicd/no-token |
— |
| Fournisseur de pipeline inconnu | 422 |
Liste des valeurs admises. |
Postconditions : le dépôt porte un pipeline exécutable, écrit par une personne de rang PUBLISHER, dont le commit est identifiable.
#WF-18 · Construction et publication d'image
| Élément | Valeur |
|---|---|
| Déclencheur | Une version doit être empaquetée en image de conteneur. |
| Acteurs | Ingénieur d'exploitation · deploy-service · registre d'images |
| Rôles RBAC requis | EDITOR pour résoudre et vérifier · PUBLISHER pour construire et publier. |
| Préconditions | Une référence de coffre contient les identifiants du registre. En cluster, un espace de noms d'exécution et un secret de registre sont configurés. |
| Surfaces | Assistant Registre du portail client · vue Livraison |
| Statut honnête | 🟢 Livré, prouvé en développement : construction sans démon en tâche éphémère, secret de registre éphémère, poignée de main réelle avec le registre. L'échange de jetons pour les registres de nuage public est ⚪ Planifié et l'annonce explicitement. |
Aucun diagramme à afficher
Diagramme 19 — flowchart
Déroulé
| # | Étape | Écran ou endpoint réel | Donnée produite | Décision ou porte |
|---|---|---|---|---|
| 1 | Résoudre le registre | POST /api/v1/deploy/registries/resolve |
Hôte et référence d'image complète | Sept familles de registres reconnues |
| 2 | Vérifier le lien | POST /api/v1/deploy/registries/verify |
Résultat d'une poignée de main réelle | Les registres de nuage public sont signalés comme nécessitant un échange de jeton absent |
| 3 | Construire et publier | POST /api/v1/deploy/images/build-push |
Image poussée | Garde PUBLISHER |
| 4 | Sécuriser les identifiants | Secret de configuration de registre éphémère monté dans la tâche | — | Jamais persisté, jamais journalisé |
| 5 | Attendre le verdict | Statut terminal de la tâche réinterrogé | Succès ou échec réel | La fin de tâche est la seule preuve acceptée |
| 6 | Publier une archive alternative | POST /api/v1/deploy/artifacts/publish-zip |
Archive réelle et adresse signée | Garde PUBLISHER |
Portes de gouvernance : identifiants par référence de coffre · exécution sans démon, en tâche éphémère, sans montage automatique de jeton de compte de service · rang PUBLISHER pour toute publication.
Cas d'erreur
| Cas | Code HTTP réel | Comportement |
|---|---|---|
| Hors cluster | 501 exec/incluster-unavailable |
Refus explicite. |
| Exécuteur non configuré | 501 build/runner-unconfigured |
Nomme la configuration manquante. |
| Création de tâche refusée par le cluster | 502 |
— |
| Outil de construction absent en mode local | 501 exec/tool-unavailable |
— |
Postconditions : une image identifiable existe dans le registre de l'utilisateur, associée à une preuve de tâche terminée.
#WF-19 · Déploiement gouverné avec approbation et retour arrière
| Élément | Valeur |
|---|---|
| Déclencheur | Une version vérifiée doit être mise en service. |
| Acteurs | Demandeur · approbateur distinct · deploy-service · cluster Kubernetes |
| Rôles RBAC requis | ADMIN pour créer un run, exécuter, déployer, approuver · PUBLISHER pour un avancement d'étape ou une simulation. |
| Préconditions | DEPLOY_LIVE doit valoir true dans l'environnement — sa valeur par défaut est false. DEPLOY_REQUIRE_APPROVAL vaut également false par défaut ; activé, il impose une approbation humaine. |
| Surfaces | Vue Livraison de l'espace de travail · page Approbations |
| Statut honnête | 🟢 Livré et prouvé en production pour Kubernetes. 🟡 Partiel pour les nuages publics : le mécanisme générique de ligne de commande en tâche est prouvé, les pilotes natifs sont ⚪ Planifiés et répondent 501. |
Aucun diagramme à afficher
Diagramme 20 — flowchart
Déroulé
| # | Étape | Écran ou endpoint réel | Donnée produite | Décision ou porte |
|---|---|---|---|---|
| 1 | Créer le run | POST /api/v1/deploy/deploy-runs |
Run et six étapes semées en attente | Garde ADMIN |
| 2 | Simuler | POST /api/v1/deploy/deploy-runs/{id}/plan |
Cible résolue, état des étapes, portes non franchies, état d'approbation, bloqueurs | Aucune infrastructure touchée, aucune écriture · garde PUBLISHER |
| 3 | Exécuter le pipeline | POST /api/v1/deploy/deploy-runs/{id}/execute |
Verdicts d'étape réels | L'approbation est vérifiée avant toute étape si le drapeau est actif |
| 4 | Étape build | Construction réelle, code de retour comme verdict | Image, journal | 501 si l'outil est absent |
| 5 | Étape test | Commande de test réelle dans l'arbre cloné | Code de sortie | 501 si le binaire est absent |
| 6 | Étape scan | Trois dimensions réelles : analyse statique, dépendances, secrets | Décomptes de constats | Un outil absent produit un 501 qui nomme les scanners manquants — jamais un vert fabriqué |
| 7 | Étape gate | Aucun outil externe | Verdict dérivé des trois verdicts réels précédents | Calcul pur |
| 8 | Approbation | POST /api/v1/deploy/deploy-runs/{id}/approve |
Décision approved ou rejected |
Séparation des devoirs stricte |
| 9 | Étape deploy | POST /api/v1/deploy/deploy-runs/{id}/deploy |
Rollout appliqué puis réinterrogé | Statut live seulement si les répliques prêtes, à jour, disponibles et souhaitées coïncident |
| 10 | Étape monitor | Relecture de l'état de la charge de travail | Convergence ou retour d'information vers la spécification | Boucle fermée |
| 11 | Retour arrière | POST /api/v1/deploy/deployments/{deployment_id}/rollback |
Nouveau déploiement portant la référence du déploiement annulé | Garde ADMIN |
| 12 | Piste d'audit | GET /api/v1/deploy/deploy-runs/{id}/approvals |
Historique des décisions humaines | — |
Portes de gouvernance : ordre d'étape non contournable · l'étape deploy ne se marque jamais à la main · un seul déploiement par run · approbation par une personne distincte du demandeur · interrupteur maître DEPLOY_LIVE.
Cas d'erreur
| Cas | Code HTTP réel | Comportement |
|---|---|---|
| Étape avancée hors ordre | 409 gate/out-of-order |
— |
| Déploiement demandé avec des portes non franchies | 409 gate/not-passed |
La liste des portes manquantes est renvoyée. |
| Tentative de marquer deploy à la main | 409 deploy/via-deploy-endpoint |
— |
| Second déploiement sur le même run | 409 deploy/already-recorded |
— |
| Approbation par le demandeur | 409 deploy/approval-self |
— |
| Approbation requise et absente | 409 deploy/approval-required |
— |
DEPLOY_LIVE désactivé |
501 deploy/live-not-enabled |
Aucun déploiement simulé. |
Postconditions : la charge de travail sert la nouvelle image, l'état a été vérifié par relecture, et la décision humaine est consignée et opposable.
#WF-20 · Mise en ligne sur sous-domaine avec TLS
| Élément | Valeur |
|---|---|
| Déclencheur | Un produit construit doit être servi publiquement à sa propre adresse. |
| Acteurs | Ingénieur d'exploitation · deploy-service · cluster Kubernetes |
| Rôles RBAC requis | PUBLISHER. |
| Préconditions | GOLIVE_ENABLED doit valoir true — sa valeur par défaut est false — et un jeton de compte de service doit être monté. |
| Surfaces | Vue Livraison de l'espace de travail |
| Statut honnête | 🟢 Livré et prouvé en production : un produit tiers est servi à un sous-domaine avec certificat. La création d'enregistrement DNS par hôte est écrite et testée mais non branchée : la mise en ligne repose aujourd'hui sur un enregistrement générique préexistant côté zone. |
Aucun diagramme à afficher
Diagramme 21 — flowchart
Déroulé
| # | Étape | Écran ou endpoint réel | Donnée produite | Décision ou porte |
|---|---|---|---|---|
| 1 | Demander la mise en ligne | POST /api/v1/deploy/go-live/{project_id} |
Plan de mise en ligne | Garde PUBLISHER |
| 2 | Contrôle du drapeau maître | Configuration d'environnement | — | false par défaut, donc 501 |
| 3 | Résolution de la cible | Modèles d'espace de noms, de charge de travail, de conteneur | Noms résolus | Bornes : répliques de 1 à 10, port de conteneur valide |
| 4 | Résolution de l'hôte | Modèle <projet>.<domaine> ou surcharge de requête |
Nom d'hôte public | Domaine par défaut kyrieva.com |
| 5 | Rendu des manifestes | Rendu pur, sans effet de bord | Déploiement, service, entrée | Sécurité par défaut : exécution non privilégiée, système de fichiers racine en lecture seule, toutes capacités retirées |
| 6 | Application | Création puis mise à jour en place si la ressource existe | Ressources en cluster | Sans jeton de compte de service, l'applieur réel n'est pas câblé, d'où un 501 |
| 7 | Certificat | Bloc TLS et annotation d'émetteur seulement si l'option d'origine chiffrée est demandée | Certificat automatique | Sinon la terminaison TLS est assurée au bord par un certificat générique |
| 8 | Retour | Adresse publique, espace de noms, hôte, statut, types de manifestes | — | Le champ DNS est toujours nul |
| 9 | Recette | Chaînage vers WF-15 | Verdict de navigateur réel | — |
Portes de gouvernance : double garde-fou — drapeau maître et capacité réelle en cluster · pod produit durci par défaut · aucune promesse DNS non tenue.
Cas d'erreur
| Cas | Code HTTP réel | Comportement |
|---|---|---|
| Mise en ligne désactivée | 501 exec/tool-unavailable |
Message explicite. |
| Applieur de manifestes indisponible | 501 |
Refus d'agir sans capacité. |
| Provisionnement automatique d'un fournisseur d'identité pour le produit | 403 du serveur d'identité, remonté en applied=false avec motif de blocage |
🔴 Bloqué : droits d'administration insuffisants, vérifiés empiriquement. Déblocage = action d'exploitation. |
Postconditions : le produit est servi à <projet>.kyrieva.com avec TLS, dans un espace de noms dédié, avec un pod durci.
#WF-21 · Collecte de retours et vote
| Élément | Valeur |
|---|---|
| Déclencheur | Un utilisateur final ou un client veut proposer une idée ou signaler un manque. |
| Acteurs | Utilisateur final anonyme · membre de l'équipe · feedback-service |
| Rôles RBAC requis | Aucun sur le tableau public, qui s'authentifie par clé de widget du locataire · EDITOR sur la boîte de réception interne. |
| Préconditions | Une clé de widget publique est émise pour le locataire. |
| Surfaces | Route publique /public/feedback du portail client · route /projects/[projectId]/feedback · widget embarquable autonome |
| Statut honnête | 🟢 Livré. Le widget de collecte embarquable est un bundle autonome intégrable chez le client. |
Aucun diagramme à afficher
Diagramme 22 — flowchart
Déroulé
| # | Étape | Écran ou endpoint réel | Donnée produite | Décision ou porte |
|---|---|---|---|---|
| 1 | Émettre une clé de widget | POST /api/v1/feedback/widget-keys |
Clé publique du locataire | Garde ADMIN |
| 2 | Intégrer le widget | Bundle autonome feedback-widget |
Extrait d'intégration avec l'adresse d'API publique | Aucune authentification utilisateur requise |
| 3 | Lire le tableau public | GET /api/v1/feedback/public/board?key=… |
Liste d'idées avec compteurs de votes | Appel anonyme, sans en-têtes d'authentification |
| 4 | Soumettre une idée | POST /api/v1/feedback/public/feedback |
Élément de retour avec émetteur facultatif | Le garde d'authentification du portail exempte les routes publiques |
| 5 | Voter publiquement | POST /api/v1/feedback/public/feedback/{item_id}/vote?key=… |
Compteur de votes, indicateur de vote déjà exprimé | Déduplication par adresse de courriel |
| 6 | Traiter en interne | Route /projects/[projectId]/feedback |
Boîte de réception, fil de commentaires | Garde EDITOR |
| 7 | Voter et commenter en interne | POST /api/v1/feedback/feedback/{id}/votes · POST /api/v1/feedback/feedback/{id}/comments |
Signal d'équipe | — |
| 8 | Convertir en exigence | Création d'un objet de spécification rattaché | Lien retour vers exigence | Boucle de retour du maillon 6 vers le maillon 2 |
Portes de gouvernance : la clé de widget est publique par construction et ne donne accès qu'aux routes publiques du locataire · aucune donnée d'un autre locataire n'est jointe.
Cas d'erreur
| Cas | Code HTTP réel | Comportement |
|---|---|---|
| Clé de widget inconnue | 404 |
Masquage d'existence. |
| Route publique appelée derrière le garde d'authentification | Redirection vers l'écran de connexion | Écart corrigé : le garde exempte désormais /public/*. |
| Vote déjà exprimé | 200 avec indicateur already_voted |
Aucun double comptage. |
Postconditions : un signal utilisateur horodaté existe, il est mesurable par les votes, et il peut devenir une exigence tracée.
#WF-22 · Publication de feuille de route et journal des changements
| Élément | Valeur |
|---|---|
| Déclencheur | L'équipe veut rendre publics ses engagements et ses livraisons. |
| Acteurs | Product Owner · public · feedback-service |
| Rôles RBAC requis | EDITOR pour écrire une entrée · PUBLISHER pour publier · aucun pour la lecture publique. |
| Préconditions | WF-21 accompli, une clé de widget existe. |
| Surfaces | Route publique /public/feedback · route /projects/[projectId]/feedback |
| Statut honnête | 🟢 Livré. |
Aucun diagramme à afficher
Diagramme 23 — flowchart
Déroulé
| # | Étape | Écran ou endpoint réel | Donnée produite | Décision ou porte |
|---|---|---|---|---|
| 1 | Lire la feuille de route interne | GET /api/v1/feedback/projects/{project_ref}/roadmap |
Éléments groupés par phase | — |
| 2 | Créer une entrée de journal | POST /api/v1/feedback/projects/{project_ref}/changelog |
Entrée en brouillon | Garde EDITOR |
| 3 | Publier | POST /api/v1/feedback/changelog/{entry_id}/publish |
Entrée visible publiquement | Garde PUBLISHER |
| 4 | Exposer la feuille de route | GET /api/v1/feedback/public/roadmap?key=… |
Vue publique | Appel anonyme |
| 5 | Exposer le journal | GET /api/v1/feedback/public/changelog?key=… |
Vue publique | Appel anonyme |
| 6 | Boucler | Retour vers WF-21 | Nouveaux votes sur les éléments annoncés | — |
Portes de gouvernance : la publication est un rang au-dessus de la rédaction · aucune entrée en brouillon n'est visible publiquement.
Cas d'erreur
| Cas | Code HTTP réel | Comportement |
|---|---|---|
Publication tentée par un rang EDITOR |
403 |
— |
| Entrée inexistante | 404 |
— |
| Clé de widget inconnue | 404 |
— |
Postconditions : la feuille de route et le journal des changements sont publiquement lisibles sans compte, et chaque publication est attribuable.
#WF-23 · Traitement d'un défaut jusqu'à la spécification d'origine
| Élément | Valeur |
|---|---|
| Déclencheur | Un test échoue, un incident survient, ou un utilisateur signale un défaut. |
| Acteurs | Responsable de test · développeur · test-quality-service · observability-board-service · agentic-core-service · spec-service |
| Rôles RBAC requis | EDITOR pour ouvrir un triage et une boucle de correction · PUBLISHER pour statuer sur la spécification. |
| Préconditions | La traçabilité entre exigences, tests et artefacts existe. |
| Surfaces | Vues Tests, Revue et AgentOps de l'espace de travail · portail d'administration /overview |
| Statut honnête | 🟢 Livré. C'est la mise en œuvre du différenciateur « un défaut remonte vers l'exigence qui l'a produit ». |
Aucun diagramme à afficher
Diagramme 24 — flowchart
Déroulé
| # | Étape | Écran ou endpoint réel | Donnée produite | Décision ou porte |
|---|---|---|---|---|
| 1 | Constater l'échec | GET /api/v1/test-quality/test-runs/{run_id}/results |
Verdicts par cas | — |
| 2 | Trier | POST /api/v1/test-quality/projects/{project_id}/failure-triage |
Classement product_defect ou obsolete_test |
Garde EDITOR |
| 3 | Statuer | POST /api/v1/test-quality/failure-triage/{id}/decision |
Décision, ouverture éventuelle d'une boucle de correction | — |
| 4 | Enregistrer le défaut | POST /api/v1/observability/defects · POST /api/v1/observability/from-failure |
Défaut avec sévérité | Le tableau de bord d'administration agrège par sévérité |
| 5 | Faire avancer la boucle | POST /api/v1/agentic-core/mas/fix-loops/{plan_id}/advance |
Étape de correction | Plafond d'autonomie applicable |
| 6 | Remonter la chaîne | GET /api/v1/spec-items/{item_id}/traceability?direction=… |
Exigence d'origine | La chaîne est portée par des arêtes à origine et preuve obligatoires |
| 7 | Trancher | Vue Revue | Correction de code ou révision d'exigence | Deux boucles de retour distinctes |
| 8 | Reboucler | WF-11 puis WF-14 | Nouveau verdict de revue et de test | — |
Portes de gouvernance : aucune correction n'est fermée sans qu'un lien vers l'exigence d'origine soit établi ou explicitement déclaré absent.
Cas d'erreur
| Cas | Code HTTP réel | Comportement |
|---|---|---|
| Aucune exigence reliée | 200 avec chaîne vide |
Le trou est nommé plutôt que comblé par une supposition. |
| Décision déjà prise | 409 |
Décision unique. |
| Boucle de correction inconnue | 404 |
— |
Postconditions : le défaut est relié à une exigence ou son absence de rattachement est explicitement consignée.
#WF-24 · Dépassement de budget et plafonnement
| Élément | Valeur |
|---|---|
| Déclencheur | La consommation d'un locataire approche ou dépasse une limite. |
| Acteurs | Administrateur du locataire · administrateur de plateforme · billing-usage-service · passerelle LLM |
| Rôles RBAC requis | EDITOR pour créer un budget ou une fenêtre de quota · capacité plateforme budgets:manage côté administration. |
| Préconditions | Un budget est défini avec sa limite, son seuil d'avertissement et son seuil critique. |
| Surfaces | Route /usage du portail client · portail d'administration /budgets |
| Statut honnête | 🟢 Livré sur les trois environnements. |
Aucun diagramme à afficher
Diagramme 25 — flowchart
Déroulé
| # | Étape | Écran ou endpoint réel | Donnée produite | Décision ou porte |
|---|---|---|---|---|
| 1 | Créer un budget | POST /api/v1/billing-usage/budgets |
Limite, seuil d'avertissement, seuil critique, portée | Garde EDITOR |
| 2 | Lire les fenêtres de quota | GET /api/v1/billing-usage/quota-windows |
Consommation, pourcentage utilisé, date de réinitialisation | Par portée et par modèle |
| 3 | Suivre côté client | Route /usage — Consommation et budgets |
Jauges dépensé, restant, pourcentage | — |
| 4 | Contrôle avant appel | Garde de crédits, puis règlement avec les jetons réels | Reçu | Sans service de facturation joignable, le reçu porte metered=false |
| 5 | Franchissement de la limite | Refus de la prochaine opération payante | Erreur de budget épuisé | Code 402 |
| 6 | Réagir | PATCH /api/v1/billing-usage/budgets/{id} ou montée de palier |
Nouvelle limite ou nouveau plan | Capacité budgets:manage côté administration |
| 7 | Effet sur l'autonomie | Résolution du plafond effectif | Repli sur N1 si le service d'entitlements est dégradé | Direction de sécurité : jamais plus d'autonomie sur incident |
Portes de gouvernance : trois seuils explicites · plafond journalier et mensuel de jetons · prix par modèle en entrée et en sortie · écriture des fonctions payantes en échec fermé vers le palier gratuit, alors que le plafond d'appels d'outil dégrade en échec ouvert pour ne pas bloquer une exécution en cours.
Cas d'erreur
| Cas | Code HTTP réel | Comportement |
|---|---|---|
| Budget de jetons épuisé | 402 |
Refus explicite, aucun appel de modèle. |
| Quota d'appels d'outil dépassé | 402 |
Refus au point de décision de politique. |
| Service de facturation injoignable | Reçu metered=false |
Jamais de montant inventé. |
| Rang insuffisant | 403 |
— |
Postconditions : la consommation est bornée, l'organisation est prévenue à deux seuils avant le refus, et aucun montant n'est jamais estimé.
#WF-25 · Montée en gamme de plan
| Élément | Valeur |
|---|---|
| Déclencheur | Une organisation atteint les limites de son palier. |
| Acteurs | Propriétaire du locataire · user-service · prestataire de paiement |
| Rôles RBAC requis | Utilisateur authentifié pour son propre abonnement · ADMIN ou SUPERADMIN pour administrer le catalogue. |
| Préconditions | Le catalogue de plans est amorcé et les identifiants de paiement sont configurés. |
| Surfaces | Route /invoices du portail client · portail d'administration /tenants |
| Statut honnête | 🟡 En cours. Le mécanisme de paiement est réel et non simulé. Écart bloquant : trois jeux de données de démarrage de plans coexistent, dont un sur un schéma périmé. Le nettoyage du catalogue est un préalable au lancement. Prix réels en base : palier Équipe 49,00 $ CAD par mois, annuel 490,00 $ ; palier Gratuit à 0 $ ; palier Entreprise sur devis. Devise unique : CAD. |
Aucun diagramme à afficher
Diagramme 26 — flowchart
Déroulé
| # | Étape | Écran ou endpoint réel | Donnée produite | Décision ou porte |
|---|---|---|---|---|
| 1 | Lire le catalogue | GET /api/v1/billing/plans — public, sans authentification |
Paliers, prix en cents, devise CAD |
Aucun filtre de publication n'est appliqué : écart connu |
| 2 | Comparer les plafonds | Tableau de paliers | Plafond d'autonomie et six quotas de registre | Gratuit N1 · Équipe N2 · Entreprise N3 |
| 3 | Changer de plan | POST /api/v1/billing/subscription/change-plan |
Abonnement modifié avec proratisation | Utilisateur authentifié |
| 4 | Confirmation asynchrone | POST /api/v1/billing/webhooks/stripe |
Événements de facturation | Signature vérifiée, idempotence garantie par un journal d'événements |
| 5 | Application des droits | Résolution des entitlements | Nouveaux quotas et nouveau plafond d'autonomie | Le drapeau des rôles virtuels vaut false par défaut : sans lui, la résolution répond 404 |
| 6 | Annuler | POST /api/v1/billing/subscription/cancel |
Fin d'abonnement en fin de période | Période de grâce |
| 7 | Essai | Profils configurés | 14 jours sans carte, rappels à J-7, J-3, J-1 | Rétrogradation vers le palier gratuit à l'expiration |
Portes de gouvernance : plafond d'autonomie plafonné par le plan · écriture des fonctions payantes en échec fermé vers le palier gratuit · aucune devise autre que le dollar canadien n'existe dans le code.
Cas d'erreur
| Cas | Code HTTP réel | Comportement |
|---|---|---|
| Prestataire de paiement non configuré | 503 |
Refus explicite lors de la création d'une intention de configuration. |
| Résolution d'entitlements désactivée par drapeau | 404 |
Comportement identique à l'absence de la fonction. |
| Sauvegarde d'une configuration de facturation sans clé de chiffrement | Échec fermé | 🔴 Bloqué : la clé de chiffrement doit être provisionnée du coffre vers le cluster. L'échec en position fermée est le comportement voulu. |
| Rang insuffisant sur le catalogue administratif | 403 |
— |
Postconditions : le locataire porte un palier explicite qui plafonne son autonomie et ses quotas.
#WF-26 · Enregistrement d'un outil MCP et permission d'appel
| Élément | Valeur |
|---|---|
| Déclencheur | Une organisation veut donner à ses agents l'accès à un outil externe. |
| Acteurs | Administrateur de plateforme ou du locataire · extension-registry-service · mcp-gateway |
| Rôles RBAC requis | EDITOR pour enregistrer et configurer · ADMIN pour la revue et la révocation · PUBLISHER pour lier une capacité approuvée. |
| Préconditions | Le secret de l'outil est déposé au coffre — voir WF-30. La base ne stocke jamais de secret. |
| Surfaces | Portail d'administration /registry, onglet Outils · /roles |
| Statut honnête | 🟢 Livré. Le service est fonctionnellement complet, sans 501 ni chantier ouvert. |
Aucun diagramme à afficher
Diagramme 27 — flowchart
Déroulé
| # | Étape | Écran ou endpoint réel | Donnée produite | Décision ou porte |
|---|---|---|---|---|
| 1 | Enregistrer le serveur d'outils | POST /api/v1/extension-registry/mcp/servers |
Serveur en statut registered |
Garde EDITOR |
| 2 | Configurer l'authentification | PATCH /api/v1/extension-registry/mcp/servers/{id}/auth |
Forme non secrète et chemin de coffre | Quatre types acceptés : aucun, protocole d'autorisation, clé d'API, authentification simple |
| 3 | Découvrir les outils | POST /api/v1/extension-registry/mcp/servers/{id}/tools |
Catalogue d'outils avec schéma d'entrée et effet de bord | — |
| 4 | Soumettre à la revue | POST /api/v1/extension-registry/extensions/mcp_server/{id}/review |
Revue en attente | Garde ADMIN + identité d'acteur obligatoire |
| 5 | Approuver | Même endpoint, décision approve |
Serveur approuvé | Séparation des devoirs, imposée jusque dans une contrainte de base |
| 6 | Accorder la permission | POST /api/v1/extension-registry/tool-permissions |
Ligne d'effet allow sur une portée |
Un serveur non approuvé provoque un 409 ; l'effet par défaut est deny |
| 7 | Résoudre | POST /api/v1/extension-registry/tool-permissions/resolve |
Verdict effectif | Sans ligne allow explicite, le verdict est deny |
| 8 | Appeler l'outil | POST /api/v1/extension-registry/sessions/{sid}/tools/{tid}:call |
Résultat + ligne d'audit | Secret résolu au moment de l'appel, jamais stocké |
| 9 | Auditer | GET /api/v1/extension-registry/audit/tool-calls et son export |
Journal paginé, empreintes seulement | Minimisation des données personnelles |
| 10 | Révoquer | POST /api/v1/extension-registry/extensions/mcp_server/{id}/revoke |
Statut revoked |
Propagation immédiate : liaisons désactivées, permissions supprimées |
Portes de gouvernance : vingt noms de secrets interdits hors chemin de coffre · huit en-têtes d'authentification interdits · scanner de valeurs à haut signal · référence de coffre obligatoire dès qu'un type d'authentification est déclaré · séparation des devoirs · refus par défaut.
Cas d'erreur
| Cas | Code HTTP réel | Comportement |
|---|---|---|
| Secret présent dans la configuration | 422 registry/tool-auth-secret |
Le message n'écho jamais la matière offensante. |
| Référence de coffre manquante | 422 registry/tool-auth-missing-ref |
La convention de chemin attendue est rappelée. |
| Permission demandée sur un serveur non approuvé | 409 |
— |
| Auto-approbation | 409 sod/self-approval-forbidden |
— |
| Identité d'acteur absente | 400 actor/required |
Une décision doit être attribuable. |
| Magasin de session indisponible | 503 capbind/session-store-unavailable |
Aucune liaison éphémère n'est accordée. |
Postconditions : l'outil est enregistré, approuvé par une personne distincte du soumissionnaire, autorisé explicitement sur une portée, et chacun de ses appels est audité.
#WF-27 · Publication d'une compétence globale
| Élément | Valeur |
|---|---|
| Déclencheur | La plateforme veut mettre une compétence réutilisable à disposition de tous les locataires. |
| Acteurs | Administrateur de plateforme · réviseur distinct · extension-registry-service |
| Rôles RBAC requis | Portée plateforme — rang ADMIN et locataire de plateforme — pour créer une entrée globale · ADMIN pour la revue · ADMIN du locataire pour adopter. |
| Préconditions | REGISTRY_TIERED_SCOPES_ENABLED doit valoir true — sa valeur par défaut est false et aucun manifeste ne la positionne. |
| Surfaces | Portail d'administration /registry, onglet Compétences |
| Statut honnête | 🟢 Livré fonctionnellement. 🟡 En cours pour l'exposition avec audience ciblée et duplication à la volée : code écrit et testé, non déployé, non prouvé en ligne. |
Aucun diagramme à afficher
Diagramme 28 — flowchart
Déroulé
| # | Étape | Écran ou endpoint réel | Donnée produite | Décision ou porte |
|---|---|---|---|---|
| 1 | Rédiger ou importer | POST /api/v1/extension-registry/skills ou …/catalog/import |
Compétence en brouillon | Description de déclenchement d'au moins vingt caractères ; secret en dur refusé |
| 2 | Vérifier la provenance | Manifeste avec source, adresse, licence, référence | Traçabilité d'origine | — |
| 3 | Vérifier la signature | Vérification cryptographique | Statut verified, unverified ou failed |
Jamais faussé : un statut invérifiable reste unverified |
| 4 | Rechercher les secrets | Scanner de contenu | Constats | Un secret bloque l'import |
| 5 | Classer le risque | Classification persistée à l'import | Niveau de risque | Un contenu importé non vérifié est classé à risque élevé |
| 6 | Valider statiquement | POST /api/v1/extension-registry/skill-versions/{id}/validate |
Rapport avec constats bloquants | Un constat bloquant maintient le brouillon |
| 7 | Soumettre à la revue | Revue soumise automatiquement si la validation est propre | Revue en attente | Aucune auto-approbation possible |
| 8 | Approuver | POST /api/v1/extension-registry/extensions/skill_version/{id}/review |
Statut approuvé | Réviseur distinct + attestation de revue de sécurité si le risque est élevé |
| 9 | Lier | POST /api/v1/extension-registry/skill-versions/{id}/bindings |
Activation sur une portée | Garde PUBLISHER |
| 10 | Adopter côté locataire | POST /api/v1/extension-registry/catalog/adoptions |
Ligne d'adoption | Garde ADMIN du locataire · quota registry.max_adoptions |
| 11 | Révoquer | POST /api/v1/extension-registry/extensions/skill_version/{id}/revoke |
Statut révoqué | Propagation immédiate |
Portes de gouvernance : l'ensemble de la chaîne est un tunnel unique — même un import en lot rejoue la pipeline entrée par entrée, rien ne la contourne · une entrée globale sans activation par défaut ni adoption n'est pas offerte · l'isolation par ligne interdit à un locataire d'écrire une entrée globale.
Cas d'erreur
| Cas | Code HTTP réel | Comportement |
|---|---|---|
| Signature invalide | 422 skill/signature-invalid |
— |
| Secret dans le contenu | 422 skill/secret-in-content |
— |
| Approbation d'un sujet à risque élevé sans attestation | 422 ext/security-review-required |
— |
| Deuxième soumission alors qu'une revue est en attente | 409 review/already-pending |
— |
| Approbation sans revue en attente | 409 review/none-pending |
— |
| Création globale hors portée plateforme | 403 registry/platform-scope-required |
Rang ADMIN et locataire de plateforme exigés. |
| Niveaux de portée désactivés par drapeau | 404 registry/tiered-scopes-disabled |
Comportement identique à l'absence de la fonction. |
Postconditions : la compétence globale est approuvée, liée, adoptable, et sa provenance ainsi que son niveau de risque sont persistés.
#WF-28 · Provisionnement du locataire de démonstration
| Élément | Valeur |
|---|---|
| Déclencheur | Un commercial ou un formateur veut une démonstration reproductible. |
| Acteurs | Administrateur de plateforme · demo-orchestrator-service |
| Rôles RBAC requis | Capacité plateforme demo:manage. |
| Préconditions | Le module de démonstration est activé — son drapeau vaut false par défaut. |
| Surfaces | Portail d'administration /demo |
| Statut honnête | 🟢 Livré. Écart connu : la table du manifeste de démonstration est morte dans l'interface — seul le résumé de comptage s'affiche. |
Aucun diagramme à afficher
Diagramme 29 — flowchart
Déroulé
| # | Étape | Écran ou endpoint réel | Donnée produite | Décision ou porte |
|---|---|---|---|---|
| 1 | Lire l'état | GET /api/v1/demo/status |
Activé, provisionné, ressources, version, projets | Capacité demo:manage |
| 2 | Provisionner | POST /api/v1/demo/provision |
Jeu de démonstration complet | Deux modes : rédigé à l'avance ou produit par des agents |
| 3 | Réinitialiser | POST /api/v1/demo/reset |
État initial restauré | — |
| 4 | Supprimer | DELETE /api/v1/demo |
Ressources retirées | Confirmation modale obligatoire |
| 5 | Épinglage | Toutes les opérations ciblent un identifiant de locataire de démonstration fixe | Isolation stricte | Aucun risque de toucher un locataire client |
Portes de gouvernance : épinglage sur un identifiant de locataire réservé · drapeau de module désactivé par défaut · capacité de plan de contrôle réservée au rôle plateforme administrateur.
Cas d'erreur
| Cas | Code HTTP réel | Comportement |
|---|---|---|
| Module désactivé | 404 |
La route se comporte comme absente. |
| Capacité absente | 403 |
Le bouton est bloqué avant l'appel serveur. |
Postconditions : un locataire de démonstration reproductible existe, isolé et réinitialisable à volonté.
#WF-29 · Production d'un rapport de conformité Loi 25
| Élément | Valeur |
|---|---|
| Déclencheur | Un auditeur, un comité ou une autorité demande la preuve de la maîtrise des traitements. |
| Acteurs | Responsable de la conformité · audit-compliance-service |
| Rôles RBAC requis | Capacité plateforme audit:export. |
| Préconditions | Le journal d'audit chaîné est alimenté. |
| Surfaces | Portail d'administration /audit |
| Statut honnête | 🟢 Livré sur les trois environnements : recherche, vérification de chaîne, génération de rapport sur période, export local. |
Aucun diagramme à afficher
Diagramme 30 — flowchart
Déroulé
| # | Étape | Écran ou endpoint réel | Donnée produite | Décision ou porte |
|---|---|---|---|---|
| 1 | Rechercher | GET /api/v1/audit-compliance/audit/events |
Événements filtrés par acteur, action, ressource ou texte libre | — |
| 2 | Vérifier l'intégrité | GET /api/v1/audit-compliance/audit/verify-chain |
Confirmation que chaque événement scelle le précédent | Chaîne de hachage recalculée |
| 3 | Générer un rapport | POST /api/v1/audit-compliance/compliance/reports — genre loi25 |
Rapport sur période | Capacité audit:export + identité d'acteur |
| 4 | Relire | GET /api/v1/audit-compliance/compliance/reports/{report_id} |
Rapport persisté | — |
| 5 | Exporter | Export local | Fichier consultable hors ligne | — |
| 6 | Compléter par les appels d'outils | GET /api/v1/extension-registry/audit/tool-calls et son export |
Journal d'appels par empreinte seulement | Minimisation des données personnelles |
| 7 | Compléter par les demandes de personnes concernées | Endpoints de confidentialité du service utilisateurs | Registre de consentements et demandes d'accès | Journal de preuve en ajout seul |
Portes de gouvernance : journal en ajout seul · chaînage par hachage vérifiable · export sans donnée personnelle superflue · les identifiants de locataire discordants renvoient 404 pour ne pas révéler l'existence d'une ressource d'autrui.
Cas d'erreur
| Cas | Code HTTP réel | Comportement |
|---|---|---|
| Chaîne rompue | 200 avec verdict négatif |
L'anomalie est nommée, jamais masquée. |
Capacité audit:export absente |
403 |
— |
| Identité d'acteur absente | 428 actor_required |
Refus local. |
Postconditions : un rapport daté, vérifiable et exportable existe, adossé à une chaîne d'audit dont l'intégrité a été recalculée.
#WF-30 · Dépôt d'un secret au coffre par projet
| Élément | Valeur |
|---|---|
| Déclencheur | Un projet a besoin d'un identifiant pour un registre, un dépôt, une base ou un service externe. |
| Acteurs | Ingénieur d'exploitation · deploy-service · coffre de secrets |
| Rôles RBAC requis | EDITOR. |
| Préconditions | Le coffre est joignable et le service dispose de ses identifiants d'accès. |
| Surfaces | Assistant Identifiants du portail client · route /credentials |
| Statut honnête | 🟢 Livré, prouvé en développement et en production : la valeur est écrite puis relue indépendamment pour preuve. |
Aucun diagramme à afficher
Diagramme 31 — flowchart
Déroulé
| # | Étape | Écran ou endpoint réel | Donnée produite | Décision ou porte |
|---|---|---|---|---|
| 1 | Choisir le fournisseur | GET /api/v1/deploy/credentials/providers |
Vingt-deux fournisseurs reconnus | Garde EDITOR |
| 2 | Construire le chemin | POST /api/v1/deploy/credentials/ref |
Chemin de coffre normalisé par environnement, projet, fournisseur et nom | Aucune valeur transmise à ce stade |
| 3 | Déposer | POST /api/v1/deploy/credentials/deposit |
Écriture réelle dans le coffre | La valeur est écrite puis jetée par le service |
| 4 | Lire la confirmation | Réponse de l'appel | Référence et numéro de version | La valeur n'est jamais renvoyée |
| 5 | Consommer | Tous les workflows qui prennent une référence de coffre | Résolution au moment de l'appel | Le secret ne transite jamais par la base de données |
| 6 | Révoquer | Opération de révocation du coffre | Version invalidée | — |
Portes de gouvernance : convention de chemin imposée · aucune valeur en réponse · aucun repli si le coffre est indisponible.
Cas d'erreur
| Cas | Code HTTP réel | Comportement |
|---|---|---|
| Coffre non configuré ou injoignable | 503 |
Refus explicite, pas de repli vers un stockage local. |
| Rang insuffisant | 403 |
— |
| Chemin ressemblant à un secret | 422 |
Un chemin de coffre doit être un chemin, pas une valeur. |
Postconditions : un secret existe dans le coffre, adressable par une référence stable, et vérifiable par relecture indépendante.
#WF-31 · Publication d'un front statique
| Élément | Valeur |
|---|---|
| Déclencheur | Une interface web construite doit être servie sans conteneur. |
| Acteurs | Ingénieur d'exploitation · deploy-service |
| Rôles RBAC requis | EDITOR pour planifier · PUBLISHER pour publier. |
| Préconditions | Une référence de coffre contient le jeton du fournisseur de diffusion ou du stockage objet. |
| Surfaces | Assistant Cibles du portail client · vue Livraison |
| Statut honnête | 🟢 Livré, prouvé en développement vers un réseau de diffusion de pages et vers un stockage objet. L'empaquetage du front par le service de déploiement est ⚪ Planifié : le bundle doit être fourni. |
Aucun diagramme à afficher
Diagramme 32 — flowchart
Déroulé
| # | Étape | Écran ou endpoint réel | Donnée produite | Décision ou porte |
|---|---|---|---|---|
| 1 | Détecter la nature du front | POST /api/v1/deploy/targets/resolve-fe |
static, spa ou ssr + cibles proposées |
Garde EDITOR |
| 2 | Lire le catalogue de cibles | GET /api/v1/deploy/targets/cloud |
Sept cibles de nuage public | — |
| 3 | Planifier | POST /api/v1/deploy/targets/plan-cloud |
Étapes et références de secrets exigées | N'exécute rien |
| 4 | Publier vers un réseau de diffusion | POST /api/v1/deploy/deploy/cloudflare-pages |
Adresse publique | Garde PUBLISHER · jeton injecté en secret éphémère consommé par la tâche |
| 5 | Publier vers un stockage objet | POST /api/v1/deploy/targets/publish-s3 |
Clés téléversées et adresse d'index | Garde PUBLISHER |
| 6 | Recette | Chaînage vers WF-15 | Verdict navigateur | — |
Portes de gouvernance : jeton par référence de coffre, jamais journalisé ni renvoyé · plan et exécution séparés · rang PUBLISHER pour toute publication.
Cas d'erreur
| Cas | Code HTTP réel | Comportement |
|---|---|---|
| Hors cluster | 501 |
Refus explicite. |
| Interface du fournisseur injoignable | 502 |
— |
| Création du secret ou de la tâche refusée | 502 |
— |
| Bundle non fourni | 422 |
L'empaquetage automatique est ⚪ Planifié : il n'est pas simulé. |
Postconditions : le front est servi à une adresse publique vérifiable, et le jeton de publication n'a jamais quitté le coffre en clair.
#WF-32 · Cycle spécification-première complet
| Élément | Valeur |
|---|---|
| Déclencheur | Une équipe veut dérouler la méthode complète, de l'intention à la tâche d'implémentation. |
| Acteurs | Product Owner · architecte · développeur · spec-service |
| Rôles RBAC requis | EDITOR pour chaque phase · ADMIN pour la phase d'implémentation. |
| Préconditions | SPEC_FIRST_ENABLED vaut true. SPEC_APPLY_ENABLED vaut false par défaut : l'application automatique des changements n'est pas active. |
| Surfaces | Écran Spécifier · vues Spéc, Tableaux et Livraison de l'espace de travail |
| Statut honnête | 🟢 Livré. Six phases nommées, chacune une route réelle. |
Aucun diagramme à afficher
Diagramme 33 — flowchart
Déroulé
| # | Étape | Écran ou endpoint réel | Donnée produite | Décision ou porte |
|---|---|---|---|---|
| 1 | Spécifier | POST /api/v1/projects/{project_id}/spec/specify |
Première formulation structurée | Garde EDITOR |
| 2 | Clarifier | POST /api/v1/projects/{project_id}/spec/clarify |
Questions ouvertes et réponses | Boucle jusqu'à levée des ambiguïtés |
| 3 | Planifier | POST /api/v1/projects/{project_id}/spec/plan |
Plan de réalisation | — |
| 4 | Découper en tâches | POST /api/v1/projects/{project_id}/spec/tasks |
Tâches reliées aux exigences | — |
| 5 | Converger | POST /api/v1/projects/{project_id}/spec/converge |
Verdict de convergence | Une non-convergence renvoie à la planification |
| 6 | Implémenter | POST /api/v1/projects/{project_id}/spec/implement |
Déclenchement d'implémentation | Garde ADMIN · l'application automatique est désactivée par défaut |
| 7 | Suivre | Vue Tableaux — kanban par statut de cycle de vie | Avancement visible | Capacité spec:read |
| 8 | Franchir les portes d'étape | GET /api/v1/sdlc/{project_ref}/stage-gates |
État des portes du cycle | Alimente WF-19 |
| 9 | Transitionner un objet | POST /api/v1/spec-items/{item_id}/transition |
Nouveau statut de cycle de vie | Transition contrôlée |
| 10 | Ancrer les décisions | POST /api/v1/projects/{project_id}/constitution/articles |
Articles de constitution du projet | Règles opposables à l'équipe et aux agents |
Portes de gouvernance : la phase d'implémentation exige un rang supérieur aux phases d'analyse · l'application automatique des changements est désactivée par défaut · les articles de constitution du projet contraignent les phases suivantes.
Cas d'erreur
| Cas | Code HTTP réel | Comportement |
|---|---|---|
| Phase déclenchée hors séquence | 409 |
— |
| Rang insuffisant sur l'implémentation | 403 |
— |
| Drapeau de méthode désactivé | 404 |
Comportement identique à l'absence de la fonction. |
Postconditions : le projet dispose d'une spécification convergée, découpée en tâches reliées, prête à alimenter les maillons Fabriquer et Vérifier.
#33. Synthèse transversale
#33.1 Les portes de gouvernance, par nature
| Nature de porte | Où elle s'applique | Workflows concernés |
|---|---|---|
| Rang RBAC minimal | Toute écriture | Tous |
| Séparation des devoirs | Revue, approbation de déploiement, gouvernance d'extension | WF-11, WF-13, WF-19, WF-26, WF-27 |
| Refus par défaut | Moteur de politique, permission d'outil, catalogue de capacités | WF-13, WF-26, WF-27 |
| Plafond d'autonomie N0 à N3 | Toute exécution d'agent | WF-06, WF-12, WF-13, WF-23 |
| Budget et quota | Tout appel de modèle ou d'outil | WF-06, WF-13, WF-24 |
| Porte humaine de validation | Promotion de spécification issue de rétro-ingénierie | WF-04, WF-05 |
| Interrupteur maître | Déploiement réel, mise en ligne | WF-19, WF-20 |
| Isolation de locataire | Toute lecture et toute écriture | Tous |
#33.2 Chaînages les plus fréquents
Aucun diagramme à afficher
Diagramme 34 — flowchart
#33.3 Ce que ce document n'affirme pas
| Sujet | Position tenue |
|---|---|
| Applications mobiles | ⚪ Planifié. Aucun code mobile n'existe dans le dépôt. Les portails sont utilisables sur mobile via navigateur. |
| Portail « business » | ⚪ N'existe pas. « Business » est une persona à l'intérieur du portail client. |
| Analyse de code non Python | Détection et signalement uniquement — jamais d'analyse fabriquée. |
| Pilotes natifs de nuage public | ⚪ Planifié, réponse 501 explicite. Le mécanisme générique en tâche est, lui, prouvé. |
| Provisionnement automatique d'un fournisseur d'identité pour le produit client | 🔴 Bloqué par des droits d'administration insuffisants, vérifiés empiriquement. |
| Chiffres de productivité | Aucun. Le dossier ne publie que des mesures de son propre dépôt. |
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.