#Sommaire

Total : 48 fiches.

---

#1. Comment lire une fiche

#1.1 Le gabarit

Chaque fiche suit la même structure, sans exception :

#1.2 Les statuts

#1.3 Les deux styles d'enregistrement à la passerelle

La source de vérité du routage est un module unique, backend/api-gateway/src/core/registry.py. Il connaît deux styles :

Le montage scopé existe parce que tous les services de la vague 2 exposent des sous-ressources sous les mêmes espaces de noms partagés (/api/v1/projects/..., /spec-items, /audit, /metrics) : un enregistrement plat provoquerait des collisions.

#1.4 La convention de base de données

Une base par service, nommée ks_<slug>_<env> avec env ∈ {dev, qa, prod}. Les identifiants de connexion sont résolus dans cet ordre : variable DATABASE_URL, puis coffre de secrets au chemin secret/data/kyspectra/<env>/postgres/<slug>, puis variables d'environnement DB_*. Aucun secret n'est jamais écrit dans le dépôt.

⚠️ Piège transverse documenté. Le pilote asyncpg attend le paramètre ssl=, pas le sslmode= de libpq. Une chaîne de connexion portant sslmode= fait échouer le démarrage. Ce piège s'applique à tous les services.

---

#2. Carte générale des services

#2.1 Répartition

#2.2 Ports et montages — table complète

---

3. Partie A — Le châssis multi-locataire

---

#Fiche A1 — Passerelle d'interface api-gateway

Rôle en une phrase. Elle est la porte d'entrée unique de toute la plateforme : elle vérifie l'identité, résout le locataire, route vers le bon service et protège l'ensemble.

Problème résolu. Sans elle, chaque portail devrait connaître l'adresse de trente services, dupliquer la vérification de jeton, et réimplémenter la limitation de débit. Un seul endroit déclare une route ; un seul endroit refuse.

Ce qu'elle applique concrètement

---

#Fiche A2 — Service d'identité et de plan de contrôle user-service

Rôle en une phrase. Il détient les personnes, les organisations, les droits, les abonnements et les preuves de conformité en matière de vie privée.

Problème résolu. Une plateforme multi-locataire sans autorité unique sur « qui est qui, dans quelle organisation, avec quels droits » devient impossible à auditer. Ce service est cette autorité.

Le moteur de permissions en cascade

Chaque évaluation écrit une ligne dans le journal de permissions.

---

#Fiche A3 — Service exemple example-service

Rôle en une phrase. C'est le gabarit « dupliquez-moi » : un microservice CRUD complet, neutre de tout domaine, qui montre comment on écrit un service correct sur ce châssis.

Problème résolu. Créer un nouveau service demande normalement de retrouver les bonnes conventions : résolution du locataire, garde anti-usurpation, RBAC serveur, santé honnête, migration idempotente. Ici tout est déjà écrit, il suffit de renommer les entités.

---

4. Partie B — Les services de la vague 1 (cœur SDD)

---

#Fiche B1 — Magasin de spécification spec-service

Rôle en une phrase. Il détient la spécification comme structure de données : des objets typés, versionnés, reliés, et une machine à états qui interdit les raccourcis.

Problème résolu. Une exigence écrite dans un document meurt le jour où le document n'est plus lu. Ici, l'exigence est une ligne de base de données avec un identifiant canonique, un statut, des révisions et des arêtes vers ce qui la satisfait et ce qui la vérifie.

Le vocabulaire canonique, mesuré

L'identifiant canonique a la forme PROJ-TYPE-NNNN, avec une séquence à quatre chiffres minimum, immuable, jamais réutilisée, allouée par un compteur atomique en base.

---

#Fiche B2 — Copilote de spécification copilot-service

Rôle en une phrase. Il transforme une intention exprimée en langage naturel en objets de spécification validés, sous garde-fous, avec un tableau d'agents en direct.

Problème résolu. Écrire une spécification structurée à la main est lent et décourage. Dicter une intention et obtenir des objets typés, validés et rattachés supprime la barrière d'entrée — à condition que rien ne soit écrit sans validation.

La chaîne d'exécution, telle qu'écrite

