#Sommaire
| § | Capacité | Statut d'ensemble |
|---|---|---|
| 1 | Rétro-ingénierie | 🟢 Livré, prouvé en production |
| 2 | Ingénierie avant | 🟢 Livré |
| 3 | Maintenance et évolution | 🟢 Livré |
| 4 | Tests et qualité | 🟢 Livré |
| 5 | Copilote IA | 🟢 Livré |
| 6 | Apprentissage automatique | 🟢 Livré, sans apprentissage |
| 7 | Apprentissage profond | ⚪ N'existe pas dans le dépôt |
| 8 | Vision par ordinateur | 🟡 Traitement d'image classique uniquement |
| 9 | Gouvernance des agents | 🟢 Livré · 🟡 activation par environnement |
| 10 | Personnel virtuel IA | 🟢 Phase 1 livrée · ⚪ Phases 2 et 3 planifiées |
| 11 | Protocole MCP et outils | 🟡 Contrat maison, protocole réel absent |
| 12 | Sécurité, conformité et audit | 🟢 Livré |
| 13 | Observabilité | 🟢 Livré |
| 14 | Déploiement et mise en ligne | 🟢 Livré pour Kubernetes · 🟡 partiel nuages publics |
| 15 | Facturation, quotas et crédits | 🟢 Livré |
| 16 | Collaboration | 🟢 Livré |
| 17 | Ingestion documentaire | 🟢 Livré |
| 18 | Extensibilité | 🟡 En cours |
Règle de lecture. Chaque section répond à cinq questions dans cet ordre : ce que c'est, comment KySpectra l'implémente réellement, ce qu'elle produit, ses limites, son statut. Chaque section porte un diagramme. Quand une capacité n'existe pas, la section le dit et explique ce qui existe à la place.
1. Rétro-ingénierie
#1.1 Ce que c'est
Partir d'un système logiciel existant et en reconstruire la connaissance perdue : quelle est son architecture réelle, quelles entités manipule-t-il, quel contrat expose-t-il, quelles règles porte-t-il, et quelles exigences implicites ont été codées sans jamais être écrites.
C'est le maillon 1 de la chaîne de valeur — Comprendre — et le différenciateur qui permet de ne pas partir d'une page blanche.
#1.2 Comment KySpectra l'implémente réellement
Le service de rétro-ingénierie ingère des sources, en extrait des faits objectifs horodatés par fichier et par ligne, en infère des candidats de spécification avec confiance et preuve, puis verrouille leur promotion derrière une validation.
Aucun diagramme à afficher
Diagramme 1 — flowchart
#Les sept émetteurs d'artefacts
Ils sont exactement sept, tous purs — aucune entrée-sortie — et testés en construisant des faits synthétiques.
| # | Émetteur | Faits consommés | Ce qu'il produit |
|---|---|---|---|
| 1 | C4 | Dépôt, service, module, point d'accès, dépendance externe, classe | Trois niveaux — contexte, conteneur, composant — plus un diagramme |
| 2 | Modèle entité-relation | Entités du code et tables du schéma, fusionnées par nom | Entités, attributs, relations avec clés étrangères, plus un diagramme |
| 3 | OpenAPI | Points d'accès, plus les traces observées si une analyse dynamique a tourné | Un document de contrat reconstruit, avec un localisateur par opération et une carte de preuve |
| 4 | Machines à états | Entités dont un champ de statut porte une énumération, plus les transitions explicites | Une machine par entité, avec une confiance « élevée » si les transitions sont réelles, « squelette » sinon |
| 5 | Séquences | Points d'accès et événements corrélés uniquement par co-localisation de fichier | Flux de requêtes reconstruits, plus un diagramme |
| 6 | Dictionnaire de données | Entités du code et tables du schéma, chaque champ gardant sa source et son localisateur | Catalogue de champs fusionné, trié de façon déterministe |
| 7 | Traçabilité | Les candidats des six autres émetteurs | Ancres de code, arêtes vers la spécification, taux de couverture et trous explicites |
Invariant commun : un artefact sans fait support dégrade en modèle honnêtement vide au lieu d'inventer. Un artefact demandé hors de cette liste produit un refus typé.
#L'analyse par arbre syntaxique — Python uniquement
C'est le point le plus important à dire clairement.
| Entrée | Analyse | Verdict |
|---|---|---|
| Python | Arbre syntaxique de la bibliothèque standard. Modules, classes, fonctions, complexité cyclomatique, graphe d'appels interne, distinction entre imports internes et externes, points d'accès HTTP reconnus par décorateur avec préfixe de routeur, détection d'authentification, entités et champs, événements publiés, code mort, surface de sécurité, clauses de garde | ✅ Réel et complet |
| JavaScript, TypeScript, Go, Java, Ruby, C# | Détectés par extension puis ajoutés à la liste des fichiers non supportés | ❌ Non supporté — refus honnête |
| SQL | Expressions régulières sur les définitions de tables et de clés étrangères | ⚠️ Heuristique |
| OpenAPI | Analyse réelle du document | ✅ Réel |
| GraphQL | Réutilise l'analyseur OpenAPI, sans sémantique propre | ⚠️ Dégradé, dit explicitement |
| Composition de conteneurs et Kubernetes | Analyse réelle, restreinte à quatre familles de ressources pour Kubernetes | ✅ Réel borné |
| Markdown | Premier titre, taille, extrait — aucune analyse sémantique | ⚠️ Superficiel |
| Historique de dépôt | Journal réel, plafonné à 200 commits | ✅ Réel borné |
| gRPC, intégration continue, exécution | Aucun gestionnaire ⇒ refus typé source-system-unsupported |
❌ Non supporté |
Il n'existe aucun analyseur polyglotte dans le service. La recherche exhaustive ne trouve aucune bibliothèque de ce type. C'est une limite structurelle, pas un oubli de configuration.
#La promotion automatique de spécifications
| Réglage | Valeur par défaut |
|---|---|
| Promotion automatique activée | Oui |
| Seuil de confiance | 0,7 |
| Adresse du magasin de spécification | Vide — sans elle, la promotion est un no-op déclaré |
Le mécanisme est délibérément identique au chemin humain : la tâche de validation est réellement approuvée par la même fonction qu'un humain, avec un relecteur sentinelle fixe et une note explicite « promu automatiquement, confiance supérieure ou égale à N pour cent ». Une approbation machine reste donc attribuable et distinguable d'une approbation humaine.
Trois garde-fous encadrent cette automatisation :
- Un déclencheur en base rend toute promotion impossible sans tâche approuvée.
- Les candidats sous le seuil restent en attente dans la file réelle : rien de risqué ne devient source de vérité automatiquement.
- Chaque candidat est encadré par un point de reprise transactionnel : un échec ne fait reculer que ce candidat, qui redevient une tâche humaine en attente.
#1.3 Ce qu'elle produit
| Sortie | Nature |
|---|---|
| Faits extraits | Lignes persistées avec provenance ingested:<source> |
| Candidats inférés | Types possibles : exigence fonctionnelle, règle métier, entité, exigence non fonctionnelle, décision, persona, contexte |
| File de validation | Triée par confiance décroissante |
| Objets de spécification promus | Provenance reverse:<mode>, statut brouillon, identifiant canonique renvoyé par le serveur, jamais fabriqué |
| Sept familles d'artefacts | Reconstructibles à la demande, en lecture seule |
| Constats de dérive | Persistés, comparant spécification et code |
#1.4 Limites connues
| # | Limite |
|---|---|
| 1 | Un seul langage réellement analysé |
| 2 | Le clone n'a ni délai d'expiration ni limite de taille : un dépôt lent peut bloquer un travailleur |
| 3 | Les types de candidats produits par les émetteurs sortent du vocabulaire persistable : les reconstructions restent donc en lecture seule |
| 4 | La découverte d'application vivante exige un moteur de navigateur : sans lui, un refus typé, et par défaut aucun n'est configuré |
| 5 | L'analyse markdown n'extrait aucune sémantique |
| 6 | En production, le clone depuis un dépôt public a exigé une règle réseau dédiée sur le port 443, la politique de refus par défaut bloquant l'opération. Le correctif est appliqué et vérifié |
#1.5 Statut
🟢 Livré, prouvé de bout en bout en navigateur réel sur l'environnement de production : import d'un dépôt public, analyse, promotion, spécifications visibles dans le portail.
2. Ingénierie avant
#2.1 Ce que c'est
Le chemin inverse de la rétro-ingénierie : partir d'une intention, la transformer en spécification exécutable, projeter cette spécification en artefacts de conception, la faire fabriquer, la vérifier, puis la livrer.
#2.2 Comment KySpectra l'implémente réellement
Aucun diagramme à afficher
Diagramme 2 — flowchart
#Le vocabulaire canonique, mesuré dans le code
| Élément | Valeur réelle |
|---|---|
| Types d'objets de spécification | 63 |
| Types de relations | 24 |
| Statuts du cycle de vie d'un objet | 7 |
| Métamodèles intégrés | 17 paquets, version de catalogue 3 |
| Phases du cycle de vie projet | 12, de l'admission au retrait |
L'identifiant canonique a la forme PROJET-TYPE-NNNN, avec une séquence à quatre chiffres minimum, immuable et jamais réutilisée, allouée par un compteur atomique en base.
#Les six commandes du cycle de spécification
| Commande | Effet |
|---|---|
specify |
Crée un lot d'objets depuis une intention |
clarify |
Émet des clarifications et des hypothèses explicites |
plan |
Produit un plan |
tasks |
Décompose en tâches |
converge |
Fait converger les propositions concurrentes |
implement |
Dispatche vers l'orchestrateur — rang administrateur requis |
#La projection en artefacts
| Famille | Ce qui est produit | Réalité |
|---|---|---|
| Document d'exigences produit | Arbre document, épopée, récit, exigence, critère d'acceptation | Magasin versionné ; la génération assistée existe mais aucun schéma de sortie spécifique n'est imposé |
| UML | 14 types acceptés, 5 avec générateur dédié, 9 en organigramme générique | Sortie textuelle de diagrammes, jamais d'image |
| BPMN | Trois sous-types acceptés, un seul rendu | Couloirs supportés ; les bassins sont annoncés mais non implémentés |
| Modèle entité-relation | Notation native, huit cardinalités, marqueurs de clés | Réel |
| ArchiMate | Trois couches plus une couche de repli, onze relations typées | Réel, mais non exposé par la passerelle |
| TOGAF | Dix phases énumérées, trois formes | Seule la forme diagramme produit un rendu ; catalogue et matrice sont stockés sans validation ni rendu |
| Sécurité | Modèle de menace, diagramme de flux de données, confiance zéro, gestion des identités | Le diagramme de flux et la confiance zéro sont réels ; le modèle de menace valide les catégories mais ne produit aucune table de menaces ni score de risque |
| Documentation comme code | Trois types, deux langues | Projection réelle depuis la spécification, avec détection de dérive |
#2.3 Ce qu'elle produit
Une chaîne continue et traçable : une intention devient des objets versionnés, qui deviennent des artefacts, qui deviennent du code exécuté dans une tâche isolée, qui devient une image publiée, qui devient un produit servi sur un sous-domaine avec certificat — et chaque étape porte sa preuve.
#2.4 Limites connues
| # | Limite |
|---|---|
| 1 | La génération assistée d'un document d'exigences n'impose aucun contrat de sortie spécifique |
| 2 | Neuf des quatorze types UML n'ont pas de sémantique dédiée |
| 3 | Aucune validation syntaxique du texte de diagramme produit : la propriété est construite, pas vérifiée |
| 4 | La transition de statut d'un artefact n'est pas contrainte |
| 5 | L'export en PDF perd le tiret cadratin utilisé par la projection elle-même |
#2.5 Statut
🟢 Livré sur les trois environnements pour la spécification et la conception ; la fabrication et la livraison relèvent des sections 9, 10 et 14.
3. Maintenance et évolution
#3.1 Ce que c'est
Ce qui se passe après la première mise en production : comprendre l'impact d'un changement, remonter un défaut jusqu'à l'exigence qui l'a produit, mesurer la dette, planifier une migration, et retirer proprement ce qui n'a plus lieu d'être.
#3.2 Comment KySpectra l'implémente réellement
Aucun diagramme à afficher
Diagramme 3 — flowchart
#L'analyse d'impact, telle qu'elle est calculée
Elle s'appuie sur un graphe où chaque arête porte une origine et une preuve non vide — la contrainte est en base, pas seulement dans le code. Six provenances sont possibles : analyse statique, analyse dynamique, infrastructure comme code, historique de dépôt, manifeste, spécification.
| Sortie | Détail |
|---|---|
| Traversée | Ascendants, descendants, chemins, voisinage |
| Cycles | Détection par requête récursive sûre vis-à-vis des cycles |
| Simulation | Quatre modes : modifier, retirer, découper, remplacer — persistée |
| Métriques de couplage | Entrant, sortant, instabilité, abstraction, cohésion |
| Points chauds | Complexité croisée avec fréquence de changement |
| Bandes de risque | Élevé au-delà de 10 dépendants, moyen au-delà de 3 |
Les bornes de coût sont explicites : profondeur par défaut 6, plafond 25 au-delà duquel la requête est refusée sans être exécutée.
#La remontée des défauts vers la spécification
| Chemin | Mécanisme |
|---|---|
| Défaut de test → exigence | Le triage propose une cause, le regroupement rassemble les rouges en causes, une décision humaine ouvre un défaut par cause |
| Incident → exigence | Un incident dont la cause est établie peut dériver des objets de spécification |
| Retour utilisateur → admission | Un retour qualifié est converti en demande d'admission réelle dans le moteur de cycle de vie |
| Dérive → tâche | Un constat de dérive persisté alimente une tâche de maintenance créée depuis des signaux réels, avec déduplication |
#La dette technique
Elle est mesurée par des faits, pas déclarée :
| Signal | Source |
|---|---|
| Code mort | Analyse statique du dépôt |
| Complexité cyclomatique | Analyse statique |
| Points chauds | Complexité croisée avec fréquence de changement |
| Vulnérabilités de dépendances | Scan sur une base publique d'avis ; scan désactivé ⇒ verdict « inconnu » explicite, jamais un faux conforme |
| Licences non conformes | Politique explicite : six licences permises, trois interdites |
| Trous de traçabilité | Calculés par l'émetteur de traçabilité |
| Bibliothèques épinglées hors liste blanche | Signalées par l'analyse de configuration produit |
#Les migrations
| Type | Mécanisme |
|---|---|
| Migration de schéma d'un service | Fichiers SQL appliqués au démarrage, idempotents, sous verrou consultatif, avec empreinte |
| Migration d'un locataire | Suivi de migrations dans le plan de contrôle, avec relance possible |
| Modernisation d'un système existant | Plan de type « figuier étrangleur », avec quatre styles cibles : microservices, monolithe modulaire, événementiel, sans serveur |
| Retrait d'un objet | Plan de dépréciation. La suppression directe est toujours refusée par un conflit typé : on déprécie, on ne supprime pas |
#3.3 Ce qu'elle produit
Une trace opposable qui relie un incident de production à l'exigence qui l'a produit, et un ensemble minimal de régénération plutôt qu'une reconstruction complète.
#3.4 Limites connues
| # | Limite |
|---|---|
| 1 | Le moteur de graphe est PostgreSQL, derrière une couture prévue pour un moteur natif non implémenté |
| 2 | Il n'existe pas d'entité défaut dans le moteur de cycle de vie : seulement une référence sur l'incident. L'entité vit dans le service d'observabilité |
| 3 | Le regroupement d'échecs est désactivé par défaut |
| 4 | La détection de dérive de documentation repose sur une empreinte réduite à six champs : une modification de description sans changement d'empreinte de contenu ne serait pas détectée |
| 5 | L'écriture effective d'une décision de changement vers la spécification est désactivée par défaut dans le service de synchronisation |
#3.5 Statut
🟢 Livré pour l'analyse d'impact, la traçabilité, la remontée des défauts et les migrations · 🟡 En cours pour l'activation de l'écriture depuis les outils de suivi externes.
4. Tests et qualité
#4.1 Ce que c'est
Prouver que ce qui a été fabriqué satisfait ce qui a été demandé, en reliant chaque test à une exigence nommée.
#4.2 Comment KySpectra l'implémente réellement
Aucun diagramme à afficher
Diagramme 4 — flowchart
#La génération de tests est obligatoirement gouvernée
Il n'existe aucun chemin de repli non gouverné. Sans service d'orchestration de prompts configuré et sans version de modèle d'invite déclarée, la génération renvoie un refus typé generation/governance-required.
| Étape | Garantie |
|---|---|
| Assemblage | Contexte tracé, budget appliqué, détection de secrets bloquante |
| Appel | Vers le proxy de modèles partagé, jamais en direct chez un éditeur |
| Validation | Sortie analysée et validée contre les mêmes vocabulaires que la base |
| Échec de validation | Refus typé, rien n'est persisté |
| Artefact produit | Statut brouillon, provenance agent:QA — donc soumis à revue humaine |
Quatre chemins de génération existent : scénarios depuis un critère d'acceptation, scénarios ancrés sur un objet de spécification, cas depuis un scénario, cas limites depuis une exigence.
#Les données de test synthétiques conformes
| Mécanisme | Valeur réelle |
|---|---|
| Barrière de conformité | Toute stratégie non synthétique sans approbateur nommé est refusée, en code et par contrainte en base |
| Seuil de k-anonymat | 2 |
| Risque de ré-identification maximal | 0,5 ; un identifiant direct résiduel force le score à 1,0 et le refus est automatique |
| Domaines de courriel | Domaines réservés par les normes internationales |
| Téléphones | Bloc de fiction réservé |
| Reproductibilité | Même graine, même référence, même nombre ⇒ octets identiques sur toute machine |
| Marquage | Chaque enregistrement porte un marqueur explicite de synthèse |
| Cycle de vie | Brouillon, généré, validé, matérialisé ; démontage possible depuis tout état vivant, idempotent |
Aucun modèle n'est appelé : la génération est entièrement déterministe, sur la bibliothèque standard.
#Les tests navigateur réels
| Chemin | Mécanisme |
|---|---|
| Recette de mise en production | Tâche Kubernetes avec une image de navigateur réelle ; assertions sur le code HTTP, sur un titre de document non vide, sur un texte attendu, et sur l'absence d'erreur de page |
| Verdict | Le statut terminal réinterrogé de la tâche, avec le journal du module comme preuve |
| Hors cluster | Refus typé, jamais un faux vert |
#La couverture et les portes
| Élément | Réalité |
|---|---|
| Couverture des critères d'acceptation | Calculée depuis les runs verts réels, avec les trous listés explicitement |
| Surface de couverture | Une grille dimensions par périmètres, persistée et rapportable |
| Carte de chaleur | N'existe pas côté service. Le rendu visuel appartient au portail |
| Matrice de traçabilité | Exposée par le service de test et par le magasin de spécification |
| Porte de qualité | Soumission puis approbation d'un plan par une personne différente, via le cœur agentique |
| Adaptateurs non câblés | Renvoient un verdict non concluant, jamais un faux vert |
#Le Gherkin, honnêtement
Il existe une validation structurée des trois clauses — donné, quand, alors — plus les conjonctions, doublée d'une contrainte en base. Une structure malformée est refusée avant l'attribution d'un identifiant canonique.
Il n'existe ni analyseur de fichiers de fonctionnalité, ni export au format Gherkin.
#4.3 Ce qu'elle produit
Une couverture reliée à des exigences nommées, des trous explicites, des grappes de causes plutôt que des listes de rouges, et une décision de porte attribuable.
#4.4 Limites connues
| # | Limite |
|---|---|
| 1 | Le regroupement d'échecs est désactivé par défaut |
| 2 | Les portes d'évaluation d'agents existent en code pur mais ne sont câblées à aucune route |
| 3 | L'export d'analyse en PDF renvoie un refus typé si la bibliothèque de rendu manque |
| 4 | La virtualisation de service existe en code pur mais n'est exposée par aucune route |
| 5 | Le test navigateur réel n'est prouvé que sur l'environnement de développement |
#4.5 Statut
🟢 Livré sur les trois environnements pour la génération, la couverture et les portes ; 🟢 Livré sur développement pour le test navigateur réel.
5. Copilote IA
#5.1 Ce que c'est
Un assistant qui transforme une intention exprimée en français en objets de spécification validés, qui répond à des questions sur des documents, et qui propose des écritures sans jamais les appliquer seul.
#5.2 Comment KySpectra l'implémente réellement
Aucun diagramme à afficher
Diagramme 5 — flowchart
#Ce que l'utilisateur peut faire concrètement
| Action | Point d'accès réel |
|---|---|
| Décrire un besoin et obtenir des objets de spécification | POST /api/v1/copilot/specify, réponse immédiate en 202 |
| Demander un enrichissement approfondi par un collège d'experts | POST /api/v1/copilot/enrich, 202 |
| Suivre l'exécution en direct | GET /api/v1/copilot/runs/{id}/events |
| Téléverser un document et lui poser une question | POST /api/v1/copilot/uploads puis /ask |
| Poser une question sur les données métier | POST /api/v1/copilot/data-qa |
| Lancer une analyse asynchrone | POST /api/v1/copilot/analyze |
| Proposer un lot d'écritures | POST /api/v1/copilot/save-objects/propose |
| Confirmer ou clore la proposition | POST /api/v1/copilot/save-objects/{id}/confirm |
| Pré-remplir un formulaire depuis un document | POST /api/v1/copilot/form-fill |
| Consulter la file de revue | GET /api/v1/copilot/reviews |
#Les objets d'écriture — le mécanisme clé
C'est la réponse à « comment laisser une IA écrire sans lui laisser le stylo ». Le modèle produit un ensemble de changements structuré, qui est persisté comme proposition. Rien n'est appliqué. Un humain relit, puis confirme ou clôt. Le code l'écrit ainsi : « les applications sont impossibles avant une confirmation explicite ».
#Le tableau d'agents en direct
Un bus d'événements en processus, avec tampon de rejeu, alimente un flux serveur. Le numéro de séquence persisté est utilisé verbatim comme identifiant d'événement, ce qui rend la reprise exacte après coupure. Un run démarré sur un autre module est rechargé depuis les événements persistés avant diffusion. L'abonnement exige un ticket signé à durée limitée, lié au run.
#Les cinq garde-fous
| Garde-fou | Effet exact |
|---|---|
| Classifieur de sûreté | Appliqué en tête de chaque entrée en langage naturel — questions, analyse, objets d'écriture, remplissage de formulaire, extraction — avant tout appel de modèle, tout débit de crédit et tout accès aux données |
| Validation humaine de niveau 2 | Les objets d'écriture sont proposés, jamais appliqués |
| Politique brouillon ou définitif | Chaque résultat persisté est marqué, avec un enregistrement de revue |
| Validation stricte du contrat | Sortie analysée contre le contrat du magasin de spécification, une seule relance corrective |
| Ticket de flux signé | L'abonnement au flux n'est pas anonyme |
Un sixième garde-fou est structurel : le magasin de spécification n'est appelé qu'après validation, donc un échec ne laisse aucun objet partiel.
#5.3 Ce qu'elle produit
Des objets de spécification réels, avec l'identifiant canonique renvoyé par le serveur ; un journal d'exécution rejouable ; des propositions d'écriture attribuables.
#5.4 Limites connues
| # | Limite |
|---|---|
| 1 | La recherche augmentée est désactivée par défaut : un document est découpé mais marqué dégradé, et la récupération renvoie un refus typé |
| 2 | Le stockage d'objets est désactivé par défaut : aucune référence de stockage fabriquée |
| 3 | Sans service de facturation, le reçu porte explicitement « non facturé » |
| 4 | Un service de collaboration injoignable fait retomber le métamodèle sur le socle par défaut, avec une source explicitement marquée « repli hors ligne » |
| 5 | L'extraction d'images et de types inconnus renvoie un refus typé |
#5.5 Statut
🟢 Livré sur les trois environnements.
6. Apprentissage automatique
#6.1 Ce que c'est
Des modèles qui produisent une prédiction : similarité, classification, triage, prévision.
#6.2 Comment KySpectra l'implémente réellement — et ce que ce n'est pas
Aucun apprentissage n'a lieu dans ce dépôt. Le service d'apprentissage automatique sert des modèles déterministes, écrits à la main, plus deux chemins qui appellent une API distante.
Aucun diagramme à afficher
Diagramme 6 — flowchart
#Les sept modèles enregistrés — leur technique réelle
| Modèle | Ce que le registre annonce | Ce que c'est vraiment |
|---|---|---|
| Triage de défaillance | « Inférence logistique multinomiale » | Un dictionnaire de coefficients écrits à la main, plus une normalisation exponentielle numériquement stable. Jamais entraîné. Quatre classes : défaut produit, instable, environnement, données. Un indicateur de signal faible est levé sous 0,35 |
| Prévision d'usage | « Tendance linéaire par moindres carrés » | De l'algèbre en arithmétique pure, avec des intervalles de prédiction de Student. Moins de trois points ⇒ refus honnête |
| Détection de renseignements personnels | « Expressions régulières plus somme de contrôle » | Exactement cela. Sept familles détectées. Ne renvoie jamais la valeur brute : type, compte, échantillon masqué, position |
| Classification de type de document | « Fréquence de termes pondérée » | Un lexique fixe de dix types. Signal trop faible ⇒ renvoie honnêtement « autre » |
| Extraction de document | « Multi-moteurs plus détection de grille » | Routage entre des bibliothèques d'analyse de fichiers ; moteur absent ⇒ refus nommant le moteur |
| Mise en correspondance de schéma | « Correspondance approximative plus coercition de type » | Bibliothèque standard. Sous le seuil de 0,55, le champ reste non mappé |
| Analyse de page | « Profils de projection plus densité d'encre » | Voir la section 8 |
#La déduplication et la similarité
| Étape | Mécanisme |
|---|---|
| Vectorisation | Appel distant à un service de plongements, dimension 1536 |
| Recherche | Magasin vectoriel filtré par locataire, avec une collection par locataire en défense en profondeur |
| Décision | Seuil de doublon 0,92 ; entre 0,80 et 0,92, un test de contradiction conservateur peut déclarer un conflit ; sinon nouveau |
| Test de contradiction | Exige un recouvrement lexical d'au moins 0,4 et soit une inversion de polarité, soit une divergence numérique |
#Ce qui répond honnêtement par un refus
| Situation | Réponse |
|---|---|
| Modèle de plongement non configuré | 501 |
| Magasin vectoriel non configuré | 501 vector-store/unconfigured |
| Fournisseur renvoyant zéro vecteur | 502 |
| Classification à zéro exemple sans passerelle | 501 puis 502 — jamais de repli silencieux sur le chemin lexical |
| Historique insuffisant | 422 forecast/insufficient-history |
| Moteur d'extraction absent | 501 nommant le moteur |
| Reconnaissance de caractères demandée sans binaire | Type laissé nul avec avertissement — jamais deviné |
#6.3 Ce qu'elle produit
Des verdicts explicables — le triage renvoie des contributions par caractéristique — et un journal d'audit qui conserve l'empreinte de l'entrée, jamais le texte brut.
#6.4 Limites connues
| # | Limite |
|---|---|
| 1 | Aucune bibliothèque d'apprentissage automatique n'est installée : ni scikit-learn, ni XGBoost, ni équivalent |
| 2 | Les coefficients du modèle de triage sont calibrés à la main : leur qualité n'est pas mesurée sur un jeu de validation |
| 3 | Le registre renvoie la première définition correspondant à une tâche ; deux modèles partagent la tâche de classification |
| 4 | Le journal de prédiction est secondaire : un échec d'écriture est journalisé sans invalider le résultat |
| 5 | Aucune route n'est protégée par un rôle : seule l'isolation par locataire s'applique |
#6.5 Statut
🟢 Livré — au sens de « des prédictions réelles, honnêtes et explicables ». Pas au sens de « apprentissage automatique entraîné », qui n'existe pas ici.
7. Apprentissage profond
#7.1 Ce que c'est
L'entraînement et l'inférence de réseaux de neurones profonds.
#7.2 Verdict factuel : cette capacité n'existe pas dans le dépôt
C'est la section la plus courte du document, et la plus importante à ne pas embellir.
Aucun diagramme à afficher
Diagramme 7 — flowchart
#La preuve, point par point
| Vérification | Résultat |
|---|---|
| Cadres d'apprentissage profond dans les fichiers de dépendances | Aucun. Ni PyTorch, ni TensorFlow, ni Keras, ni JAX |
| Bibliothèques d'apprentissage automatique classique | Aucune. Ni scikit-learn, ni XGBoost, ni LightGBM, ni ONNX |
| Bibliothèques de traitement du langage | Aucune. Ni spaCy, ni NLTK, ni Gensim |
| Bibliothèque de transformeurs | Aucune |
| Bibliothèque de phrases vectorisées | Déclarée dans un seul fichier de projet, mais explicitement morte. Le fichier de dépendances du même service écrit noir sur blanc qu'elle tirait un cadre profond et des pilotes graphiques de plusieurs gigaoctets, qu'elle a fait échouer la machine de construction, et que le service ne l'importe pas. Vérification faite : aucun import dans tout le dépôt |
| Code d'entraînement | Aucun. Aucune boucle d'époque, aucune rétropropagation, aucun optimiseur d'apprentissage, aucune sauvegarde de modèle |
| Fichiers de poids | Aucun, quelle que soit l'extension recherchée |
#Ce qui existe réellement, et qu'il faut dire à la place
| Capacité réelle | Nature |
|---|---|
| Appels à de grands modèles de langage | Oui, via un proxy compatible OpenAI hébergé hors de ce dépôt. Trois paliers : rapide, standard, expert |
| Plongements de texte | Oui, par appel d'API distante, dimension 1536 |
| Analyse d'images par un grand modèle | Oui, un point d'accès envoie des images encodées à la passerelle. C'est un appel HTTP, pas une inférence locale |
| Repli déterministe d'un plongement | Un service possède une chaîne de repli qui termine par une empreinte cryptographique normalisée. Ce n'est pas un plongement sémantique : c'est un vecteur de hachage, et le code le nomme comme tel |
#7.3 Ce qu'elle produit
Rien qui lui soit propre. Toute la capacité dite « IA » de la plateforme est distante et déléguée. Le dépôt est un orchestrateur, pas un entraîneur.
#7.4 Limites connues
La limite est la capacité : il n'y a rien à entraîner, rien à héberger, rien à mettre à jour côté modèle. En contrepartie, la plateforme dépend entièrement de la disponibilité de la passerelle de modèles, et le dit : un refus typé plutôt qu'un résultat fabriqué.
#7.5 Statut
⚪ N'existe pas. Toute communication affirmant que KySpectra « entraîne des modèles » ou « fait de l'apprentissage profond » serait fausse.
8. Vision par ordinateur
#8.1 Ce que c'est
L'extraction d'information depuis des images.
#8.2 Comment KySpectra l'implémente réellement
Il existe trois modules de traitement d'image réels, tous déterministes, tous sans réseau de neurones, pour environ 310 lignes utiles au total.
Aucun diagramme à afficher
Diagramme 8 — flowchart
#Module 1 — Analyse de page
| Aspect | Réalité |
|---|---|
| Algorithme auto-déclaré | « Profils de projection plus densité d'encre » |
| Étapes réelles | Décodage, conversion en niveaux de gris, redimensionnement à 1 600 pixels maximum, seuil fixe, moyennes de pixels sombres par ligne et par colonne |
| Classification | Un arbre de conditions codé en dur. Quatre classes : page vide, photo, tableau ou formulaire, page de texte |
| Les « probabilités » | Des constantes normalisées, pas la sortie d'un modèle |
| Sans la bibliothèque d'image | Refus typé vision/engine-unavailable, jamais un résultat fabriqué |
#Module 2 — Comparaison visuelle
| Aspect | Réalité |
|---|---|
| Différence de pixels | Valeur absolue au-delà d'un seuil, puis ratio de pixels changés |
| Indice de similarité structurelle | Formule globale réimplémentée à la main — moyennes, variances, covariance sur toute l'image. Ce n'est pas la version fenêtrée d'une bibliothèque spécialisée : c'est une approximation à fenêtre unique |
| Dépendance | Un seul module de calcul numérique ; la bibliothèque d'image ne sert qu'au décodage |
| Activation | Activée par défaut ; désactivée, refus typé |
| Usage | Comparer une capture d'écran contre une capture de référence approuvée par un rôle publieur |
#Module 3 — Reconnaissance de caractères
Appel à un binaire système externe. Aucun modèle dans le dépôt. Si le binaire n'est pas installé dans l'image, le chemin image de l'extraction renvoie un refus typé et la reconnaissance de caractères est simplement désactivée — le reste du traitement d'image continue de fonctionner.
#Module 4 — Capture d'écran du widget de retours
Sérialisation du DOM vivant dans un objet étranger SVG, puis rastérisation sur un canevas. Les limites sont écrites dans le code : les feuilles de style d'origine tierce sont illisibles et ignorées, les images d'origine tierce sont remplacées par un cadre neutre, la capture est un rendu statique, et en cas d'échec le widget soumet sans capture plutôt qu'une capture corrompue.
#Les réponses catégoriques
| Question | Réponse | Preuve |
|---|---|---|
| Détection d'objets ? | Non | Aucune occurrence de bibliothèque ou de concept associé dans tout le dépôt |
| Classification d'image par réseau de neurones ? | Non | Le module d'analyse de page est un arbre de conditions ; le registre le marque déterministe |
| Reconnaissance faciale ? | Non | Aucune occurrence |
| Modèle de vision pré-entraîné local ? | Non | Aucun fichier de poids dans le dépôt |
| Modèle de vision distant ? | Oui, un seul point d'accès : il envoie des images encodées à la passerelle de modèles partagée. C'est un appel HTTP | — |
| Bibliothèque de vision par ordinateur installée ? | Non. Elle apparaît uniquement comme clé d'un dictionnaire de détection de disponibilité — sondée, jamais installée, jamais importée | — |
#8.3 Ce qu'elle produit
Une classe de page parmi quatre, un verdict de comparaison visuelle chiffré, un texte extrait quand le binaire est présent, et une capture jointe à un retour utilisateur.
#8.4 Limites connues
La limite principale est la nature même de ces modules : c'est du traitement d'image classique, avec des seuils fixes et des heuristiques, pas de la vision apprise. Un document mal cadré, un fond coloré ou une mise en page inhabituelle dégradent la classification sans que le système le sache.
#8.5 Statut
🟡 Traitement d'image classique livré — analyse de page, comparaison visuelle, reconnaissance de caractères déléguée, capture d'écran. ⚪ Vision par ordinateur apprise : n'existe pas. Aucune communication ne doit laisser croire le contraire.
9. Gouvernance des agents
#9.1 Ce que c'est
Traiter un agent IA comme un collaborateur : un périmètre déclaré, des capacités accordées explicitement, un plafond d'autonomie, un budget et un journal.
#9.2 Comment KySpectra l'implémente réellement
Aucun diagramme à afficher
Diagramme 9 — flowchart
Chaque étage peut refuser. Aucun n'accorde par omission.
#Le registre central
| Propriété | Détail |
|---|---|
| Rôle | Source de vérité persistée de tous les agents |
| Contenu par agent | Nom, nature statique ou dynamique, capacités, compétences, serveurs d'outils, jetons estimés, transport, état, visibilité |
| Alimentation | L'orchestrateur pousse ses spécifications au démarrage et peut tirer ce qui lui manque |
| Dégradation | Registre injoignable ⇒ le registre en mémoire reste intact |
| Exposition | Portail d'administration, destination Agents IA |
| Écart honnête | Le service n'a aucun contrôle d'accès basé sur les rôles, et l'en-tête de locataire y est optionnel |
#Les capacités à trois niveaux
| Niveau | Valeur | Qui accorde |
|---|---|---|
| Global | global |
Le locataire réservé de la plateforme, avec un rang administrateur et un périmètre plateforme vérifié |
| Organisation | tenant, valeur par défaut |
Un rang administrateur du locataire |
| Utilisateur | user, capacités d'invite uniquement |
La personne propriétaire |
« Projet » n'est pas un niveau : c'est une valeur de la grammaire de liaison, aux côtés de « locataire » et « agent ».
La résolution. Le catalogue tranche : une capacité n'est offerte que si elle est approuvée et liée et non révoquée. Une entrée globale sans activation par défaut ni adoption n'est pas offerte. En cas de liaisons concurrentes, la plus spécifique gagne : agent, puis projet, puis locataire.
#Le refus par défaut, aux trois endroits où il compte
| Endroit | Comportement |
|---|---|
| Permission d'outil | La colonne d'effet vaut deny par défaut en base : sans ligne explicite d'autorisation, l'appel est refusé |
| Catalogue | L'appelant ne voit rien plutôt qu'une capacité fabriquée |
| Moteur de politique d'exécution | Onze motifs d'action autorisés, tout le reste refusé et journalisé sous un identifiant de politique dédié |
| Point d'application des outils | Panne du point de décision ⇒ refus ; erreur serveur ⇒ refus ; magasin de sessions injoignable ⇒ refus |
Sont intentionnellement absents de la liste d'autorisations, donc refusés : le déploiement en production, la suppression de fichiers par commande système, la sortie réseau, l'écriture hors espace de travail et l'emprunt de secret.
#La séparation des devoirs, à trois étages
- Contrainte en base interdisant le même identifiant en soumissionnaire et en relecteur.
- Garde applicative avant toute approbation, retraduisant une violation en conflit typé.
- Attribution obligatoire : sans identifiant d'acteur valide, un refus explicite — « une décision doit être attribuable ».
Approuver un sujet classé à risque élevé exige en plus une attestation de revue de sécurité. Une seconde soumission alors qu'une revue est en cours produit un conflit. Approuver sans revue en attente aussi.
#Le plafond d'autonomie N0 à N3
| Niveau | Signification opérationnelle |
|---|---|
| N0 | L'agent propose. Rien ne s'exécute sans validation humaine explicite |
| N1 | L'agent exécute des lectures et des préparations, sans effet de bord durable |
| N2 | L'agent exécute des actions à effet de bord dans un périmètre déclaré |
| N3 | L'agent exécute de bout en bout dans son périmètre, sous journal et budget |
La règle de plafonnement est un minimum entre le plafond du rôle virtuel et celui du plan commercial. En cas de valeur inconnue ou de dégradation du service de droits, la plateforme retombe sur N1 : l'autonomie baisse en cas d'incertitude, jamais l'inverse. Le code nomme cette direction « sûre par défaut ».
| Plan | Plafond maximal |
|---|---|
| Découverte | N1 |
| Équipe | N2 |
| Entreprise | N3 |
Sept rôles virtuels sont définis dans le roster, chacun avec une autonomie par défaut et un maximum propre.
#Les budgets
| Mécanisme | Réalité |
|---|---|
| Budget par périmètre | Limite en dollars, seuil d'avertissement à 80 %, seuil critique à 95 % |
| Refus | Une charge qui ferait dépasser un budget lié est refusée et rien n'est écrit |
| Budget de jetons | Plafond journalier de 500 000 et mensuel de 10 000 000, appliqués dans le cache |
| Pré-autorisation | Conservatrice, pas atomique : deux exécutions simultanées peuvent chacune passer avant d'incrémenter |
| Plafond d'appels d'outils | Quotidien, par plan, de 200 à un million |
#9.3 Ce qu'elle produit
Un journal opposable de qui a autorisé quoi, à quel agent, dans quel périmètre, avec quel budget, et pour quel résultat.
#9.4 Limites connues
| # | Limite |
|---|---|
| 1 | Les deux drapeaux maîtres — portées à trois niveaux et rôles virtuels — valent faux par défaut et aucun manifeste de déploiement ne les active |
| 2 | Le registre central lui-même n'a aucune garde de rôle |
| 3 | Les plans de découverte et de proxy hérités de la passerelle d'outils sont totalement non gouvernés |
| 4 | Les six agents de flotte ont leur gouvernance désactivée par défaut : les adresses du registre et de l'orchestration d'invites sont vides |
| 5 | Le mode d'authentification par en-têtes auto-déclarés est la valeur par défaut du code et n'est surchargé dans aucun manifeste |
#9.5 Statut
🟢 Livré pour le mécanisme, testé et prouvé en développement · 🟡 En cours pour son activation par environnement, qui est une action d'exploitation et non de développement.
10. Personnel virtuel IA
#10.1 Ce que c'est
Modéliser les agents comme un effectif : des membres avec un rôle et une discipline, des équipes, un rattachement hiérarchique, des files de travail, un niveau d'autonomie et un historique.
#10.2 Comment KySpectra l'implémente réellement
Aucun diagramme à afficher
Diagramme 10 — flowchart
#La phase 1 — ce qui existe et est prouvé
| Capacité | Route réelle | Preuve |
|---|---|---|
| Créer une équipe | POST /api/v1/workforce/teams |
🟢 Livré |
| Recruter un membre | POST /api/v1/workforce/staff |
🟢 Prouvé en navigateur réel sur développement et sur production |
| Modifier un membre — statut, équipe, autonomie | PATCH /api/v1/workforce/staff/{id} |
🟢 Livré |
| Assigner une tâche | POST /api/v1/workforce/staff/{id}/tasks |
🟢 Prouvé en navigateur réel |
| Consulter la file | GET /api/v1/workforce/staff/{id}/tasks |
🟢 Prouvé |
| Faire transiter une tâche | PATCH /api/v1/workforce/tasks/{id} |
🟢 Livré |
| Récapitulatif | GET /api/v1/workforce/overview |
🟢 Livré |
Le modèle de données porte les trois tables : équipe, personnel, tâche. Le niveau d'autonomie par défaut d'un membre est N1. L'état de validation humaine d'une tâche vaut « aucune » par défaut.
#L'organigramme, honnêtement
Les primitives hiérarchiques existent : une équipe peut avoir une équipe parente et un coordinateur, et chaque membre est rattaché à une équipe. Mais il n'existe aucun point d'accès dédié à l'organigramme. Le récapitulatif ne renvoie que des compteurs. L'arbre doit être reconstruit par l'appelant depuis la liste des équipes et celle du personnel.
C'est exactement ce que fait le portail. La capacité est donc utilisable, mais elle n'est pas servie par le serveur.
#Les phases suivantes
| Phase | Contenu conçu | Statut |
|---|---|---|
| Phase 2 | Autonomie déléguée, escalade, contrat d'autonomie par membre | ⚪ Planifié — conception seule |
| Phase 3 | Chaîne d'imputabilité, grand livre de responsabilité, console de direction virtuelle globale | ⚪ Planifié — conception seule |
Les drapeaux nommés dans le document de conception de ces phases n'existent nulle part dans le code : ce sont des noms de conception, pas des drapeaux livrés.
#10.3 Ce qu'elle produit
Un effectif visible : combien de membres, combien d'actifs, combien d'équipes, combien de tâches ouvertes et terminées, et la file de chacun.
#10.4 Limites connues
| # | Limite |
|---|---|
| 1 | Pas de point d'accès d'organigramme |
| 2 | Le service hôte est hors du châssis partagé : aucune garde de rôle sur les routes héritées, origines de partage ouvertes, base partagée, création de schéma automatique |
| 3 | Deux systèmes de validation humaine coexistent sans être unifiés ; seul le second applique la séparation des devoirs |
| 4 | La clé de traduction de la destination correspondante manque dans le portail d'administration, en français comme en anglais |
| 5 | Deux libellés français concurrents désignent la même vue dans le portail client |
#10.5 Statut
🟢 Phase 1 livrée et prouvée en navigateur réel sur développement et sur production. ⚪ Phases 2 et 3 planifiées, conception seule.
11. Protocole MCP et outils
#11.1 Ce que c'est
Donner aux agents un accès contrôlé à des outils externes : bases de connaissances, systèmes de gestion, API tierces.
#11.2 Comment KySpectra l'implémente réellement
Aucun diagramme à afficher
Diagramme 11 — flowchart
#Trois rectifications factuelles
| Croyance | Réalité |
|---|---|
| « Les serveurs d'outils sont en Node.js » | Faux. Les cinq serveurs sont des applications Python. Aucun fichier TypeScript ou JavaScript n'existe dans ce répertoire |
| « Le protocole MCP est implémenté » | Non. Ni appel de procédure JSON, ni transport par entrée-sortie standard, ni flux d'événements. C'est un contrat HTTP maison inspiré de MCP : santé, catalogue, exécution |
| « Trois transports sont supportés » | Le schéma du registre en autorise trois ; un seul existe |
#Les outils réellement disponibles — inventaire exhaustif
| Serveur | Outils | Lecture | Écriture | Sur données d'exemple | Amont mort |
|---|---|---|---|---|---|
| Magasin de documents | 5 | 5 | 0 | 0 | 5 |
| Profils d'utilisateurs | 5 | 5 | 0 | 0 | 5 |
| Base de connaissances | 4 | 3 | 1 | 4 | 0 |
| Moteur de référentiels | 5 | 5 | 0 | 5 | 0 |
| Réglages et configuration | 8 | 7 | 1 | 8 | 0 |
| Total | 27 | 25 | 2 | 17 | 10 |
Traduction opérationnelle honnête : sur 27 outils, 17 fonctionnent sans dépendance externe mais sur des données d'exemple codées en dur, et 10 pointent vers des services qui n'existent pas — l'un des deux services amont n'existe pas dans le dépôt, et l'autre n'expose aucune des cinq routes appelées. Le code du proxy est réel ; la dépendance ne l'est pas.
Le seul outil portant une logique métier non triviale est un vérificateur de conformité qui évalue des contrôles avec quatre statuts possibles, présume la non-conformité pour un contrôle critique non évalué, et calcule un score.
Le repli statique de la passerelle déclare 14 serveurs ; 9 n'ont aucune implémentation et seront systématiquement signalés en mauvaise santé.
#La gouvernance, où elle s'applique et où elle ne s'applique pas
| Chemin | Gouvernance |
|---|---|
| Appel gouverné | Identifiant de locataire obligatoire et valide, décision déléguée, exécution uniquement sur autorisation explicite, échec fermé de bout en bout |
| Découverte, proxy hérité, appel explicite par serveur | Aucune. Ni authentification, ni autorisation, ni locataire. Le fichier de description l'assume |
#La résolution des secrets
Le point de décision ne voit jamais un secret : il ne stocke qu'un chemin de coffre. La passerelle lit le secret au moment de l'appel, l'injecte selon le type d'authentification, et ne journalise que des codes de raison non secrets. Les en-têtes statiques déclarés ne peuvent jamais écraser l'authentification résolue. Toute erreur de résolution produit un refus sans exécution.
Trois règles de rejet à l'enregistrement protègent la base : vingt noms de secret interdits hors des clés de coffre, huit en-têtes d'authentification interdits, et un détecteur de secrets à fort signal sur chaque chaîne. Le message de refus n'écho jamais la matière offensante.
#11.3 Ce qu'elle produit
Un journal d'appels d'outils en ajout seul, contenant l'empreinte des arguments et non leur valeur, avec le coût associé — exportable en CSV et en PDF.
#11.4 Limites connues
| # | Limite |
|---|---|
| 1 | Le protocole réel n'est pas implémenté |
| 2 | Le drapeau des portées à trois niveaux étant éteint par défaut, l'injection d'authentification amont est inerte en configuration par défaut |
| 3 | Aucun manifeste Kubernetes de la passerelle ni de l'espace de noms des serveurs n'existe dans le dépôt |
| 4 | Aucun test, aucune authentification entrante, aucune isolation par locataire dans les serveurs d'outils : l'état est global au processus |
| 5 | Deux fichiers JSON locaux constituent toute la persistance ; ils ne sont pas partagés entre répliques |
#11.5 Statut
🟡 En cours. Le chemin gouverné est réel et testé par 17 tests ; le reste demande un travail de complétion assumé.
12. Sécurité, conformité et audit
#12.1 Ce que c'est
Prouver, devant un auditeur, qui a fait quoi, quand, sur quelle donnée, avec quelle autorisation — et démontrer que la preuve n'a pas été modifiée.
#12.2 Comment KySpectra l'implémente réellement
Aucun diagramme à afficher
Diagramme 12 — flowchart
#La chaîne de hachage
Le hachage d'une ligne combine le hachage de la ligne précédente et une sérialisation canonique de l'action, de l'acteur, de la ressource et de la charge utile. La première ligne part d'une valeur de genèse fixe.
La vérification contrôle deux invariants par ligne : la continuité du chaînage et l'exactitude du recalcul. Elle retourne le premier bris, avec sa raison typée : genèse incorrecte, chaînage incorrect, hachage incorrect. Une chaîne vide est valide par vacuité.
Le code le dit lui-même : la vérification effectue un vrai recalcul, elle peut retourner « invalide », elle ne tamponne rien.
Le journal est protégé en base : révocation des droits de modification et de suppression, plus des déclencheurs. L'insertion seule est possible.
#Comment le journal se remplit
Un intergiciel partagé émet un événement d'audit par mutation réussie depuis n'importe quel service, en une ligne de câblage. La documentation du module est explicite sur la cause racine qu'il corrige : la plateforme avait un journal conforme, mais aucun service métier ne l'appelait, donc les recherches d'audit et les rapports comptaient zéro événement.
#Les rapports Loi 25
La génération agrège réellement le journal sur la période : vue des accès, des consentements et des violations, comptes par action, acteurs et ressources distincts, plus une vérification de chaîne au moment de la génération. Une période sans données produit un rapport valide, horodaté et vide — jamais une erreur.
La résidence des données est paramétrable et reportée dans chaque rapport ; sa valeur par défaut est le Québec.
#La conformité côté données personnelles
| Mécanisme | Où |
|---|---|
| Registre de consentement en ajout seul | Service d'identité |
| Demandes d'accès aux renseignements personnels | Service d'identité |
| Travaux d'export de données personnelles | Service d'identité |
| Détection de renseignements personnels à l'ingestion | Sept familles, échantillons masqués, valeur brute jamais persistée |
| Barrière d'acceptation | Une justification non vide est obligatoire pour accepter un candidat marqué |
| Données de test sans donnée réelle | Barrière refusant toute stratégie non synthétique sans approbateur |
| Nettoyage des preuves | Activé par défaut sur le plan d'exécution des agents |
| Journal d'appels d'outils | Empreinte des arguments seulement, jamais leur valeur |
#L'isolation multi-locataire
| Rang | Source du locataire |
|---|---|
| 1 | En-tête dédié — prioritaire |
| 2 | Revendication du jeton vérifié |
| 3 | Paramètre de requête — dernier repli |
Règle de sécurité : un identifiant en désaccord avec la revendication du jeton renvoie 404, pas 403. On ne divulgue pas l'existence de la ressource d'autrui. Le choix est motivé par la minimisation.
La sécurité au niveau des lignes est forcée dans la grande majorité des services : la variable de session est posée par requête, en transaction locale, avant toute lecture — sans quoi les politiques masqueraient les données au service lui-même.
#Les secrets
Aucun secret n'est jamais écrit en base : seul un chemin de coffre circule. Deux garanties structurelles le vérifient :
- Une contrainte en base impose que le chemin commence par le préfixe attendu.
- Une garde exécutée au chargement du module interdit toute colonne de secret sur la table de configuration d'authentification du produit généré.
Le plan d'exécution des agents va plus loin : le secret est rendu par un agent de coffre à l'intérieur de la tâche et ne touche jamais la spécification de la tâche, le service, la base ni un journal. Seule la référence du bail est enregistrée pour l'audit, dans une table qui n'a aucune colonne de secret — garde structurelle testée.
#12.3 Ce qu'elle produit
Un journal vérifiable, un rapport de période exportable, une preuve de consentement, et une réponse défendable à « montrez-moi ce que cet agent a fait ».
#12.4 Limites connues
| # | Limite |
|---|---|
| 1 | Les trois lectures sensibles du service d'audit n'ont aucune garde de rôle, seulement l'isolation par locataire |
| 2 | Le mode d'authentification par en-têtes auto-déclarés est la valeur par défaut du code |
| 3 | Cinq rôles sectoriels hérités subsistent hors hiérarchie et ne satisfont jamais une exigence de rang minimum |
| 4 | L'export PDF d'un rapport renvoie un refus typé si la bibliothèque de rendu manque |
| 5 | Une clé de chiffrement doit être provisionnée depuis le coffre vers le cluster ; en son absence, les nouvelles sauvegardes de configuration de facturation échouent en position fermée — ce qui est le comportement voulu, mais reste un blocage |
#12.5 Statut
🟢 Livré sur les trois environnements · 🔴 Bloqué pour la sauvegarde de nouvelles configurations de facturation, tant que la clé n'est pas provisionnée.
13. Observabilité
#13.1 Ce que c'est
Savoir ce que fait la plateforme, mesurer sa progression sur des faits, et déclencher une décision quand un seuil est franchi.
#13.2 Comment KySpectra l'implémente réellement
Aucun diagramme à afficher
Diagramme 13 — flowchart
#Trois invariants remarquables
| Invariant | Comportement |
|---|---|
| Progression calculée, jamais déclarée | Les deux points d'accès d'écriture manuelle renvoient toujours un refus typé progress/derived-only |
| Défaut vérifié seulement sur preuve | Un défaut n'atteint l'état « vérifié » qu'avec une preuve de nouvelle exécution verte, sinon un conflit typé |
| Pas d'observation, pas de brèche | Une cible sans valeur observée renvoie « non évaluée » avec la raison, jamais une brèche |
#Le catalogue d'indicateurs
Environ 42 indicateurs répartis en huit familles : flux, indicateurs de performance de livraison, qualité, agents, coût, spécification, sécurité, fiabilité. Chaque entrée porte un identifiant, une famille, une formule sous forme d'expression machine, une unité, une direction, une fenêtre et des dimensions.
Les formules sont évaluées par un moteur d'expressions sûr, jamais par une évaluation dynamique de code. Une entrée manquante produit un refus typé, pas un zéro silencieux.
#Les seuils et les brèches
Une cible porte un comparateur, une valeur et une action de porte. L'évaluation lit la dernière valeur observée. Chaque brèche écrit une ligne durable et émet une alerte sur le flux. La publication sur un bus de messages est optionnelle, best-effort, et désactivée par défaut.
#Le tableau AgentOps — précision importante
Le tableau AgentOps de l'espace de travail du portail client ne lit pas le service d'observabilité : il consomme les exécutions du copilote. Le service d'observabilité porte sa propre piste d'activité d'agents, distincte, avec un graphe d'exécution calculé et une intention de contrôle — arrêt, interruption, départage — accompagnée d'un audit.
Les flux de livraison alimentent la même piste par un type d'exécution dédié.
#13.3 Ce qu'elle produit
Un instantané agrégé par périmètre, un déroulé du projet jusqu'à la tâche, une progression défendable, un historique de brèches, et un graphe d'exécution.
#13.4 Limites connues
| # | Limite |
|---|---|
| 1 | L'ingestion depuis un bus de messages ou un système de métriques est hors périmètre : les valeurs sont postées par l'API |
| 2 | Le rapport en PDF renvoie un refus typé — il n'y a pas de chaîne de rendu ni de stockage d'objets pour cela |
| 3 | Le portail d'administration affiche un flux d'activité par sondage, pas par événements serveur |
| 4 | La latence de santé par service affiche toujours zéro en mode passerelle, l'agrégat ne l'exposant pas |
| 5 | Le service de boucle de correction automatique n'a aucun dépôt cible configuré par défaut : son état est « non configuré » |
#13.5 Statut
🟢 Livré sur les trois environnements.
14. Déploiement et mise en ligne
#14.1 Ce que c'est
Transformer un artefact vérifié en produit servi, sous décision approuvée et avec un retour arrière possible.
#14.2 Comment KySpectra l'implémente réellement
Aucun diagramme à afficher
Diagramme 14 — flowchart
#Les six étapes et leur exécution réelle
| # | Étape | Exécution | Sans l'outil |
|---|---|---|---|
| 1 | Construction | Clone puis construction d'image ; variante sans démon en tâche Kubernetes, contexte depuis le dépôt, statut terminal réinterrogé | Refus typé |
| 2 | Test | Commande configurée dans l'arbre cloné ; le code de retour est le verdict | Refus typé |
| 3 | Analyse | Trois dimensions réelles : analyse statique de sécurité, audit de dépendances, détection de secrets | Refus typé nommant les analyseurs manquants — jamais un vert fabriqué |
| 4 | Porte | Aucun outil externe : verdict dérivé des trois verdicts réels précédents | — |
| 5 | Déploiement | Application de l'image puis nouvelle interrogation ; l'état « en ligne » n'est prononcé que si les répliques prêtes, mises à jour, disponibles et souhaitées coïncident | Refus typé |
| 6 | Surveillance | Relecture post-déploiement ; sinon un retour est renvoyé vers la spécification — la boucle est fermée | — |
#Les invariants d'ordre
Portés par un module pur, donc testables hors base :
- Une étape d'ordre inférieur non franchie bloque l'avancement, avec un conflit typé.
- Les portes non franchies sont listées dans le refus.
- L'étape de déploiement ne se marque jamais à la main : elle passe obligatoirement par son point d'accès dédié.
- Un seul déploiement par exécution.
#L'approbation et le retour arrière
| Mécanisme | Réalité |
|---|---|
| Approbation humaine | Décision approuvée ou rejetée, persistée avec demandeur et approbateur |
| Séparation des devoirs | L'approbateur doit différer du demandeur, sous peine d'un conflit typé |
| Interrupteur d'exigence | Un drapeau impose l'approbation ; il vaut faux par défaut |
| Retour arrière | Déploiement inverse réel ; l'original passe à l'état « annulé », une nouvelle ligne référence l'original |
| Simulation à blanc | Cible résolue, état des étapes, portes non franchies, approbation, disponibilité, obstacles — aucune infrastructure touchée, aucune écriture |
#La mise en ligne sur sous-domaine
Trois manifestes sont rendus par une fonction pure puis appliqués : un déploiement durci, un service et une entrée. Le déploiement produit tourne sans privilège, avec un système de fichiers racine en lecture seule, toutes les capacités retirées, et des ressources bornées. Le nombre de répliques est borné entre 1 et 10, le port entre 1 et 65 535.
Deux garde-fous encadrent l'opération : un drapeau dédié, faux par défaut, et la présence effective d'une configuration en cluster — sans quoi un refus typé est levé.
#Ce qui est plan-only côté nuages publics
C'est le point à dire avec précision.
| Cible | Réalité |
|---|---|
| Kubernetes interne | 🟢 Réel et prouvé en production |
| Publication d'un front statique vers un service de pages | 🟢 Réel, prouvé en développement : une tâche exécute l'outil de publication et l'adresse publique est extraite du journal |
| Publication d'un front statique vers un stockage objet | 🟢 Réel, prouvé en développement : téléversement et adresse signée |
| Interface en ligne de commande de nuage générique | 🟢 Réel, prouvé en développement sur un fournisseur : une tâche exécute n'importe quelle image d'outil avec les identifiants déposés |
| Vérification d'un lien de registre | 🟢 Réel : véritable poignée de main du protocole de registre |
| Génération de pipeline pour quatre fournisseurs | 🟢 Réel, avec commit réel dans un dépôt |
| Pilotes natifs des services de conteneurs des trois grands nuages | ⚪ Plan seul. Il n'existe aucun exécuteur dédié par fournisseur ; le module de publication nuage ne fournit que des plans avec leurs prérequis. Ce qui manque : les identifiants nuage de l'utilisateur et les pilotes eux-mêmes |
| Échange de jetons de registre des trois grands nuages | ⚪ Absent. La vérification de registre le signale honnêtement |
| Empaquetage d'un front statique par le service de déploiement | ⚪ Absent |
| Déclencheurs d'intégration continue externes | ⚪ Absents |
| Provisionnement automatique d'un fournisseur d'identité pour le produit client | 🔴 Bloqué, vérifié empiriquement par des refus réels du serveur d'identité : le compte de service n'a ni le droit de créer un realm, ni celui de gérer les fournisseurs d'identité. Le déblocage est une action d'exploitation, pas de développement |
#Le DNS, honnêtement
Un client d'enregistrement DNS est écrit et testé, mais non branché : le service de mise en ligne est construit sans lui, et les deux réglages correspondants ne sont lus nulle part. Le champ DNS de la réponse est donc toujours vide.
Conséquence factuelle : une mise en ligne sur un sous-domaine repose aujourd'hui sur un enregistrement générique préexistant dans la zone. Aucun enregistrement par hôte n'est créé par le service.
#L'interrupteur maître
Un drapeau d'exécution réelle vaut faux par défaut. Sans lui, aucun déploiement n'est simulé : le produit renvoie un refus explicite avec un message clair. C'est la traduction la plus directe de l'honnêteté d'ingénierie revendiquée.
#14.3 Ce qu'elle produit
Un produit servi sur un sous-domaine avec certificat, une décision approuvée traçable, une preuve d'étape par étape, et un chemin de retour arrière.
#14.4 Limites connues
Voir le tableau ci-dessus. À retenir : un correctif d'exploitation reste nécessaire pour la partie identité, et les pilotes nuage natifs sont planifiés, pas disponibles.
#14.5 Statut
🟢 Livré pour Kubernetes, prouvé en production · 🟡 Partiel pour les nuages publics · 🔴 Bloqué pour le provisionnement automatique d'identité.
15. Facturation, quotas et crédits
#15.1 Ce que c'est
Compter la consommation réelle, la plafonner avant qu'elle ne dérape, et ne jamais inventer un montant.
#15.2 Comment KySpectra l'implémente réellement
Aucun diagramme à afficher
Diagramme 15 — flowchart
#Les quatre mécanismes
| Mécanisme | Réalité |
|---|---|
| Budget | Limite en dollars, seuil d'avertissement à 80 %, seuil critique à 95 %, quatre états. Une contrainte en base garantit que la dépense ne dépasse pas la limite |
| Fenêtre de quota | Par périmètre et par modèle, avec limites, consommation, pourcentage utilisé et date de réinitialisation. Deux modèles de fenêtre : glissante par minute et glissante hebdomadaire |
| Grand livre de crédits | En ajout seul, cinq types de mouvement avec contrainte de signe. La table de comptes n'a volontairement aucune colonne de solde : le solde est toujours une somme |
| Budget de jetons | Plafonds journalier et mensuel appliqués dans le cache, avec expiration automatique des compteurs |
#Le prix par modèle est en base, pas dans le code
Sept lignes de tarif sont semées par migration, en crédits pour mille jetons, en entrée et en sortie, avec une ligne par défaut. Un crédit vaut un dollar américain. La conversion des jetons en crédits passe par un seul point, alimenté par le prix lu en base.
#La configuration semée
| Réglage | Valeur |
|---|---|
| Seuils d'alerte | 50 %, 80 %, 95 % |
| Crédits de grâce | 0 |
| Bascule de routage | 80 % |
| Drainage | 95 % |
| Étiquette de prévision | « estimation » |
#La garantie d'honnêteté
Elle vit dans la bibliothèque partagée. Quand aucun service de facturation n'est joignable, la pré-vérification renvoie un ticket non contraignant et le reçu porte explicitement « non facturé » avec la raison « facturation désactivée ». Aucun montant n'est inventé.
Cette garantie est consommée par au moins quatre services : orchestration d'invites, test et qualité, ingestion, apprentissage automatique.
#La posture d'échec
| Situation | Direction |
|---|---|
| Écriture d'une fonction payante en cas de dégradation | Fermée : refus |
| Plafond d'appels d'outils quotidien en cas de dégradation | Ouverte : l'appel passe, la dégradation est journalisée |
| Prévision | Toujours étiquetée « estimation » par configuration |
#Le catalogue commercial
Trois plans existent réellement en base : gratuit, équipe à 49 dollars canadiens par mois, entreprise sur devis. La devise unique du code est le dollar canadien.
Le paiement est réel, pas simulé : le module de paiement du fournisseur est appelé pour l'annulation en fin de période, le changement de plan avec proratisation, et les webhooks sont vérifiés par signature avec idempotence.
#15.3 Ce qu'elle produit
Une consommation mesurée par modèle, un solde vérifiable, un refus avant dépassement, et un reçu qui dit la vérité même quand il ne peut pas facturer.
#15.4 Limites connues
| # | Limite |
|---|---|
| 1 | La pré-autorisation de budget de jetons est conservatrice, pas atomique : deux exécutions simultanées peuvent chacune passer avant d'incrémenter |
| 2 | Les compteurs d'usage exposés par le service d'identité sont codés en dur |
| 3 | Une configuration pointe le service de facturation sur un port erroné ; sans effet aujourd'hui, la facturation étant désactivée par défaut |
| 4 | 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 bloquant au lancement |
| 5 | Le palier expert du kit d'agents est facturé au tarif du modèle le plus cher alors qu'il est exécuté sur le modèle intermédiaire |
#15.5 Statut
🟢 Livré · 🔴 Bloqué pour la sauvegarde de nouvelles configurations de facturation, en attente d'une clé de chiffrement provisionnée.
16. Collaboration
#16.1 Ce que c'est
Faire travailler plusieurs personnes sur la même spécification sans se marcher dessus, et laisser chaque équipe employer sa méthode.
#16.2 Comment KySpectra l'implémente réellement
Aucun diagramme à afficher
Diagramme 16 — flowchart
#Les espaces et les commentaires
Un espace produit regroupe des membres. Un fil de commentaires peut s'ouvrir sur n'importe quel objet, être commenté, résolu, puis rouvert. L'écriture exige au minimum le rang éditeur.
#Les revues et la séparation des devoirs
La machine à états de revue est réellement testée. Elle rejette une décision dont l'auteur est aussi le soumissionnaire. La décision exige le rang publieur, un rang au-dessus de la soumission.
| Élément | Valeurs réelles |
|---|---|
| Types de cible admis | 9, dont objet de spécification, artefact, diagramme, document d'exigences, livrable d'architecture d'entreprise, artefact de sécurité, code, contexte borné, agrégat |
| États | 5 : brouillon, soumis, changements demandés, approuvé, rejeté |
| Verdicts | 3 : approuvé, changements demandés, rejeté |
#La modélisation par domaine
Contextes bornés, carte de contextes avec arêtes typées, agrégats, et génération d'un diagramme d'agrégat par une fonction pure.
#Le métamodèle par projet
C'est le mécanisme qui permet à deux équipes d'employer deux méthodes différentes sur la même plateforme.
| Élément | Valeur réelle |
|---|---|
| Paquets intégrés | 17, version de catalogue 3 |
| Les paquets | Socle de développement piloté par la spécification, modèle de domaine, boîte à outils de spécification, grammaire d'exigences contrôlée, méthode de cycles courts, cadre d'agilité à l'échelle, méthode de deltas ouverts, développement piloté par le comportement, décisions d'architecture, modèle d'architecture à quatre niveaux, langage de modélisation d'entreprise, méthode d'architecture d'entreprise, cadre de classification, taxonomie documentaire, méthode de spécification exécutable, méthode de décomposition en tâches, et le socle de la méthode agentique interne |
| Activation | Un ou plusieurs paquets simultanément ; la référence résolue devient composite |
| Repli | Un projet vierge retombe sur le socle |
| Contrat de lecture | Un point d'accès unique de métamodèle résolu, consommé par le magasin de spécification et par le copilote |
Le catalogue est validé strictement à l'import : chaque type déclaré doit appartenir au vocabulaire canonique, et chaque relation au vocabulaire de relations.
#16.3 Ce qu'elle produit
Une conversation attachée aux objets, des décisions attribuables, une modélisation de domaine partagée, et une méthode de travail choisie par projet plutôt qu'imposée.
#16.4 Limites connues
| # | Limite |
|---|---|
| 1 | Aucun drapeau de fonctionnalité, aucun refus typé : le service est complet mais sans marge de configuration |
| 2 | Un service de collaboration injoignable fait retomber le copilote sur le socle par défaut, avec une source explicitement marquée « repli hors ligne » |
| 3 | La validation de conformité au métamodèle dépend de ce service : injoignable, elle renvoie un refus typé plutôt qu'un faux succès |
#16.5 Statut
🟢 Livré.
17. Ingestion documentaire
#17.1 Ce que c'est
Transformer les documents existants d'une organisation — cahiers des charges, notes, tableaux — en objets de spécification, sans importer ni erreur ni donnée personnelle.
#17.2 Comment KySpectra l'implémente réellement
Aucun diagramme à afficher
Diagramme 17 — flowchart
#Les formats réellement acceptés
| Format | Moteur | Statut |
|---|---|---|
| Markdown et texte | Décodage tolérant | ✅ Réel |
| Bibliothèque d'analyse ; document corrompu ou protégé ⇒ refus typé | ✅ Réel | |
| Traitement de texte | Paragraphes et tableaux | ✅ Réel |
| Image | Aucun ⇒ document créé, stocké, marqué dégradé, zéro candidat | ⚠️ Dégradation honnête |
Trois codes de refus typés existent : type non supporté, fichier illisible, fichier lu mais sans texte exploitable — le cas d'un document numérisé sans couche de texte.
Trois plafonds sont appliqués : fichier vide, fichier au-delà de 10 mébioctets, extension hors liste.
#La structuration est déterministe
Trois règles seulement, et une garantie forte :
| Entrée | Sortie |
|---|---|
| Tableau markdown | Une entité, dont les attributs sont les cellules d'en-tête |
| Titre | Une ancre de section ; le tout premier grand titre est ignoré comme titre de document |
| Puce, numéro ou phrase | Classée par précédence de marqueurs : contrainte, puis récit, puis exigence, puis élément d'interface |
Un texte ne correspondant à aucun marqueur n'est pas inventé en candidat. C'est la garantie qui empêche le pipeline de fabriquer du contenu.
#La barrière de renseignements personnels
Deux niveaux de détection :
| Niveau | Mécanisme |
|---|---|
| Document | Langue toujours détectée localement. Détection de renseignements personnels et de type de document, localement ou par le service d'apprentissage automatique selon la configuration |
| Extrait | Chaque candidat est marqué individuellement selon son extrait source |
Le détecteur local couvre courriel, carte de paiement avec somme de contrôle, numéro d'assurance sociale, téléphone, code postal et adresse réseau. Chaque constat porte un échantillon masqué ; la valeur brute n'est jamais persistée.
La barrière d'acceptation : accepter un candidat marqué exige une justification non vide, sous peine d'un refus typé. La justification est conservée dans l'enregistrement de revue. C'est le point de contrôle Loi 25 du pipeline.
#La validation humaine obligatoire
Quatre actions sont possibles, et une seule écrit dans le magasin de spécification :
| Action | Effet | Écriture |
|---|---|---|
| Modifier | Amende le titre, les attributs ou le type ; reste révisable | Non |
| Rejeter | Abandonne | Non |
| Relier | Résout un doublon vers l'objet correspondant | Non |
| Accepter | Barrière, création réelle, arête de conflit si nécessaire, indexation best-effort | Oui |
L'identifiant canonique est celui renvoyé par le magasin de spécification, jamais fabriqué. Un échec du magasin annule l'état local : il n'y a pas de demi-état.
Une garde commune interdit de réviser un candidat déjà décidé.
#Le document comme donnée, jamais comme instruction
Quand la génération assistée est activée, le document est encadré comme donnée externe non fiable, explicitement pas comme une instruction. C'est une frontière de confiance nommée dans le code.
#17.3 Ce qu'elle produit
Des objets de spécification réels, rattachés au projet, avec une provenance qui nomme le fichier d'origine, et une trace de qui a accepté quoi et pourquoi.
#17.4 Limites connues
| # | Limite |
|---|---|
| 1 | En configuration par défaut, le service tourne à 100 % en déterministe local : pas de génération assistée, pas de déduplication, pas de classification par apprentissage. C'est le chemin le plus fiable, mais sans enrichissement sémantique |
| 2 | Les images ne produisent aucun candidat |
| 3 | Aucun événement n'est publié sur un bus : toute la communication est synchrone |
| 4 | Sans cache, la clé d'idempotence est acceptée mais non dédupliquée |
#17.5 Statut
🟢 Livré.
18. Extensibilité
#18.1 Ce que c'est
Permettre d'ajouter des compétences, des invites et des outils à la plateforme sans modifier son code — et de les partager.
#18.2 Comment KySpectra l'implémente réellement
Aucun diagramme à afficher
Diagramme 18 — flowchart
#Ce qui est importable
| Type | Sources | Réalité |
|---|---|---|
| Compétence | Dépôt, archive, registre | ✅ Réel |
| Serveur et outils | Enregistrement direct, plus import d'un contrat d'interface produisant un descripteur d'authentification | ✅ Réel |
| Capacité d'invite | Lien gouverné vers un modèle du service d'orchestration d'invites | ✅ Réel |
| Rôle virtuel | Ne s'importe pas : il se crée, et seulement au périmètre plateforme | — |
#Le pipeline d'import, en sept étapes
| # | Étape | Comportement honnête |
|---|---|---|
| 1 | Provenance | Source, adresse, licence, référence et voie d'import sont enregistrées |
| 2 | Signature | Vérification cryptographique jamais faussée : échec ⇒ refus typé ; invérifiable ⇒ statut « non vérifié » assumé |
| 3 | Détection de secrets | Refus typé si un secret est trouvé dans le contenu |
| 4 | Classification de risque | Persistée à l'import : importé et non vérifié vaut risque élevé |
| 5 | Atterrissage | Visibilité globale, source « importé », statut brouillon |
| 6 | Validation statique | Détection de secrets et moindre privilège. Un constat bloquant maintient le brouillon et empêche la soumission |
| 7 | Soumission | Une validation propre soumet à revue. Jamais d'auto-approbation |
Un jeu de compétences curaté peut être ingéré, mais rejoue exactement le même pipeline entrée par entrée. Le code le dit : « ce n'est pas une insertion en lot, rien ne contourne le pipeline ». L'opération est idempotente et rapporte trois issues : importé, déjà présent, bloqué.
La découverte en ligne est strictement un aperçu : elle n'importe rien, n'écrit aucune ligne, et se limite à des hôtes autorisés. Source injoignable ⇒ retour dégradé explicite avec liste vide.
#Le cycle de vie
| Objet | États |
|---|---|
| Compétence et capacité d'invite | Brouillon, en revue, approuvé ou rejeté, révoqué |
| Serveur d'outils | Enregistré, en revue, approuvé, révoqué, en mauvaise santé — pas d'état rejeté : un rejet ramène à l'état enregistré |
| Vérification | Non vérifié, vérifié, échoué |
La révocation est une transition persistée avec propagation immédiate : toutes les liaisons sont désactivées et toutes les permissions supprimées.
#La place de marché
C'est le point à traiter avec prudence.
| Élément | Statut réel |
|---|---|
| Registre à trois niveaux avec catalogue global | 🟡 Code écrit et testé, drapeau éteint par défaut, non activé dans aucun manifeste |
| Adoption d'une entrée globale par une organisation | 🟡 Idem |
| Curation d'audience et duplication à la volée avec provenance | 🟡 Code écrit et testé, jamais déployé, jamais prouvé en ligne |
| Place de marché ouverte à des contributeurs externes | ⚪ Planifié. Le carnet de comparaison la positionne explicitement comme non aboutie |
#Les compétences génériques du dépôt
Quatre spécifications existent en Markdown : résumé de document, questions-réponses, extraction structurée, traduction bilingue. Deux sur quatre ont un exécutant. Et surtout : aucun mécanisme de chargement n'existe — aucun code du dépôt ne lit ces fichiers à l'exécution. Le registre effectif vit ailleurs, sous quatre formes dupliquées.
Conséquence opérationnelle honnête : un message contenant le mot « traduire » est routé vers un identifiant de compétence sans exécutant.
#18.3 Ce qu'elle produit
Un catalogue gouverné où chaque capacité porte sa provenance, sa licence, sa classe de risque, sa décision de revue et son périmètre d'activation.
#18.4 Limites connues
| # | Limite |
|---|---|
| 1 | Les deux drapeaux maîtres valent faux par défaut et ne sont activés nulle part |
| 2 | La place de marché avec audience ciblée n'a jamais été déployée ni prouvée en ligne |
| 3 | Le paquet de compétences génériques est de la documentation de conception, pas un moteur |
| 4 | Deux des quatre compétences génériques n'ont aucun exécutant |
| 5 | Un second jeu de compétences globales, en anglais, existe dans un autre service, sans aucun lien de code avec le premier |
#18.5 Statut
🟡 En cours. Le mécanisme de gouvernance est réel et complet ; son activation et la place de marché ne le sont pas.
Synthèse — les capacités, leur statut et leur preuve
| # | Capacité | Statut | Preuve principale |
|---|---|---|---|
| 1 | Rétro-ingénierie | 🟢 Livré, prouvé en production | Sept émetteurs, promotion automatique, analyse Python par arbre syntaxique |
| 2 | Ingénierie avant | 🟢 Livré | 63 types, 24 relations, 17 métamodèles |
| 3 | Maintenance et évolution | 🟢 Livré | Graphe avec preuve obligatoire, dérivation d'exigences depuis un incident |
| 4 | Tests et qualité | 🟢 Livré | Génération obligatoirement gouvernée, couverture calculée, données synthétiques |
| 5 | Copilote IA | 🟢 Livré | Cinq garde-fous, objets d'écriture proposés jamais appliqués |
| 6 | Apprentissage automatique | 🟢 Livré, sans apprentissage | Sept modèles déterministes enregistrés |
| 7 | Apprentissage profond | ⚪ N'existe pas | Aucun cadre, aucun poids, aucune ligne d'entraînement |
| 8 | Vision par ordinateur | 🟡 Traitement d'image classique | Trois modules, environ 310 lignes, zéro apprentissage |
| 9 | Gouvernance des agents | 🟢 Livré · 🟡 activation | Refus par défaut à quatre endroits, séparation des devoirs à trois étages |
| 10 | Personnel virtuel IA | 🟢 Phase 1 · ⚪ Phases 2-3 | Recrutement et assignation prouvés en navigateur réel |
| 11 | Protocole MCP et outils | 🟡 Contrat maison | 27 outils, dont 17 sur données d'exemple et 10 morts |
| 12 | Sécurité, conformité et audit | 🟢 Livré · 🔴 un blocage | Chaîne de hachage vérifiable, isolation par 404 |
| 13 | Observabilité | 🟢 Livré | Progression calculée jamais déclarée, 42 indicateurs |
| 14 | Déploiement et mise en ligne | 🟢 Kubernetes · 🟡 nuages · 🔴 identité | Six étapes, approbation distincte, retour arrière |
| 15 | Facturation, quotas et crédits | 🟢 Livré · 🔴 un blocage | Refus avant dépassement, reçu honnête |
| 16 | Collaboration | 🟢 Livré | 17 paquets de méthode, séparation des devoirs testée |
| 17 | Ingestion documentaire | 🟢 Livré | Validation humaine obligatoire, barrière de renseignements personnels |
| 18 | Extensibilité | 🟡 En cours | Pipeline d'import en sept étapes, place de marché non déployée |
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.