MEDICALCITY · Bayon

Bayon — MDM Agentique · wireframe v2.0

Deux surfaces : une console d'administration qui gouverne (agents, interfaces, flux), et une surface utilisateur qui fabrique et pilote (création d'interface, flux technique et métier).

Versionv2.0 · 28 juillet 2026
SourcesSpec Bayon v2.0 · Interfaces déployées 28/07 · Deck commercial
Succède àbayon_agenticmdm_wireframe_v1.0 (canvas de composants)
SystèmeTokens MEDICALCITY — bone / ink / rouge, coins carrés
Avertissement de périmètre — à lire avant tout chiffrage
  • La spécification Bayon v2.0 place explicitement hors périmètre : « pas de portail utilisateur final dans cette version ; la surface d'accès est le gateway MCP (machine-à-machine) et les outils internes ».
  • Ce wireframe conçoit donc une surface que la spec exclut. Il ne contredit pas la v2.0 : il définit ce qui devra devenir la v2.1 ou la v3. À arbitrer avant développement — et à répercuter dans la spec, sans quoi les deux documents divergeront.
  • Toutes les données affichées sont réelles, reprises de la fiche « Interfaces déployées » du 28/07 et de la spec : 9 interfaces en production, 5 planifiées, 53 outils MCP, 127 361 lignes mdm.stg_raw, 1 631+ exécutions journalisées.
00 — Principe directeur
Deux surfaces, une seule chaîne

La spec décrit une chaîne de valeur unique : Sources → workers → staging gouverné → résolution d'identité → survivorship → golden records → publication MCP. Les deux surfaces regardent la même chaîne, à deux hauteurs différentes.

QuestionSurfaceRôle
Qui a le droit de faire quoi ?AdminGouverne : registre des agents, classes d'autonomie, budgets, matrice HITL, journal WORM
Qu'est-ce qui circule, et est-ce juste ?UtilisateurFabrique et pilote : création d'interface, flux technique, flux métier, arbitrages
La chaîne, telle qu'affichée aux deux surfaces
1 · Source
Odoo, Brevo, LMS…
source_priority
2 · Worker
Filigrane
watermark
3 · Staging
Brut gouverné
stg_raw
4 · Identité
Résolution
identity_link
5 · Arbitrage
Survivorship
field_sources
6 · Golden
SCD2
is_current
7 · Publication
Gateway MCP
53 outils
Décision de conception
  • Ce ruban est le même composant dans les deux surfaces. En admin il porte les politiques ; côté utilisateur il porte les volumes et la santé. Un seul objet mental à apprendre.
01 — Accès et identité
B1Connexion/login
bayon.medicalcity.ai/login
Bayon
Se connecter
MDM agentique — accès réservé aux comptes provisionnés.
Adresse professionnelle
Mot de passe
Mot de passe oublié
ou
Pas de création de compte en libre-service. Bayon gouverne des référentiels d'entreprise : les comptes sont provisionnés par un administrateur ou par le fournisseur d'identité de l'organisation.
À l'implémentation
  • Entra ID est placé avant Google, délibérément. Bayon se vend à des organisations : Entra ID est le chemin d'entrée réel en établissement, Google celui des petites structures et de vos propres équipes. L'ordre visuel doit refléter la cible.
  • Aucune inscription en libre-service. Un outil qui attribue des classes d'autonomie à des agents ne s'ouvre pas par formulaire public.
  • Entra ID doit supporter la restriction par locataire et par domaine : n'accepter que les identités du tenant déclaré, sinon n'importe quel compte Microsoft ouvre une session.
  • Le SSO F12 est déjà partiellement livré côté plateforme — admin_sso_status et runbook Entra/Okta existent, la validation JWT live reste à brancher. Cet écran en est la façade humaine, pas un nouveau chantier d'identité.
  • Session JWT d'1 h, rafraîchissement 7 j, révocation immédiate — aligné sur TS-AUTH-001 du programme MCP. Ne pas créer un second modèle d'identité.