création du run → run.started → appel du modèle → llm.completed avec le comptage de jetons → analyse et validation strictes, une seule relance corrective → spec.persisting → appel à spec-service → run.completed. Toute erreur produit un run en échec ; le magasin de spécification n'est appelé qu'après validation, donc aucun objet partiel n'est écrit.

Les cinq garde-fous

---

#Fiche B3 — Registre de champs dynamiques custom-fields-service

Rôle en une phrase. Il permet à chaque organisation cliente d'ajouter ses propres attributs à des entités existantes, sans migration de schéma.

Problème résolu. Deux clients n'ont jamais exactement les mêmes champs. Sans registre dynamique, chaque demande devient un changement de code et un déploiement.

---

#Fiche B4 — Pipeline d'ingestion documentaire ingestion-service

Rôle en une phrase. Il transforme un document téléversé en candidats de spécification, sous validation humaine obligatoire et sous barrière de renseignements personnels.

Problème résolu. Une organisation arrive avec des cahiers des charges en PDF et des tableaux Word. Les retranscrire à la main coûte des semaines. Les importer sans contrôle produirait une spécification fausse et exposerait des données personnelles.

Les dix étapes du pipeline

La barrière Loi 25. Accepter un candidat marqué comme contenant des renseignements personnels exige une justification non vide, sous peine d'un refus typé 422. La justification est conservée dans l'enregistrement de revue. Les échantillons de détection sont masqués : la valeur brute n'est jamais persistée.

---

#Fiche B5 — Service d'apprentissage automatique ml-service

Rôle en une phrase. Il sert des prédictions honnêtes : soit un calcul réel, soit un refus explicite — jamais une valeur inventée.

Problème résolu. Les autres services ont besoin de similarité, de triage, de prévision et de classification. Les centraliser évite sept implémentations divergentes et rend leur provenance auditable.

Les sept modèles enregistrés — et ce qu'ils sont vraiment

Les dégradations, telles qu'écrites

---

#Fiche B6 — Service d'expérience de portail portal-experience-service

Rôle en une phrase. Il fournit au portail client ses agrégats de page d'accueil, ses assistants pas à pas, ses tableaux de bord, ses vues sauvegardées, ses notifications et sa palette de commandes.

Problème résolu. Sans lui, chaque écran du portail ferait dix appels et recomposerait la même logique côté navigateur. Le service assemble une fois, côté serveur.

---

#Fiche B7 — Service de collaboration et de métamodèle collaboration-service

Rôle en une phrase. Il porte les espaces produit, les fils de commentaires, les revues avec séparation des devoirs, la modélisation par domaine, et le métamodèle propre à chaque projet.

Problème résolu. Une spécification sans conversation ni revue devient un monologue. Et un métamodèle unique imposé à tous les projets force chaque équipe à plier sa méthode. Ce service résout les deux.

Le catalogue de métamodèles intégrés — 17 paquets, version de catalogue 3

sdd-core · domain-model · spec-kit · kiro-ears · shape-up · safe · openspec · bdd · adr · c4-model · archimate · togaf · zachman · bmad-core · diataxis · tessl · task-master

Plusieurs paquets peuvent être actifs simultanément sur un même projet ; la référence résolue est alors composite. Un projet vierge retombe sur sdd-core. Le point d'accès GET /api/v1/metamodel/projects/{id}/resolved est le contrat lu par spec-service et par le copilote.

La séparation des devoirs, réellement codée. La machine à états de revue rejette une décision dont l'auteur est aussi le soumissionnaire. La décision exige le rang PUBLISHER. Neuf types de cibles de revue sont admis, cinq états et trois verdicts.

---

#Fiche B8 — Fabrique d'artefacts d'ingénierie artifact-service

Rôle en une phrase. Il génère et versionne les artefacts d'ingénierie — document d'exigences, UML, BPMN, ERD, ArchiMate, TOGAF, sécurité — et projette la documentation depuis la spécification.

Problème résolu. Les diagrammes vivent d'habitude dans des fichiers dessinés à la main, qui divergent du code dès la deuxième semaine. Ici, chaque artefact référence au moins un objet de spécification vérifié, et la documentation détecte sa propre dérive.

Les deux invariants portés par le code

1. Aucun artefact orphelin : chaque référence de spécification est vérifiée par un appel réel avant persistance, doublé d'une contrainte en base exigeant au moins une référence.
2. Aucun faux succès : magasin de spécification injoignable ⇒ 502 typé ; génération en échec ⇒ 502 typé ; moteur d'export absent ⇒ 501 honnête, jamais un fichier vide.

UML : le compte exact

Écarts connus de ce service

---

5. Partie C — Les services scopés de la vague 2

---

#Fiche C1 — Moteur de cycle de vie sdlc-service

Rôle en une phrase. Il pilote un projet d'un bout à l'autre : admission, découverte, spécification, conception, plan, construction, vérification, revue, livraison, exploitation, évolution, retrait.

Problème résolu. Les équipes traversent ces phases de toute façon, mais sans porte ni trace. Ici, chaque transition de phase est refusée si sa porte n'est pas satisfaite, et chaque promotion vers un environnement laisse une ligne.

---

#Fiche C2 — Service de test et de qualité test-quality-service

Rôle en une phrase. Il génère des tests depuis les exigences, les exécute, calcule une couverture reliée aux critères d'acceptation, et regroupe les échecs en causes.

Problème résolu. Une suite verte ne prouve rien si personne ne sait quelle exigence elle couvre. Et quarante tests rouges provoqués par une même cause font perdre une journée à trois personnes.

Ce qui est réel, ce qui ne l'est pas

---

#Fiche C3 — Fabrique de données de test test-data-factory-service

Rôle en une phrase. Il produit des jeux de données de test synthétiques, reproductibles et sans aucun renseignement personnel réel.

Problème résolu. Tester avec une copie de la base de production est la première cause de fuite de données. Tester avec trois lignes bricolées ne prouve rien. Ce service tranche les deux.

La conformité, telle qu'implémentée

---

#Fiche C4 — Configuration du produit généré product-config-service

Rôle en une phrase. Il décrit la pile technique, le style d'architecture, le découpage en services, les bibliothèques épinglées, la posture de sécurité et le modèle d'identité du produit que la plateforme fabrique.

Problème résolu. Sans contrainte déclarée, un agent génère du code dans la pile qu'il préfère. Ici, la configuration devient une contrainte de génération, et un artefact hors liste blanche est signalé.

Invariant structurel vérifié au chargement du module : la table de configuration d'authentification ne peut pas contenir de colonne de secret. Seul un chemin de coffre y est écrit. La garde est exécutée à l'import, pas seulement documentée.

---

#Fiche C5 — Configuration de la plateforme platform-config-service

Rôle en une phrase. Il est le magasin de configuration d'exécution de KySpectra elle-même : drapeaux de fonctionnalité, configurations de modèles et d'adaptateurs, politiques d'exécution et garde-fous.

Problème résolu. Changer un comportement en production sans redéployer, et pouvoir dire à un auditeur exactement quelle politique était active à quelle date.

Deux garanties inscrites dans le schéma

L'évaluation du rollout est déterministe : le seau est dérivé d'une empreinte stable de la paire clé de drapeau et identifiant de locataire, jamais d'un tirage aléatoire. Elle est donc uniforme et monotone : un locataire activé à un pourcentage donné le reste pour tout pourcentage supérieur.

L'évaluation de garde-fou est en refus par défaut, avec un ordre total de sélection du gagnant : priorité, puis le refus l'emporte sur l'autorisation, puis le locataire l'emporte sur le global, puis le motif le plus long, puis l'ordre alphabétique.

---

#Fiche C6 — Journal d'audit et conformité audit-compliance-service

Rôle en une phrase. Il tient un journal d'audit inviolable par chaîne de hachage, et produit des rapports de conformité Loi 25 sur une période.

Problème résolu. « Prouvez-moi que ce journal n'a pas été modifié » est une question à laquelle un fichier de logs ne peut pas répondre. Une chaîne de hachage vérifiable, si.

La chaîne, telle que calculée

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. 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.

Comment le journal se remplit. Un intergiciel partagé émet un événement d'audit par mutation réussie depuis n'importe quel service. Il suffit d'une ligne par service pour le brancher. Avant ce correctif, le journal existait mais restait vide.

Résidence des données : paramétrable, valeur par défaut « ca-qc », reportée dans chaque rapport.

---

#Fiche C7 — Tableau d'observabilité observability-board-service

Rôle en une phrase. Il calcule la progression réelle depuis les faits, évalue les seuils de niveau de service, et enregistre les brèches.