B2Vérification en deux étapes & élévation de session/login/mfa · /admin/*
À la connexion — second facteur
Vérification en deux étapes
Obligatoire pour tout compte ayant accès à la gouvernance : registre des agents, matrice HITL, journal WORM.
Code TOTP
Utiliser un code de secours
En cours de session — élévation
Action sensible — confirmation d'identité requise

Vous êtes sur le point de faire passer l'agent hermes_enrich de RECO à AUTO. Cette opération assouplit une règle de gouvernance et sera inscrite au journal WORM à votre nom.

Code TOTP
L'élévation vaut pour cette opération uniquement. Elle n'ouvre pas une session privilégiée durable.
Ce que l'authentification change dans le journal WORM
Jusqu'ici tous les acteurs étaient des agents. Un humain qui agit par l'interface devient lui aussi un acteur tracé.
seqType d'acteurActeurActionIdentité vérifiée par
1634humainrichard.yi@medicalcity.aipolicy_relax · hermes_enrich RECO→AUTOEntra ID + TOTP
1633humainrichard.yi@medicalcity.aihitl_approve · golden_mergesession (MFA < 15 min)
1632agentbrevo-syncgolden_updateBearer + scopes
À l'implémentation — le point qui dépasse l'écran de connexion
  • Le journal WORM doit distinguer acteur humain et acteur agent. Sans cette colonne, on perd la capacité de dire si une décision vient de la politique ou d'un contournement humain — c'est-à-dire l'essentiel de ce que la gouvernance prétend prouver.
  • Assouplir une règle exige une élévation ; la durcir non. Passer OBLIG → AUTO réduit le contrôle : c'est l'opération à protéger. L'inverse peut rester fluide.
  • L'élévation est par opération, jamais une session privilégiée qui reste ouverte.
  • Le mode d'authentification est inscrit dans l'entrée d'audit — « Entra ID + TOTP » n'a pas la même valeur probante qu'une session héritée. Un auditeur le demandera.
  • Ne pas dupliquer les rôles. Les profils Bayon dérivent de TS-AUTH-003 du programme MCP (owner, admin, developer, viewer) : la gouvernance des agents relève de l'admin, la fabrique d'interfaces du developer, le pilotage technique de l'exploitant. Un second référentiel de rôles serait une dette immédiate.
02 — Console d'administration · gouvernance
A1Console de gouvernance/admin
bayon.medicalcity.ai/admin
Console de gouvernance
Instance de production · 28 juillet 2026, 12:25 UTC
fail-closed actif R. YI · admin · MFA ✓ 4 min
Agents enregistrés
12
9 AUTO · 2 RECO · 1 OBLIG
Exécutions journalisées
1 631
append-only, non modifiable
Budget consommé
62 %
agrégé sur la journée
Chaîne WORM
Intacte
vérifiée à 12:00 UTC
Décisions en attente d'humain
AgentOutilClasseDepuis
brevo-syncgolden_mergeRECO4 minArbitrer
hermes_enrichfield_overrideRECO18 minArbitrer
agent-inconnu—OBLIG2 hExaminer
La troisième ligne est un cas fail-closed : agent absent du registre, ramené d'office en OBLIG. Ce n'est pas une erreur, c'est la politique qui s'applique.
Santé des interfaces
InterfaceCadenceDernier cycleÉtat
Odoo → Bayon (CDC)temps réelcontinusain
Brevo ⇄ Bayon60 s10:20:34sain
Moodle → Bayon60 s12:24:02sain
Gateway MCPà la demande12:25:102 incidents 26–28/07
Charge du box — risque connu au registre

PostgreSQL à 150 % CPU sur 2 vCPU. Impact : indisponibilité intermittente des outils MCP. Mitigation en cours : watchdog et redimensionnement.

À l'implémentation
  • La console n'est pas un tableau de métriques, c'est une file de décisions. Le premier bloc utile est « ce qui attend un humain » — tout le reste est contexte.
  • Le fail-closed doit se lire comme une politique, jamais comme une panne : un agent inconnu apparaît en OBLIG avec la mention de la règle appliquée, pas dans une liste d'erreurs.
  • L'état de la chaîne WORM porte l'horodatage de la dernière vérification. Sans date, l'indicateur ne vaut rien.
A2Registre des agents — policy-as-data/admin/agents
bayon.medicalcity.ai/admin/agents
Registre des agents
Table SCD2 mdm.agent_registry — toute modification crée une version, aucune n'écrase.
Tous (12)AUTO (9)RECO (2)OBLIG (1)Suspendus (0)Budget > 80 %
agent_keyNomVer.ClasseOutils autorisésBudget jourConsomméÉtat
bayon-ingestIngest MDMv3.4AUTOstg_raw, golden_*, identity_link5 0001 204 · 24 %actif
brevo-syncSynchronisation Brevov2.1AUTOstg_raw, contacts_out2 8801 440 · 50 %actif
lms-syncMoodle + Tutor LMSv3.4AUTOstg_raw, lms_new2 8801 437 · 50 %actif
hermes_enrichEnrichissement HERMESv1.2RECOgolden_person, field_override400338 · 85 %budget haut
mcp-gatewayGateway MCPa65e29cAUTO53 outils · lectureillimité—actif
agent-inconnunon enregistré—OBLIGaucun0—fail-closed
Un agent absent du registre n'est jamais rejeté silencieusement : il apparaît ici, en OBLIG, avec la règle qui l'y a placé.
À l'implémentation
  • Aucune modification en place. Changer une classe ou un budget crée une nouvelle version SCD2 : l'écran doit le dire au moment de l'action, et proposer l'historique des versions sur la fiche.
  • La colonne « consommé » est lue depuis mdm.agent_execution, pas depuis un compteur applicatif — c'est la même source que la politique d'exécution.
  • Un agent à plus de 80 % de budget bascule visuellement avant d'être bloqué. Découvrir l'épuisement au blocage est un défaut d'exploitation.
A3Matrice HITL & journal WORM/admin/hitl · /admin/worm
Matrice HITL — outil × classe d'autonomie
Croise l'outil appelé et la classe de l'agent pour décider à l'exécution.
OutilAgent AUTOAgent RECOAgent OBLIG
mdm_identity_searchAUTOAUTOOBLIG
golden_mergeRECORECOOBLIG
field_overrideRECOOBLIGOBLIG
reconcile_deletesOBLIGOBLIGOBLIG
La ligne reconcile_deletes est OBLIG partout : une suppression ne s'automatise pas, quelle que soit la confiance accordée à l'agent.
Journal WORM — mdm.worm_audit
chaîne vérifiée · 1 631 entrées · GENESIS → h:9f2c…
seqActeurActionprev_hashhash
1631brevo-syncgolden_updatea71b…9f2c…
1630lms-synclms_new55e0…a71b…
1629mcp-gatewaytool_callc108…55e0…
Aucune action d'édition ici

Pas de menu contextuel, pas de suppression, pas de correction. UPDATE et DELETE sont révoqués pour les rôles applicatifs : l'interface ne doit jamais laisser croire l'inverse.

À l'implémentation
  • La matrice est éditable par l'admin, mais chaque changement est lui-même une entrée WORM : qui a assoupli quelle règle, et quand.
  • La vérification d'intégrité recalcule la chaîne côté serveur et affiche le rang de la première rupture s'il y en a une. Un « OK » sans date ni portée n'est pas une preuve.
03 — Surface utilisateur · fabrique & pilotage
U1Mes interfaces/interfaces
bayon.medicalcity.ai/interfaces
Mes interfaces
9 en production · 5 planifiées · toutes suivent la même méthode en sept étapes
#InterfaceSensCanalCadenceFiligrane / dernier cycleSanté
1Odoo → Bayon miroir CDCentrantréplication logiquetemps réelcontinusain
2Odoo RH → Bayon minimiséentrantmême canal CDCtemps réelcontinusain
3Bayon → Brevosortantworker brevo-sync60 s10:20:34 UTCsain
4Brevo → Bayonentrantworker + watermark60 s07:31:14 UTCsain
5Tutor LMS → Bayonentrantworker lms-sync60 swp_users.IDsain
6Moodle → Bayonentrantworker lms-sync60 stimemodifiedsain
7Bayon → Gateway MCPsortantFastMCP · Bearerà la demande53 outils exposés2 incidents
8Agents HERMES → BayonentrantINSERT append-onlyà chaque exécution1 631 exécutionssain
9Bayon → Sauvegarde S3sortantpg_dump chiffréquotidienrétention 14 jsain
—Dedalus (DPI) → BayonentrantFHIR R4 · OAuth2—comité 02/08planifiée
À l'implémentation
  • La colonne filigrane est le seul indicateur qui dit si une interface avance vraiment. Un service « running » dont le watermark ne bouge plus est en panne silencieuse — c'est le mode de défaillance le plus coûteux d'une chaîne CDC.
  • Les interfaces planifiées figurent dans la même liste, grisées. Les cacher dans un autre écran empêche de voir le plan.
U2Créer une interface — assistant en 7 étapes gouvernées/interfaces/nouvelle
bayon.medicalcity.ai/interfaces/nouvelle
Nouvelle interface — Scribe → Bayon
Chaque étape correspond à une garantie de la plateforme. Aucune ne peut être sautée.
1Déclarer la source
2Worker & filigrane
3Enregistrer l'agent
4Identité & survivorship
5Matrice HITL
6Traçage
7Publication
Étape 3 — Enregistrer l'agent au registre
Garantie apportée : aucune exécution hors politique. En l'absence d'enregistrement, l'agent est ramené en OBLIG.
agent_key
Classe d'autonomie
Scribe remonte des métadonnées de comptes rendus : RECO le temps d'observer les arbitrages.
Budget quotidien
Priorité de source
Outils autorisés stg_rawidentity_linkgolden_mergefield_override
Les outils non cochés seront refusés à l'exécution, pas ignorés.
Ce que l'étape garantit
ÉtapeGarantie
1 · SourcePosition d'arbitrage explicite et révisable
2 · FiligraneIncrémental sans doublon, reprise sur incident
3 · AgentAucune exécution hors politique ; fail-closed
4 · IdentitéUn seul référentiel canonique, chaque champ tracé
5 · HITLAUTO / RECO / OBLIG selon outil et classe
6 · TraçageAuditabilité totale, coûts mesurés, chaîne WORM
7 · PublicationGolden records SCD2 exposés via le gateway
Simulation avant activation

L'interface démarre en lecture seule : le worker tourne, remplit stg_raw, calcule les arbitrages — sans jamais écrire de golden. L'utilisateur voit ce qui serait arbitré avant d'autoriser l'écriture.

À l'implémentation — le cœur du produit
  • L'assistant n'est pas un formulaire, c'est la méthode §3.1 rendue visible. Chaque étape affiche la garantie qu'elle apporte : l'utilisateur comprend pourquoi on lui demande une information, et la gouvernance cesse d'être vécue comme une friction.
  • Aucune étape sautable, et l'ordre est contraint : déclarer un agent avant d'avoir un filigrane n'a pas de sens.
  • Le mode simulation (lecture seule) est ce qui rend l'outil utilisable par un non-développeur : on voit les arbitrages projetés avant d'autoriser la moindre écriture. C'est aussi ce qui permet de vendre l'outil — la démonstration ne risque rien.
  • À la validation finale, l'interface produit une déclaration (source_priority + worker + agent_registry + mapping), pas du code. C'est la promesse « une interface n'est pas un connecteur codé, c'est une déclaration gouvernée ».
U3Pilotage d'un flux — lecture technique et lecture métier/interfaces/moodle
bayon.medicalcity.ai/interfaces/moodle
Moodle → Bayon
worker lms-sync · agent AUTO · priorité de source 30
Flux techniqueFlux métier
Source
mdl_user
timemodified
Worker
lms-sync
60 s
Staging
stg_raw
+38 aujourd'hui
Identité
email / lms_new
31 liés · 7 créés
Arbitrage
survivorship
3 conflits
Golden
golden_person
SCD2
Lecture technique — l'exploitant
IndicateurValeur
Dernier cycle12:24:02 UTC · il y a 41 s
Filigranetimemodified = 1785312842
Cycles / 24 h1 437 · 0 échec
Lignes staging+38 aujourd'hui · 127 361 au total
Budget agent1 437 / 2 880 · 50 %
Rejeu possibleoui, depuis le filigrane (PR-9)
Lecture métier — le responsable de la donnée
Ce que le flux a décidé, pas ce qu'il a transporté.
PersonneChampRetenuÉcartéRègle
M. Dupontnomres_partnermoodlepriorité 10 < 30
Mme Bergeremailres_partnermoodlepriorité 10 < 30
M. Ndiaye—golden créé—règle lms_new
3 conflits d'arbitrage aujourd'hui

Moodle propose une valeur différente d'Odoo sur un champ où Odoo est prioritaire. La valeur perdante est conservée et consultable — rien n'est détruit.

À l'implémentation — la décision la plus importante de ce wireframe
  • Un flux se lit de deux façons, et elles ne s'adressent pas aux mêmes personnes. L'exploitant veut des cycles, un filigrane, un débit, une capacité de rejeu. Le responsable de la donnée veut savoir quelle valeur a gagné, laquelle a perdu et pourquoi. Fondre les deux dans un tableau de bord unique produit un écran que personne ne lit.
  • La bascule est un commutateur en tête d'écran, pas deux pages distinctes : c'est le même flux, vu à deux hauteurs.
  • La colonne « écarté » est indispensable : la promesse de survivorship n'est crédible que si la valeur perdante reste consultable.
  • « Rejouer depuis le filigrane » est l'action la plus utile de tout le produit et doit être atteignable en un clic depuis l'écran du flux — c'est la procédure de reprise après incident.
04 — Proposition : la console est un client MCP
P1Réconcilier l'interface humaine avec « la surface d'accès est le gateway MCP »
Principe proposé

La console n'accède jamais aux tables mdm.* directement. Chaque action de l'interface est un appel d'outil sur le gateway MCP, au même titre qu'un appel d'agent. La surface d'accès reste unique : la spec v2.0 n'est pas contredite, elle est étendue à un nouveau type de client.

Sans la proposition — deux portes
Agents
→ gateway
gouverné
Console
→ SQL direct
non gouverné
  • La matrice HITL, les budgets et les allowlists devraient être réimplémentés côté console.
  • Deux implémentations de la même règle divergent toujours, et c'est la plus permissive qui gagne.
  • Le journal WORM ne verrait plus qu'une partie des décisions.
Avec la proposition — une seule porte
Agents
→ gateway
gouverné
Console
→ gateway
gouverné
  • La gouvernance est héritée, pas réécrite : HITL, budgets, allowlist et WORM s'appliquent d'office.
  • Un bouton de l'interface qui n'a pas d'outil correspondant n'existe pas — la surface humaine ne peut pas dépasser la surface gouvernée.
  • La console devient la démonstration vivante du produit : notre propre back-office passe par la gouvernance que nous vendons.
Identité déléguée — ce qui remplace la colonne « type d'acteur » de l'écran B2

Plutôt que d'introduire un acteur humain à côté des agents, la console est un agent enregistré — bayon-console — qui agit pour le compte d'un principal humain. L'entrée WORM porte les deux, et le modèle d'audit reste homogène.

Champ WORMAppel d'agentAction depuis la console
actorbrevo-syncbayon-console
on_behalf_of— (aucun)richard.yi@medicalcity.ai
auth_methodBearer + scopesEntra ID + TOTP
autonomy_classAUTO (registre)classe de l'outil × rôle du principal
Conséquence : bayon-console a sa propre allowlist et son propre budget. Une console compromise reste bornée par la politique, exactement comme un worker.
Ce qu'il faut ajouter au catalogue d'outils

Les 53 outils en production sont majoritairement en lecture. Une console qui gouverne doit écrire — donc étendre le catalogue, jamais le contourner. Chaque nouvel outil est lui-même classé dans la matrice HITL : c'est la méta-gouvernance.

ÉcranOutil à ajouterClasse proposéeJustification
A2 Registreadmin_agent_upsertRECOCrée une version SCD2 ; réversible et tracée
A2 Registreadmin_policy_relaxOBLIGRéduit le contrôle — élévation de session exigée
A3 Matriceadmin_hitl_matrix_setOBLIGModifie la règle qui arbitre toutes les autres
A1 Filehitl_approve / hitl_rejectRECOL'humain est déjà dans la boucle ; on trace sa décision
U2 Assistantinterface_declareRECOProduit une déclaration, pas du code
U2 Assistantinterface_simulateAUTOLecture seule par construction : aucun golden écrit
U3 Pilotageworker_replayRECORejeu idempotent depuis le filigrane (PR-9)
U3 Pilotageworker_suspend / resumeRECOInterrompt un flux de production
U3 Métiergolden_conflict_listAUTOLecture des arbitrages et des valeurs écartées
A3 WORMadmin_audit_verifyAUTOExiste déjà — à réutiliser tel quel
Amendement à porter dans la spec §1.3

Texte actuel : « Pas de portail utilisateur final dans cette version : la surface d'accès est le gateway MCP (machine-à-machine) et les outils internes. »

Texte proposé : « La surface d'accès reste le gateway MCP. La console d'administration et la surface de fabrique en sont des clients, au même titre qu'un agent : elles n'accèdent à aucune table directement, chaque action est un appel d'outil gouverné, et elles s'exécutent sous l'identité déléguée bayon-console pour le compte d'un principal humain authentifié. »

Le coût de la proposition — à assumer
  • Le gateway devient un point de défaillance unique pour l'interface. Il a connu deux incidents les 26 et 28 juillet (tools/list figé, résolus par redémarrage). Le watchdog planifié M1 cesse d'être un confort : il devient un prérequis à l'ouverture de la console.
  • Une latence supplémentaire par action, contre une garantie de non-contournement. Le compromis est favorable pour un outil de gouvernance, il le serait moins pour une saisie de masse.
  • Le budget de bayon-console doit être dimensionné : une console active consomme des appels, et l'épuiser bloquerait l'interface.
Pourquoi cette proposition plutôt qu'une autre
  • Votre spec écrit que le gateway « ne contourne jamais la gouvernance — il la consomme ». Une console en accès direct à la base ferait exactement l'inverse, et viderait de sa substance l'argument que vous vendez.
  • Elle transforme une contrainte en preuve : pouvoir dire à un client « notre propre back-office est soumis à la gouvernance que nous vous vendons, et son journal le montre » vaut mieux qu'une démonstration.
  • Elle borne le risque : une console compromise est un agent compromis — allowlist, budget, classe d'autonomie s'appliquent, et le fail-closed joue.
  • Elle a une conséquence de conception forte : un bouton sans outil correspondant ne peut pas exister. La feuille de route de l'interface devient la feuille de route du catalogue d'outils, ce qui discipline les deux.
05 — Ce qui reste à trancher
QuestionEnjeuStatut
Ouvrir une surface utilisateur ?La spec v2.0 exclut explicitement un portail utilisateur final. Ce wireframe le conçoit. Décision produit préalable à tout développement, et mise à jour de la spec.à trancher — bloquant
Qui peut créer une interface ?L'assistant U2 crée un agent et lui attribue une classe d'autonomie : c'est un acte de gouvernance. Un utilisateur métier peut-il le faire seul, ou l'étape 3 exige-t-elle une validation admin ?à trancher
Multi-tenantF8 (tenants + RLS) est planifié M3. Les deux surfaces supposent un tenant unique. Le sélecteur de tenant change la navigation — mieux vaut le prévoir maintenant que le rétrofitter.dépend de M3
Édition de la matrice HITLAssouplir une règle est plus sensible que la durcir. Faut-il une double validation pour tout passage OBLIG → RECO → AUTO ?à trancher
Provisionnement des comptesEntra ID permet le rapprochement automatique des utilisateurs par groupe de sécurité. Fait-on confiance aux groupes du client pour attribuer un rôle Bayon — y compris l'accès au journal WORM — ou exige-t-on une attribution explicite côté Bayon ?à trancher
Durée de validité de la MFACombien de temps une vérification reste-t-elle valable avant qu'une action sensible en exige une nouvelle ? Quinze minutes est retenu dans le wireframe, à confirmer.à trancher
Sort du wireframe v1.0Le v1.0 est un canvas de composants (typo, couleurs, boutons), pas des écrans. Il reste utile comme planche de style, mais il n'est pas au système de tokens MEDICALCITY.à aligner