Problème résolu. Une progression déclarée à la main est une opinion. Une progression calculée depuis des critères d'acceptation vérifiés et des tâches terminées est un fait.

Trois invariants remarquables

Le catalogue d'indicateurs compte environ 42 entrées réparties en huit familles : flux, DORA, qualité, agents, coût, spécification, sécurité, fiabilité. Chaque entrée porte une formule évaluée 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.

⚠️ Écart d'affichage à connaître. Le tableau AgentOps de l'espace de travail du portail client ne lit pas ce service : il consomme les exécutions du copilote. Ce service porte sa propre piste d'activité, distincte.

---

#Fiche C8 — Facturation d'usage, budgets et crédits billing-usage-service

Rôle en une phrase. Il compte la consommation réelle, applique des budgets et des fenêtres de quota, et tient un grand livre de crédits en ajout seul.

Problème résolu. Laisser des agents consommer un modèle sans plafond est une facture surprise. Refuser après coup est trop tard. Ici, une charge qui ferait dépasser un budget est refusée avant d'être écrite.

Prix par modèle réellement semés en base — en crédits pour mille jetons, en entrée puis en sortie :

Configuration semée : seuils d'alerte à 50, 80 et 95 % ; crédits de grâce à 0 ; bascule de routage à 80 % ; drainage à 95 %.

La garantie d'honnêteté sur la facturation vit dans la bibliothèque partagée, pas ici. Quand aucun service de facturation n'est joignable, la pré-vérification renvoie un ticket non contraignant et le reçu porte metered=false avec la raison « facturation désactivée ». Aucun montant n'est inventé.

---

#Fiche C9 — Registre d'extensions et de capacités extension-registry-service

Rôle en une phrase. Il est le catalogue gouverné des compétences, des serveurs et outils du protocole MCP, et des capacités de prompt — avec revue par une personne différente, refus par défaut et journal d'appels.

Problème résolu. Donner un outil à un agent est une décision de sécurité. Sans registre, cette décision est prise par celui qui écrit le code, sans trace et sans revue.

Les trois niveaux réels

« Projet » n'est pas un niveau : c'est une valeur de la grammaire de liaison, aux côtés de « locataire » et « agent ».

Le refus par défaut, en trois endroits

1. La colonne d'effet d'une permission d'outil vaut deny par défaut : sans ligne explicite d'autorisation pour le triplet outil, agent, projet, l'appel est refusé.
2. Une capacité n'est offerte que si elle est approuvée et liée et non révoquée — l'appelant ne voit rien plutôt qu'une capacité fabriquée.
3. Au moment de l'appel, si le magasin de sessions est injoignable, le verdict est refus.

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, et exigence d'un identifiant d'acteur valide sous peine de refus « une décision doit être attribuable ». Approuver un sujet à risque élevé exige en plus une attestation de revue de sécurité.

Le plafonnement d'autonomie : le niveau effectif est le minimum entre le plafond du rôle et celui du plan. Une dégradation du service de droits retombe sur le niveau le plus bas — l'autonomie baisse en cas d'incertitude, jamais l'inverse.

Les secrets d'outils. La base ne stocke jamais une valeur de secret : seulement la forme non secrète et un chemin de coffre. Vingt noms de secret sont interdits hors des clés de coffre, huit en-têtes d'authentification sont interdits, et chaque chaîne passe un détecteur de secrets à fort signal. Le message de refus n'écho jamais la matière offensante.

---

#Fiche C10 — Graphe de dépendances dependency-graph-service

Rôle en une phrase. Il détient un graphe où chaque arête porte une origine et une preuve, et calcule des traversées, des cycles, des métriques de couplage et des rayons d'impact.

Problème résolu. « Si je change ceci, qu'est-ce qui casse ? » n'a de réponse fiable que si le graphe est bâti sur des faits sourcés, pas sur des suppositions.

L'invariant dur. Une arête doit porter une origine et une preuve non vide : la contrainte est en base, pas seulement dans le code. Onze niveaux de nœuds, onze types d'arêtes de base plus vingt-trois de traçabilité, six provenances possibles.

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 ; longueur de cycle maximale 200 ; nombre de chemins par défaut 50, plafond 200.

---

#Fiche C11 — Plan d'exécution des agents agent-runtime-service

Rôle en une phrase. Il détient l'état d'exécution de chaque run d'agent : suivi, points de reprise, moteur de politique en refus par défaut, flux d'activité rejouable, et exécution en tâche Kubernetes éphémère.

Problème résolu. Faire tourner du code produit par une IA sur une machine partagée est un risque. L'isoler dans une tâche jetable, non privilégiée, sans réseau sauf une adresse autorisée, avec un système de fichiers en lecture seule, ramène ce risque à un niveau tenable.

La posture de sécurité de la tâche, telle que rendue

Le moteur de politique en refus par défaut autorise onze motifs d'action et refuse tout le reste. Sont intentionnellement absents, 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. Chaque verdict est écrit en base.

Comparaison visuelle : différence pixel à pixel et indice de similarité structurelle, calculés sur des tableaux numériques. Activée par défaut ; désactivée, elle renvoie un 503 honnête.

---

#Fiche C12 — Rétro-ingénierie reverse-engineering-service

Rôle en une phrase. Il part d'un dépôt de code existant et en extrait des faits horodatés par fichier et par ligne, en infère des candidats de spécification avec confiance et preuve, et verrouille leur promotion derrière une validation.

Problème résolu. Reprendre un système dont personne ne connaît plus l'intention. C'est le maillon « Comprendre » de la chaîne de valeur, et le seul moyen de partir de l'existant plutôt que d'une page blanche.

Langages et formats : ce qui est vraiment analysé

Il n'existe aucun analyseur polyglotte dans le service : la recherche exhaustive ne trouve aucune bibliothèque de ce type. Le seul langage réellement compris est Python.

Le clone, tel qu'exécuté. Aucune bibliothèque intermédiaire : appel direct au binaire, arguments passés en liste, jamais par un interpréteur de commandes. Clone superficiel à une seule branche. Le jeton est injecté par une option de configuration à chaque invocation, jamais dans l'adresse ni dans la configuration du dépôt cloné. Le répertoire temporaire est supprimé dans un bloc de nettoyage garanti, même en erreur. Les messages d'erreur sont caviardés et tronqués.

---

#Fiche C13 — Service de déploiement deploy-service

Rôle en une phrase. Il modélise, garde et enregistre la chaîne construction, test, analyse, porte, déploiement, surveillance comme une machine à états ordonnée et non contournable — et il exécute chaque étape pour de vrai.

Problème résolu. Un déploiement sans décision approuvée et sans trace est un effet de bord. Ici, il devient une décision, avec un demandeur, un approbateur différent, une preuve et un retour arrière.

Les six étapes et ce qu'elles font vraiment

Les invariants d'ordre, portés par un module pur : une étape d'ordre inférieur non franchie bloque l'avancement ; les portes non franchies sont listées ; l'étape de déploiement ne se marque jamais à la main ; un seul déploiement par run.

Les quatre fournisseurs d'intégration continue générés : GitHub Actions, GitLab CI, Azure Pipelines, Jenkins. La génération est un module pur ; les secrets sont référencés par nom de secret du fournisseur uniquement. Côté commit réel, deux cibles de gestion de version sont supportées ; la troisième est honnêtement déclarée non supportée.

Ce qui est réel côté nuage : un mécanisme générique — n'importe quelle interface en ligne de commande de nuage exécutée dans une tâche avec les identifiants déposés. Il n'existe aucun exécuteur dédié par fournisseur ; le module de publication nuage ne fournit que des plans avec leurs prérequis.

---

#Fiche C14 — Synchronisation d'intégrations integration-sync-service

Rôle en une phrase. Il synchronise dans les deux sens avec deux outils de suivi du marché, en gardant la spécification comme source de vérité.

Problème résolu. Les équipes ne vont pas abandonner leur outil de tickets du jour au lendemain. Mais laisser cet outil écraser la spécification détruirait le modèle. La réponse est une proposition de changement, pas une écriture aveugle.

La vérification de signature est réelle : empreinte à clé sur le corps brut, comparaison à temps constant, quatre en-têtes acceptés par ordre de priorité, secret résolu au coffre avec repli sur variable d'environnement. Secret absent ⇒ requête rejetée, jamais validée par défaut. L'un des deux fournisseurs n'ayant pas de signature native, l'absence d'en-tête produit un rejet honnête.

L'idempotence est en base, par unicité de la paire système et identifiant de livraison — elle ne dépend pas de Redis. Une signature invalide est quand même enregistrée, marquée invalide, puis rejetée en 401.

---

#Fiche C15 — Orchestration de prompts prompt-orchestration-service

Rôle en une phrase. Il est le plan de contrôle des prompts : registre versionné, assemblage de contexte budgété et tracé, détection de secrets bloquante, et dispatch avec contrat de sortie.

Problème résolu. Un prompt écrit en dur dans un service est invisible, non versionné, non révisable, et peut fuiter un secret. Ici, il devient un objet gouverné.

Le budget de jetons, honnêtement décrit. L'estimation est une heuristique déterministe — le maximum entre le nombre de mots et le nombre de caractères divisé par quatre. Ce n'est pas un tokeniseur du modèle cible, et le code le dit. Le choix est assumé : la reproductibilité entre plateformes prime, car l'empreinte d'assemblage doit être stable.

L'invariant : aucune troncature silencieuse. Un dépassement de budget bloque l'envoi avec un refus typé, et les segments qui auraient dû sauter sont enregistrés sur l'envoi. On ne coupe jamais du contexte en douce.

Le contrat de sortie est vérifié par un validateur de schéma réel. Un schéma lui-même malformé est refusé avant tout appel de modèle. Une violation après une relance cadrée produit un conflit typé, avec l'envoi et le résultat conservés pour l'audit — jamais une analyse approximative.

La chaîne d'envoi : pré-vérification de crédits avant l'appel, envoi, validation, puis métrage réel — y compris en cas de violation de contrat, puisque le modèle a bien été invoqué. Une erreur de transport laisse l'envoi rejouable, sans charge fantôme.

⚠️ Écart relevé. La configuration pointe le service de facturation sur un port qui est en réalité celui du service de retours. Sans effet observable aujourd'hui, la facturation étant désactivée par défaut, mais à corriger.

---

#Fiche C16 — Service de retours produit feedback-service

Rôle en une phrase. Il capte les retours des utilisateurs finaux, les nettoie, les déduplique, les convertit en demandes d'admission réelles, et les rend publics sous forme de tableau, de feuille de route et de journal des changements.

Problème résolu. Les retours arrivent par courriel, par messagerie, par capture d'écran. Ils se perdent. Et quand une demande est livrée, personne ne prévient celui qui l'avait faite.

La machine à états : nouveau, en revue, planifié, en cours, livré ; avec deux sorties, fermé et fusionné. La réouverture est possible depuis « fermé ». L'arête de livraison est modélisée explicitement, jamais forcée en silence.

La priorisation combine portée, impact, confiance et effort. La portée suggérée est un plancher observé — votes plus abonnés — et reste modifiable. Les quadrants valeur contre effort viennent des médianes observées ou de valeurs documentées, jamais de données inventées.

---

#Fiche C17 — Orchestrateur de démonstration demo-orchestrator-service

Rôle en une phrase. Il provisionne, réinitialise et supprime un locataire de démonstration complet, de façon idempotente et strictement confinée.

Problème résolu. Faire une démonstration crédible demande des données cohérentes dans quinze services. Les créer à la main est long ; les créer par script sauvage risque de toucher un vrai client.

La garde de sécurité est la seule dépendance des routes d'écriture : drapeau éteint, mauvais locataire ou rôle insuffisant sont rejetés avant toute session de base et tout appel réseau. Chaque ressource provisionnée porte un statut honnête : semée, déjà existante, en erreur, ou ignorée.

---

6. Partie D — Le plan agentique

---

#Fiche D1 — Orchestrateur IA ai-orchestrator

Rôle en une phrase. Il compose des graphes d'exécution d'agents, tient un collège d'experts de cycle de vie, et pousse le catalogue d'agents vers le registre central.

Problème résolu. Un agent seul répond à une question. Une chaîne d'agents avec classification d'intention, vérification de crédit, point de validation humaine et formatage de sortie produit un résultat exploitable.

Les graphes réellement compilés

Neuf orchestrateurs de profil sont compilés, tandis que la configuration en déclare quinze : six profils n'ont pas de graphe compilé. Un validateur vérifie que chaque agent et chaque compétence référencés existent.

Le pont vers le registre central. Au démarrage, le service pousse toutes ses spécifications d'agents vers le registre central, qui est déclaré source de vérité. Il peut aussi tirer ce qui lui manque. Registre injoignable ⇒ le registre en mémoire reste intact — dégradation gracieuse.

Écarts honnêtes de ce service

---

#Fiche D2 — Registre central d'agents agent-registry-service

Rôle en une phrase. Il est la source de vérité persistée de tous les agents de la plateforme.

Problème résolu. Sans registre unique, personne ne peut répondre à « combien d'agents tournent chez nous, avec quelles capacités, et lesquels sont sains ». Le portail d'administration affichait zéro agent avant sa création.

---

#Fiche D3 — Cœur agentique et personnel virtuel agentic-core-service

Rôle en une phrase. Il détient le cycle de vie des tâches agentiques, la validation humaine, la coordination multi-agents, et le personnel virtuel IA : effectif, équipes, files de travail.

Problème résolu. Traiter un agent comme un employé — avec un rôle, une équipe, un niveau d'autonomie, une file de travail et un historique — plutôt que comme un appel de fonction anonyme.

Le personnel virtuel, phase 1 — ce qui existe vraiment

Les deux systèmes de validation humaine, non unifiés

Écarts assumés : ce service est hors du châssis partagé — configuration propre, création de schéma automatique pour les tables héritées, origines de partage de ressources ouvertes, base partagée plutôt que dédiée, adresse de cache codée en dur dans la valeur par défaut, aucune garde de rôle sur les routes héritées ni sur les connexions temps réel, et un jeton accepté puis jamais vérifié. La lecture de configuration de garde anti-boucle renvoie des valeurs codées en dur et ne relit pas ce que l'écriture a posé.

---

#Fiches D4 à D9 — Les six agents spécialisés

Les six services d'agents partagent une architecture identique : image durcie multi-étapes, utilisateur non privilégié, roue Python locale du kit de développement d'agents installée sans accès réseau, quatre routes racine, et un appel direct à la passerelle de modèles.

Constat transverse important. Aucun des six n'est enregistré à la passerelle d'interface : ils ne sont pas atteignables publiquement. Leur seule surface publique est le récapitulatif de flotte exposé par le cœur agentique. Leur route d'exécution n'a aucun appelant dans le dépôt : la flotte est câblée pour la synchronisation et le manifeste, pas encore pour l'exécution.

Constat de gouvernance. Les adresses du registre d'extensions et de l'orchestration de prompts sont vides par défaut dans les six configurations. La synchronisation centrale renvoie alors un conflit typé, et l'exécution retombe sur un chemin d'outils hérité, non filtré. Le champ de provenance des capacités indique honnêtement l'origine.

#Fiche D4 — Agent analyste analyst-agent-service (port 8100)

#Fiche D5 — Agent rédacteur writer-agent-service (port 8101)

#Fiche D6 — Agent réviseur reviewer-agent-service (port 8102)

#Fiche D7 — Agent extracteur extractor-agent-service (port 8103)

#Fiche D8 — Agent calculateur calculator-agent-service (port 8105)

#Fiche D9 — Agent conseiller advisor-agent-service (port 8108)

---

#Fiche D10 — Mémoire et recherche augmentée memory-rag-service

Rôle en une phrase. Il tient la mémoire des agents sur quatre niveaux et fournit une recherche hybride avec fusion de rangs.

Problème résolu. Un agent sans mémoire recommence à zéro à chaque appel. Un agent avec une mémoire non hygiénisée finit par se contredire ou par se faire empoisonner.

Les quatre niveaux réels

Trois protections réelles à l'écriture : déduplication exacte par empreinte, détection d'empoisonnement avec mise en quarantaine, et détection de conflit qui met en quarantaine le côté le moins fiable.

Écarts honnêtes

---

#Fiche D11 — Service de conversation chat-service

Rôle en une phrase. Il fournit un fil de conversation persistant avec diffusion de la réponse jeton par jeton.

Ce que ce service n'est pas. Ce n'est pas un chat agentique : la détection d'intention est purement lexicale, la compétence détectée n'est pas exécutée, et la réponse vient d'un modèle généraliste. L'exécution réelle n'a lieu que sur un événement dédié, dont l'adresse cible par défaut est morte. Il ne parle jamais aux six agents ni au service de mémoire : aucune mémoire longue, aucune recherche augmentée. Aucune authentification sur les routes ni sur la poignée de main temps réel ; le locataire et l'utilisateur sont acceptés depuis le client.

---

7. Partie E — Le plan MCP

---

#Fiche E1 — Passerelle d'outils mcp-gateway

Rôle en une phrase. Elle est la porte d'entrée unique de l'exécution d'outils par les agents, et le point d'application de la politique.

Problème résolu. Laisser chaque agent appeler directement chaque outil rend impossible toute allow-list, tout budget et tout journal.

Les deux plans qui coexistent

La posture d'échec fermé du chemin gouverné. Un refus est relayé verbatim et l'outil n'est pas exécuté. Une panne réseau du point de décision produit un refus. Une erreur serveur produit un refus. Toute erreur de résolution de secret produit un refus, sans exécution.

La résolution des secrets au moment de l'appel. Le point de décision ne voit jamais de 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 ne peuvent jamais écraser l'authentification résolue.

⚠️ Écart majeur. Le drapeau de portées à trois niveaux étant éteint par défaut, l'injection d'authentification amont est inerte en configuration par défaut.

---

#Fiche E2 — Serveurs d'outils mcp-servers

Rôle en une phrase. Ce sont cinq petits services par domaine, chacun exposant un catalogue d'outils que la passerelle agrège.

Inventaire honnête des 27 outils

Trois rectifications factuelles importantes

1. Les cinq serveurs sont des applications Python, pas Node.js. La documentation interne du projet affirme le contraire ; le dépôt dit l'inverse.
2. Le protocole MCP n'est pas implémenté : 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. Le schéma du registre autorise trois transports ; un seul existe.
3. 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é.

Autres absences structurelles : aucun test, aucun manifeste Kubernetes, aucune authentification entrante, aucune isolation par locataire — l'état est global au processus et partagé entre tous les locataires.

---

8. Partie F — Paquets partagés et surfaces web

---

#Fiche F1 — Kit de développement d'agents packages/agent-sdk

Rôle en une phrase. C'est la roue Python autonome qui donne aux agents leurs contrats typés, leurs clients de passerelle et leur liaison de capacités centrale.

Le fil conducteur : la liaison centrale de capacités. Un agent ne code pas en dur ses compétences, ses outils ni son invite : il résout tout depuis le registre d'extensions, en échec fermé. Une résolution impossible fait échouer le run avec le message « refus d'exécuter avec une gouvernance non résolue ».

Le budget de jetons est réel mais approximatif : le kit ne tokenise rien, il consomme les compteurs renvoyés par la passerelle et applique des plafonds dans le cache. La pré-autorisation est conservatrice, pas atomique : deux exécutions simultanées peuvent chacune passer avant d'incrémenter.

Écart notable : la classe de base d'agent et l'orchestrateur de domaine ne sont importés par aucun service. La surface réellement consommée se limite à l'intégration de flotte, aux en-têtes de service, au client de modèles et au résolveur de capacités.

Incohérence relevée : le palier expert est facturé au tarif du modèle le plus cher alors qu'il est exécuté sur le modèle intermédiaire.

---

#Fiche F2 — Compétences génériques packages/skills/global

Rôle en une phrase. Quatre spécifications de compétences transverses, en Markdown avec en-tête structuré.

Conséquence opérationnelle honnête : un message contenant le mot « traduire » est routé vers un identifiant de compétence sans exécutant.

---

#Fiche F3 — Système de conception frontend/packages/design-system

---

#Fiche F4 — Kit de portail frontend/packages/portal-shared

---

#Fiche F5 — Widget de collecte de retours frontend/packages/feedback-widget

Rôle en une phrase. C'est un composant autonome à déposer sur n'importe quel site client, qui capture un retour avec son contexte technique.

---

#Fiche F6 — Portail client frontend/client-portal

---

#Fiche F7 — Portail d'administration frontend/admin-portal

---

9. Synthèse par statut

#9.1 Décompte

#9.2 Les neuf fiches « En cours » et ce qui manque exactement

---

10. Ce qui n'existe pas, dit explicitement

Cette section existe parce qu'un inventaire qui ne dit pas ses trous n'est pas un inventaire.

---

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.