Guide administrateur complet — plan de contrôle KySpectra

#Sommaire

---

#1. Rôle de l'administrateur et périmètre du plan de contrôle

#1.1 Ce qu'est le portail d'administration

Le portail d'administration de KySpectra est un plan de contrôle. Il ne sert pas à produire du logiciel : il sert à gouverner la fabrique qui le produit. Vous y décidez qui existe, qui peut agir, dans quelles limites, avec quels modèles de langage, sous quelles politiques d'exécution, et vous y prouvez après coup que ces décisions ont bien été appliquées.

Techniquement, le portail est un site entièrement statique, rendu côté navigateur (frontend/admin-portal, Next.js 15.1.6, React 19, export statique). Il ne détient aucune donnée : chaque panneau interroge en direct un microservice du plan de contrôle et affiche la réponse réelle. Quand un service ne répond pas, l'interface affiche un état d'indisponibilité explicite — jamais une valeur de remplacement.

Cette règle est structurante et vous la retrouverez partout dans ce guide : l'interface ne fabrique jamais de donnée. Un compteur à zéro signifie zéro mesuré ; un tiret (—) signifie « non renseigné » ; un encadré « indisponible » signifie que la sonde a échoué. Aucune de ces trois situations n'est déguisée en succès.

#1.2 Ce qui distingue le portail d'administration du portail client

Point de vocabulaire. Il n'existe pas de « portail business » distinct. C'est une persona à l'intérieur du portail client. Ne l'annoncez jamais comme une troisième application.

#1.3 Les quatre groupes de destinations

La barre latérale regroupe les seize destinations selon quatre intentions d'exploitation. L'ordre ci-dessous est celui du code (src/components/nav.tsx), et un test unitaire le verrouille : nav.test.ts affirme que la navigation expose exactement seize destinations, sans doublon.

⚠️ La destination Workforce n'a pas de libellé traduit. Voir §3.13 et §9 : c'est un écart réel, visible à l'écran.

#1.4 Le contrat d'honnêteté du plan de contrôle

Sept comportements observables constituent le contrat que vous administrez. Ils ne sont pas des slogans : chacun se vérifie dans l'interface.

#1.5 Vue d'ensemble du plan de contrôle

---

#2. Accès, environnements, authentification et rôles

#2.1 Les trois environnements

Points d'attention par environnement :

1. Développement — la résolution de noms externes depuis les conteneurs est défaillante ; certains parcours passant par le tunnel dev-api.kyrieva.com ne routent pas. Le cluster de développement est également à saturation : une mise à jour d'un service peut se bloquer si la stratégie de déploiement exige un conteneur supplémentaire avant d'en retirer un. Symptôme : la version en ligne ne change pas alors que le déploiement est « réussi ».
2. Qualification — environnement de répétition. Toute modification de politique, de garde-fou ou de drapeau doit y être répétée avant la production.
3. Production — l'utilisateur final teste directement ici. Une modification de production n'est jamais « seulement un essai ».

#2.2 Les deux modes d'authentification

Le mode est choisi au moment de la construction du portail, par la variable NEXT_PUBLIC_AUTH_MODE. Il n'est pas modifiable depuis l'interface.

Implication de sécurité, à énoncer sans détour. En mode dev-headers, n'importe quel opérateur ayant accès à l'URL peut se déclarer administrateur plateforme en cochant une case. Le contrôle d'accès du portail devient purement décoratif ; seul le contrôle serveur subsiste, et celui-ci fait lui aussi de dev-headers sa valeur par défaut côté backend. Une exposition publique en mode dev-headers équivaut à une absence d'authentification.

Corollaire opérationnel : le mode du portail et le mode du backend doivent être identiques. Un portail construit en dev-headers pointé vers un backend en jwt provoque une avalanche de 401 que le navigateur présente souvent comme une erreur de partage de ressources entre origines. L'inverse — portail jwt, backend dev-headers — produit une connexion réussie suivie d'écrans vides, car le jeton n'est jamais lu comme autorité.

#2.3 Paramètres Keycloak du portail d'administration

⚠️ Divergence documentée. La configuration partagée du backend décrit le domaine d'identité réellement exploité comme sso et qualifie kyspectra de domaine résiduel. Avant toute bascule en jwt, faites trancher ce point : un domaine d'identité erroné produit un échec de vérification de signature et un redémarrage en boucle de la passerelle.

#2.4 Les trois rôles plateforme

Les rôles plateforme sont distincts de l'échelle métier VIEWER → EDITOR → PUBLISHER → ADMIN → OWNER que vous attribuez aux utilisateurs d'un locataire. Ne les confondez jamais.

#2.5 La matrice des seize capacités

Chaque bouton d'écriture du portail est rattaché à une capacité sémantique. La matrice ci-dessous est celle du code (src/lib/rbac.ts), sans interprétation.

Comment la garde se manifeste à l'écran. Un bouton dont la capacité n'est pas accordée n'est pas caché : il est désactivé, et son infobulle affiche l'un des deux messages suivants.

• Requiert le rôle Administrateur plateforme.
• Requiert le rôle Opérateur ou Administrateur plateforme.

Ce choix est délibéré : l'opérateur voit ce qui existe et comprend pourquoi il ne peut pas l'exécuter. Le serveur reste l'autorité. Le blocage visuel n'est qu'une politesse ; il n'a jamais valeur de contrôle de sécurité.

#2.6 Choisir le locataire actif

Presque toutes les destinations sont portées par un locataire. Sans locataire sélectionné, l'écran affiche un garde-fou plutôt que des données :

Aucun locataire sélectionné — « Renseignez l'identifiant (UUID) du locataire à administrer via le sélecteur en haut à droite. En développement, l'authentification s'effectue via l'en-tête X-Tenant-ID. »

Procédure :

1. Repérez le sélecteur Locataire (tenant) dans la barre supérieure, à droite.
2. Collez l'identifiant du locataire au format UUID.
3. La sélection est persistée localement sous la clé spx-admin-tenant — elle survit au rechargement de la page, pas au changement de navigateur ou de poste.
4. Alternative : ouvrez Locataires, repérez la ligne voulue et cliquez Sélectionner. La ligne du locataire courant affiche « Ce locataire est le locataire courant. » au lieu du bouton.

Le client d'appel refuse localement toute requête portée sans locataire, avec le code 428 tenant_required et le message « Aucun locataire sélectionné. ». La requête n'est pas envoyée : c'est un garde local, pas un échec réseau.

Trois surfaces échappent à cette règle :

#2.7 L'identité agissante et le garde 428

Les actions de gouvernance exigent un acteur nommé. Si vous tentez une décision sans identité agissante définie, le client refuse localement avec 428 actor_required :

« Aucune identité Platform-Admin définie. Renseignez l'identifiant de l'administrateur agissant (X-User-ID) — une action de gouvernance doit être attribuable (séparation des tâches). »

En mode jwt, cette identité provient du jeton et le problème ne se pose pas. En mode dev-headers, vous devez la saisir sur la page Configuration.

#2.8 Deux routes vers les services : passerelle ou direct

Le portail sait joindre chaque service de deux façons. La règle de résolution est stricte et lisible sur la page Configuration.

La colonne URL cible de la page Configuration affiche la cible complète et une pastille passerelle ou direct. C'est votre premier réflexe de diagnostic quand un panneau reste vide.

Les segments de portée injectés, tels que définis dans le code :

Le tableau de santé de la page État système ne surveille que neuf de ces dix services : demo en est exclu, puisqu'il ne fait pas partie du chemin critique d'exploitation. Un test unitaire (config.test.ts) verrouille ce nombre.

---

#3. Les seize destinations du plan de contrôle, une par une

Chaque fiche suit le même gabarit : objet, ce que vous voyez, actions pas à pas, contraintes réelles, effets de bord, permissions, erreurs, écarts.

#3.1 État système — /overview

Libellé de navigation : État système · Groupe : Supervision · Sous-titre : « Santé des services et magasins polyglottes, agrégats du locataire sélectionné »

#Objet

Répondre en dix secondes à deux questions : les services répondent-ils ? et où en est le locataire sélectionné ?

#Ce que vous voyez

États possibles d'une ligne de santé : En service · Hors service · Sonde indisponible · Sonde…. Le bandeau résume : « Tout est opérationnel », « n hors service », « n sonde indisponible ».

La distinction entre « Hors service » et « Sonde indisponible » est essentielle. En mode passerelle, le portail interroge un agrégat de santé unique. Cet agrégat répond 200 quand tout va bien et 503 quand un service est en panne — et les deux réponses portent le détail par service. Tout autre code (404, 502…) signifie que la sonde elle-même ne fonctionne pas ; le portail affiche alors « Sondes de santé indisponibles » plutôt que de peindre tous les services en rouge.

Le texte d'aide du panneau précise la nature de la sonde : chaque point de santé exécute un vrai SELECT 1 sur son magasin PostgreSQL, et sur Redis lorsque configuré. Un état vert reflète une connectivité réelle.

#Actions

Cette destination est en lecture seule. Aucune capacité d'écriture n'y est rattachée.

1. Sélectionnez le locataire à observer.
2. Laissez la page ouverte : le rafraîchissement est automatique (santé toutes les 15 secondes).
3. Cliquez Réessayer sur un encadré d'erreur pour relancer la sonde concernée.
4. Filtrez le catalogue d'indicateurs par famille (Qualité / Coût / Spécification) ou par nom.

#Permissions

config:read — accordée aux trois rôles.

#Écarts honnêtes

---

#3.2 Flotte d'agents — /fleet

Libellé : Flotte d'agents · Groupe : Supervision · Sous-titre : « Supervision de la flotte d'agents et interruption »

#Objet

Voir ce que les agents exécutent en ce moment pour le locataire sélectionné, inspecter une exécution, et l'arrêter si nécessaire.

#Ce que vous voyez

1. Flotte en un coup d'œil — total des exécutions, nombre d'actives, répartition par statut sous forme d'anneau.
2. Graphe d'exécution — chaque voie est une exécution : la tête violette est l'agent, suivie des étapes de son plan. Les étapes exécutées sont vertes, l'étape courante porte le statut de l'exécution, les étapes à venir restent neutres.
3. Runs d'agents — tableau : Agent · Statut · Exécuteur · Étape · Mis à jour · Créé · Actions.
4. Détail du run — tiroir latéral : Projet, Budget d'étapes, Démarré, Erreur du run.
5. Activité en direct — flux d'événements récents.

Statuts affichés : En file · En cours · Suspendu · Terminé · Échoué.

Le graphe se pilote au clavier : flèches pour naviguer entre les nœuds, Entrée pour inspecter, plus/moins pour zoomer, 0 pour ajuster à la vue.

#Action pas à pas — interrompre une exécution

1. Sélectionnez le locataire concerné.
2. Repérez la ligne dont le statut est En cours ou En file.
3. Cliquez Interrompre.
4. Lisez la confirmation : « Interrompre le run ? — Le run passera à l'état terminal « failed ». Cette action est irréversible. »
5. Confirmez. Le message « Run interrompu. » s'affiche et la liste se rafraîchit.

Effets de bord. L'exécution passe à un état terminal. Il n'y a pas de reprise : la seule suite possible est une nouvelle exécution. L'action porte l'identité agissante — elle est donc attribuable et journalisée.

#Contraintes

#Permissions

fleet:interrupt — opérateur et administrateur plateforme.

#Écarts honnêtes signalés dans l'interface

---

#3.3 Locataires — /tenants

Libellé : Locataires · Groupe : Locataires & accès · Sous-titre : « Registre des locataires, plans et sélection »

#Objet

Créer un locataire, changer de locataire actif, consulter le registre des organisations, le catalogue de plans, et éditer les champs personnalisés de l'organisation.

#Ce que vous voyez

#Action pas à pas — créer un locataire

1. Ouvrez Locataires.
2. Cliquez Nouveau locataire (en haut à droite du registre).
3. Renseignez les trois champs :

4. Le bouton de validation reste inactif tant que le slug est invalide ou que le nom est vide.
5. Confirmez. Message : « Locataire créé. »
6. Le registre se rafraîchit. Cliquez Sélectionner sur la nouvelle ligne pour en faire le locataire actif.

⚠️ Piège réel. Le champ Plan est un champ texte libre pré-rempli avec la valeur starter. Or aucun plan de code starter n'existe dans le catalogue exploité : les codes réellement présents sont gratuit, team et enterprise. Écrasez systématiquement la valeur par défaut par un code existant, sous peine de créer un locataire rattaché à un plan fantôme. Voir §9.

#Effets de bord

• Le slug est normalisé en minuscules avant envoi.
• Une clé d'idempotence accompagne la création : un double clic ne crée pas deux locataires.
• Le locataire créé n'a aucun utilisateur. Enchaînez immédiatement sur le runbook R1 (§4.1).

#Permissions

tenants:manage — administrateur plateforme uniquement.

#Écarts honnêtes signalés dans l'interface

Suspension de locataire — écart backend : le service utilisateur n'expose aucun point d'entrée de suspension d'organisation. Le schéma de mise à jour ne comporte pas de champ d'activité et il n'existe pas de route de suspension. L'état Actif / Suspendu est donc affiché en lecture seule. Pour retirer un accès en urgence, utilisez le runbook R3 (§4.3), qui agit sur les utilisateurs et non sur le locataire.

Autres écarts :

---

#3.4 Utilisateurs & RBAC — /users

Libellé : Utilisateurs & RBAC · Groupe : Locataires & accès · Sous-titre : « Utilisateurs et éditeur de matrice RBAC »

#Objet

Gérer le cycle de vie des comptes du locataire, poser et retirer les rôles d'identité, inspecter les permissions effectives et poser des dérogations ciblées.

#Ce que vous voyez

Statuts d'utilisateur : En attente · Actif · Inactif · Suspendu · Supprimé.

Les huit capacités affichées comme colonnes de la matrice de référence sont : config:read, budgets:manage, flags:manage, fleet:interrupt, rbac:edit, models:manage, policies:manage, secret_access:approve.

#Action pas à pas — créer un utilisateur

1. Vérifiez le locataire actif : l'utilisateur y sera rattaché.
2. Cliquez Nouvel utilisateur.
3. Renseignez :

4. Validez. Message : « Utilisateur créé. »

Le compte est créé sans aucun rôle. Sans rôle, l'utilisateur ne peut rien faire. Enchaînez sur l'attribution.

#Action pas à pas — attribuer ou retirer un rôle

1. Sur la ligne de l'utilisateur, cliquez Modifier.
2. Le bloc Rôles (Keycloak) liste les rôles en place. Aide affichée : « Ajouter/retirer un rôle applique immédiatement le mapping de rôle Keycloak. »
3. Pour ajouter : choisissez un rôle dans la liste déroulante puis cliquez Ajouter. Rôles proposés, dans l'ordre : VIEWER, EDITOR, PUBLISHER, ADMIN, OWNER. Le bouton est inactif si le rôle est déjà présent. Message : « Rôle ajouté. »
4. Pour retirer : cliquez la croix × sur la pastille du rôle. Message : « Rôle retiré. »

Effet immédiat et sans confirmation. Le retrait d'un rôle n'ouvre aucune boîte de dialogue. L'effet est instantané côté serveur d'identité. Un utilisateur sans rôle affiche « Aucun rôle ».

Signification des rôles métier, telle que définie par le modèle RBAC partagé :

Les rôles sont composites côté serveur d'identité : OWNER implique ADMIN, qui implique PUBLISHER, et ainsi de suite. Vous n'avez donc pas à empiler les rôles ; attribuez le plus élevé nécessaire, et un seul.

#Action pas à pas — modifier ou supprimer un utilisateur

1. Modifier ouvre un formulaire : Courriel (revalidé), Statut (liste des cinq états), Rôles. Message : « Utilisateur mis à jour. »
2. Supprimer ouvre une confirmation : « Supprimer l'utilisateur ? — Cette action supprime définitivement l'utilisateur. Elle est irréversible. » Le courriel est rappelé dans la boîte. Message : « Utilisateur supprimé. »

Choisissez la désactivation plutôt que la suppression chaque fois que la traçabilité compte. Passer le statut à Inactif ou Suspendu coupe l'accès en conservant l'historique.

#Action pas à pas — poser une dérogation de permission

1. Sur la ligne de l'utilisateur, cliquez Permissions — cela le sélectionne dans le panneau du dessous.
2. Lisez d'abord Permissions effectives : c'est la matrice résolue par le serveur (rôles + dérogations). La ligne « Rôles appliqués » indique les rôles pris en compte.
3. Cliquez Nouvelle dérogation (inactif tant qu'aucun utilisateur n'est sélectionné).
4. Renseignez :

5. Validez. Message : « Dérogation créée. »

#Action pas à pas — révoquer une dérogation

1. Repérez la ligne dans Dérogations de l'utilisateur.
2. Cliquez Révoquer. Confirmation : « Révoquer la dérogation ? — Cette action révoque définitivement la dérogation. Elle est irréversible. »
3. Message : « Dérogation révoquée. »

Portée verrouillée. Une dérogation de portée Locataire ne peut pas être révoquée depuis cet écran : le bouton est désactivé et affiche « Dérogation à l'échelle du locataire — révocation impossible ici. » Seules les dérogations de portée Utilisateur sont révocables ici.

#Permissions

#Écarts honnêtes signalés dans l'interface

Moteur de permissions non raccordé : « Le moteur de permissions (/permissions) n'est pas raccordé dans cet environnement. La matrice de rôles ci-dessous reste la référence ; les permissions effectives par utilisateur seront disponibles une fois le service raccordé. »

Cet encadré s'affiche quand le point d'entrée répond 404 ou 501. Conséquence pratique : dans un tel environnement, les permissions effectives et les dérogations sont indisponibles, et seule l'attribution de rôles fonctionne. Le portail distingue proprement ce cas d'une vraie panne : une erreur réseau ou un 5xx affichent un encadré d'erreur avec bouton Réessayer, pas ce message.

---

#3.5 Gouvernance & SoD — /governance

Libellé : Gouvernance & SoD · Groupe : Locataires & accès · Sous-titre : « Contrôle double (SoD), politiques d'accès Vault et audit des accès aux justificatifs »

#Objet

Exercer le second contrôle sur les élargissements d'accès sensibles, consulter les chemins de coffre référencés, et auditer les accès aux justificatifs.

#Ce que vous voyez

#Action pas à pas — approuver ou rejeter une revue

1. Vérifiez que votre identité agissante est définie. Sinon un encadré s'affiche : « Identité requise — Définissez l'identité Platform-Admin (X-User-ID) pour agir sur une revue. »
2. Choisissez le Type de sujet : Version de skill ou Serveur MCP.
3. Collez l'Identifiant du sujet (UUID). Le format UUID canonique est exigé ; le bouton Charger les revues reste inactif sinon.
4. Cliquez Charger les revues.
5. Lisez le tableau : Soumis par · Revu par · Classe de risque · Verdict · Actions.
6. Cliquez Approuver (2ᵉ contrôle) ou Rejeter.

Ce que fait la séparation des devoirs, concrètement. Avant tout appel réseau, le portail vérifie trois conditions et bloque le bouton si l'une échoue :

Le rejet, lui, reste possible même si vous êtes le soumetteur : on peut toujours retirer sa propre demande. Seule l'approbation est verrouillée par l'anti-auto-approbation.

Le serveur reste autoritatif. Même si le blocage visuel était contourné, la base de données refuse l'auto-approbation avec un conflit typé sod/self-approval-forbidden. Le blocage de l'interface évite un aller-retour inutile ; il ne constitue pas la sécurité.

Détail d'implémentation à connaître. Lorsque la classe de risque du sujet est élevée, le portail transmet automatiquement l'indicateur « revue de sécurité effectuée » avec votre décision. En approuvant un sujet à haut risque, vous attestez donc avoir mené la revue de sécurité correspondante. Traitez ce clic comme une signature.

#Effets de bord

• La décision porte votre identité et devient définitive.
• Une approbation débloque les liaisons associées à la capacité ; un rejet les laisse inertes.
• Une capacité non approuvée ne peut pas être liée à un rôle IA (voir §3.14).

#Permissions

secret_access:approve — administrateur plateforme uniquement. La proposition d'élargissement relève de secret_access:widen, ouverte aussi à l'opérateur : c'est la mécanique même du double contrôle.

#Écarts honnêtes signalés dans l'interface

File de revues à l'échelle plateforme — écart backend : le registre d'extensions liste les revues par sujet (type + identifiant), et non une file transverse des revues en attente. Une file d'approbations unifiée nécessiterait un point d'entrée dédié. Conséquence : vous devez connaître à l'avance l'identifiant du sujet à traiter. En pratique, il vient du message de la personne qui vous sollicite ou de la page Registre.

Autres points :

---

#3.6 Budgets & quotas — /budgets

Libellé : Budgets & quotas · Groupe : Coûts & conformité · Sous-titre : « Budgets de dépense et fenêtres de quota du locataire »

#Objet

Poser un plafond de dépense sur une portée, suivre la consommation réelle, et lire les fenêtres de quota mesurées en amont.

#Ce que vous voyez

Budgets — une carte par budget, avec : la portée en police à chasse fixe, une pastille d'état, une jauge, puis trois valeurs — Dépensé, Restant, % utilisé.

États possibles et code couleur :

Fenêtres de quota — tableau : Portée · Modèle de limite · % consommé · Réinitialisation. Panneau en lecture seule : les fenêtres sont produites par la mesure en amont, pas administrées ici.

#Action pas à pas — créer un budget

1. Sélectionnez le locataire.
2. Cliquez Nouveau budget.
3. Renseignez :

4. Validez. Message : « Budget créé. »

Convention de portée. La portée est une chaîne libre : rien ne l'empêche d'être mal orthographiée. Une portée projet:FB au lieu de project:FB crée un budget qui ne sera jamais consommé. Adoptez une convention écrite et tenez-vous-y.

#Action pas à pas — modifier un budget

1. Cliquez Modifier sur la carte.
2. Ajustez Limite, Seuil d'alerte, Seuil critique. La portée n'est pas modifiable — pour la changer, supprimez et recréez.
3. Validez. Message : « Budget mis à jour. »

#Action pas à pas — supprimer un budget

1. Cliquez Supprimer.
2. Confirmation : « Supprimer le budget ? — Cette action supprime définitivement le budget. L'historique de consommation est conservé (le lien est dissocié). Elle est irréversible. »
3. Message : « Budget supprimé. »

Ce point mérite d'être souligné : supprimer un budget ne détruit pas l'historique de dépense. Vous perdez le plafond, pas la trace.

#Permissions

budgets:manage — opérateur et administrateur plateforme.

#Points d'attention

---

#3.7 Audit & conformité — /audit

Libellé : Audit & conformité · Groupe : Coûts & conformité · Sous-titre : « Recherche du journal d'audit et export de conformité Loi 25 »

#Objet

Retrouver une action passée, prouver que le journal n'a pas été altéré, et produire un rapport de conformité sur une période.

#Ce que vous voyez

Colonnes du journal : Horodatage · Acteur · Action · Ressource · Hash (préfixe). Le préfixe de hachage affiché correspond aux douze premiers caractères de l'empreinte de l'entrée.

#Action pas à pas — rechercher dans le journal

1. Sélectionnez le locataire.
2. Renseignez tout ou partie des quatre filtres : Acteur, Action, Ressource, Recherche libre.
3. Cliquez Rechercher.
4. Le compteur affiche « n entrée(s) ». Sans résultat : « Aucune entrée d'audit pour ce filtre. »

Les filtres sont appliqués au clic, pas à la frappe : modifier un champ sans cliquer Rechercher ne change rien à l'affichage.

#Action pas à pas — vérifier l'intégrité de la chaîne

1. Cliquez Vérifier la chaîne (en haut à droite du panneau de recherche).
2. Le service recalcule les empreintes et compare.
3. Deux issues possibles :

Que faire d'une chaîne compromise. Ce n'est pas un incident d'interface, c'est un incident de sécurité. Consignez l'identifiant, le motif et la position affichés, n'effectuez aucune écriture supplémentaire sur le locataire concerné, et déclenchez la procédure de réponse à incident (voir le guide de durcissement, §6 du document 05-guide-administrateur-securite.md).

#Action pas à pas — générer un rapport Loi 25

1. Renseignez Période — début et Période — fin (sélecteurs de date).
2. Cliquez Générer le rapport. Le bouton reste inactif tant qu'une des deux dates manque.
3. Message : « Rapport de conformité généré. »
4. Le rapport apparaît dans le tableau : Période · Événements · Chaîne vérifiée (Oui/Non) · Généré par · Créé le.

Le texte d'aide est explicite sur la méthode : « Rapport Loi 25 par agrégation réelle du journal (accès / consentement / brèche + vérification de la chaîne). Une période sans données produit un rapport valide horodaté (non une erreur). »

C'est important en audit : l'absence d'événement est une information, et elle est attestée.

#Action pas à pas — exporter un rapport

1. Sur la ligne du rapport, cliquez Exporter (JSON).
2. Le fichier est produit localement par le navigateur, nommé loi25-report-<identifiant>.json.

Cet export ne passe par aucun serveur : il sérialise l'objet déjà chargé dans la page. Il n'y a donc aucune trace serveur de l'export lui-même. Si votre politique interne exige de tracer les extractions, consignez-les manuellement.

#Permissions

#Points d'attention

• Les dates saisies sont converties en horodatage complet avant envoi ; attention aux effets de bord de fuseau sur les bornes de période.
• Le journal est append-only et chaîné par hachage : aucune entrée n'est modifiable depuis l'interface, par construction.

---

#3.8 Feature-flags — /flags

Libellé : Feature-flags · Groupe : Configuration plateforme · Sous-titre : « Feature-flags de la plateforme (évaluation déterministe par locataire) »

#Objet

Activer ou désactiver une fonctionnalité, globalement ou pour le seul locataire courant, avec un pourcentage de déploiement progressif.

#Ce que vous voyez

Tableau : Clé · Portée · Activé · Déploiement (%) · Description · Actions. Filtre de texte disponible sur la clé.

Le texte d'aide pose la règle : « Un flag global s'applique à toute la plateforme ; une dérogation de locataire ne concerne que le locataire courant. »

#Action pas à pas — créer un drapeau

1. Cliquez Nouveau flag.
2. Renseignez :

3. Validez.

Le drapeau est créé DÉSACTIVÉ. C'est délibéré et c'est la bonne posture : on crée, on relit, puis on active. Message : « Feature-flag créé. »

#Action pas à pas — activer, désactiver, ajuster

1. Activer / Désactiver : bouton unique sur la ligne, dont le libellé bascule entre Activer et Désactiver. Effet immédiat, sans confirmation. Message : « Feature-flag mis à jour. »
2. Modifier : ouvre un formulaire limité au Déploiement (%) et à la Description. Ni la clé ni la portée ne sont modifiables après création.
3. Supprimer : confirmation « Supprimer le feature-flag ? — Cette action supprime définitivement le feature-flag. Elle est irréversible. » La clé est rappelée.

⚠️ Le bouton d'activation n'a pas de confirmation. Sur un drapeau de portée globale en production, un clic engage toute la plateforme. Traitez ce bouton avec la même prudence qu'un déploiement.

#Effets de bord

• L'évaluation est déterministe par locataire : à pourcentage constant, un même locataire obtient toujours la même réponse. Ce n'est pas un tirage aléatoire à chaque appel.
• Un drapeau à 0 % activé reste inerte pour tout le monde ; l'activation seule ne suffit pas.
• Certaines destinations dépendent d'un drapeau (Démo, Rôles IA). Voir §3.15 et §3.14.

#Permissions

flags:manage — opérateur et administrateur plateforme.

#Points d'attention

---

#3.9 Modèles & adaptateurs — /models

Libellé : Modèles & adaptateurs · Groupe : Configuration plateforme · Sous-titre : « Configuration des modèles LLM et des adaptateurs d'assistant (chemins Vault uniquement) »

#Objet

Déclarer quels modèles de langage la plateforme peut utiliser, lequel est le modèle par défaut, et par quel adaptateur d'assistant on y accède.

#Ce que vous voyez

Configurations de modèle : Clé · Fournisseur · Modèle · Chemin Vault · Par défaut · Activé · Actions. Adaptateurs d'assistant : Clé · Assistant · Config modèle liée · Chemin Vault · Activé · Actions.

#Action pas à pas — créer une configuration de modèle

1. Cliquez Nouvelle config modèle.
2. Renseignez :

3. Validez. Message : « Configuration de modèle créée. »

Aucun secret n'est jamais saisi ici. Le champ attend un chemin dans le coffre. Le service résout la valeur au moment de l'appel. Si vous collez une clé d'API dans ce champ, vous venez de la persister en clair dans la configuration : traitez cela comme un incident et effectuez une rotation immédiate.

#Action pas à pas — changer le modèle par défaut

1. Cliquez Modifier sur la configuration cible.
2. Cochez Modèle par défaut.
3. Vérifiez que Activé est coché — un modèle par défaut désactivé est un piège classique.
4. Validez. Message : « Configuration de modèle mise à jour. »
5. Rechargez la liste et vérifiez qu'une seule ligne porte la pastille « Par défaut ».

#Action pas à pas — créer un adaptateur

1. Cliquez Nouvel adaptateur.
2. Renseignez :

3. Validez. Message : « Adaptateur créé. »

⚠️ Le champ Clé de config modèle liée est libre et non vérifié au moment de la saisie. Une faute de frappe produit un adaptateur pointant vers un modèle inexistant, sans erreur immédiate. Recopiez la clé depuis le tableau du dessus.

#Suppression

Les deux entités se suppriment avec une confirmation irréversible : « Cette action supprime définitivement la configuration de modèle / l'adaptateur. Elle est irréversible. »

#Permissions

models:manage — administrateur plateforme uniquement. Un opérateur voit tout et ne peut rien écrire.

#Effets de bord à connaître

• Les chemins de coffre saisis ici alimentent le panneau « Politiques d'accès Vault » de la page Gouvernance. C'est le seul endroit où l'on crée ces liaisons.
• Supprimer une configuration de modèle ne nettoie pas les adaptateurs qui la référencent : ils continuent d'afficher une clé désormais orpheline.

---

#3.10 Garde-fous & exécution — /policies

Libellé : Garde-fous & exécution · Groupe : Configuration plateforme · Sous-titre : « Garde-fous d'exécution (deny-by-default) et politiques de sandbox »

#Objet

Définir ce qu'un agent a le droit de faire (garde-fous) et dans quel bac à sable il s'exécute (politiques d'exécution).

#Ce que vous voyez

Garde-fous (out-of-loop, deny-by-default) : Identifiant · Motif d'action · Effet · Priorité · Approbation · Activé · Actions, plus un encadré Évaluer une action. Politiques d'exécution (sandbox) : Identifiant · Réseau · Egress (allowlist) · Durée max (s) · Système de fichiers · Actions.

La règle fondatrice est affichée : « Sans règle allow correspondante, une action est refusée par défaut (fail-safe). » Et quand la table est vide : « Aucune règle de garde-fou. L'évaluation refuse toute action par défaut. »

#Action pas à pas — créer un garde-fou

1. Cliquez Nouvelle règle.
2. Renseignez :

3. Validez. Message : « Garde-fou créé. »

L'effet par défaut est « Refuser ». C'est cohérent avec la posture de refus par défaut. Passer une règle en « Autoriser » est toujours un élargissement : justifiez-le.

Comprendre la priorité. Plus le nombre est petit, plus la règle est évaluée tôt. Une règle d'autorisation large en priorité 10 peut donc neutraliser une règle de refus ciblée en priorité 100. Placez toujours les refus ciblés avant les autorisations larges.

#Action pas à pas — évaluer une action

1. Dans l'encadré Évaluer une action, saisissez l'action à tester (exemple affiché : deploy:prod).
2. Cliquez Évaluer.
3. Le verdict s'affiche : « Verdict : Autorisée » ou « Verdict : Refusée », suivi du nombre de règles correspondantes, de la mention Approbation requise le cas échéant, et de l'identifiant de la règle appliquée.

Si le service d'évaluation n'est pas monté dans l'environnement, l'encadré affiche : « Évaluateur non raccordé — L'évaluateur de garde-fous n'est pas raccordé dans cet environnement (l'endpoint d'évaluation répond 404/501). Les règles ci-dessus restent réelles ; l'évaluation à la volée sera disponible une fois le service raccordé. »

C'est un point de nuance important : un évaluateur non raccordé ne signifie pas que les règles sont inertes. Elles sont bien appliquées par le service d'exécution ; c'est seulement le simulateur de l'interface qui manque.

#Action pas à pas — créer une politique d'exécution

1. Cliquez Nouvelle politique.
2. Renseignez :

3. Validez. Message : « Politique d'exécution créée. »

La validation du préfixe deny- est un verrou de conception : on ne peut pas créer depuis cette interface une politique réseau permissive par défaut. C'est volontaire.

#Action pas à pas — durcir une politique existante

1. Cliquez Modifier.
2. Champs modifiables : Politique réseau (préfixe deny- toujours exigé), Egress (allowlist), Durée max, Système de fichiers, Activé.
3. L'allowlist d'egress est une liste d'hôtes séparés par des virgules (exemple affiché : api.anthropic.com, gateway.internal). Les espaces sont supprimés et les entrées vides ignorées.
4. Validez. Message : « Politique d'exécution mise à jour. »

#Permissions

policies:manage — administrateur plateforme uniquement, pour les deux familles.

#Points d'attention

---

#3.11 Registre (skills/outils/prompts) — /registry

Libellé : Registre (skills/outils/prompts) · Groupe : Configuration plateforme · Sous-titre : « Registre GLOBAL des skills, outils (MCP) et prompts — géré au niveau plateforme, visible par tous les locataires »

#Objet

Publier, au nom de la plateforme, les capacités que tous les locataires pourront adopter : compétences, serveurs d'outils, modèles de prompt.

#Portée : attention particulière

Un encadré permanent l'annonce : « Portée globale (locataire plateforme) — Ces entrées sont créées AU NOM du locataire plateforme avec la visibilité « global » et sont proposées à tous les locataires. Le sélecteur de locataire en haut n'affecte pas cette page. »

C'est la seule destination, avec Rôles IA et Démo, où le sélecteur de locataire est sans effet. Ne cherchez pas à isoler une publication sur un locataire depuis cet écran : ce n'est pas ce que fait cette page.

#Les trois onglets

#Action pas à pas — rédiger une compétence globale

1. Onglet Skills, cliquez Nouveau skill.
2. Renseignez :

3. Validez. Message : « Skill global créé (brouillon). »

La compétence atterrit en brouillon. Elle n'est pas utilisable tant qu'une revue de séparation des devoirs n'a pas été approuvée sur la page Gouvernance. Le texte d'aide le dit : « Ils atterrissent en brouillon jusqu'à approbation SoD (Gouvernance). »

#Action pas à pas — importer le seed curaté de compétences

1. Onglet Skills, repérez le panneau Importer le seed de skills globaux.
2. Lisez le manifeste : Capacité · Source · Licence · Résultat · Détail.
3. Cliquez Importer les n skills.
4. Le rapport s'affiche : « n importés », « n ignorés », « n bloqués », et par ligne : Importé · Déjà présent · Bloqué · Erreur.
5. Message : « Seed importé (en attente de revue SoD). »

La note de gouvernance affichée décrit précisément le pipeline : « Chaque skill passe par le pipeline gouverné : provenance → vérification de signature → classification du risque → validation + analyse de secrets → revue SoD. Ce n'est jamais un INSERT en masse. Idempotent : un skill déjà présent est ignoré. »

Vous pouvez donc relancer l'import sans risque de doublon.

#Action pas à pas — enregistrer un serveur d'outils MCP

1. Onglet Outils (MCP), cliquez Nouvel outil.
2. Renseignez l'identité du serveur :

3. Choisissez le Type d'authentification parmi : Aucune · OAuth2 · Clé API · Basique (login). Les champs suivants s'adaptent :

4. Renseignez le Chemin Vault du justificatif :

« Les secrets vivent dans Vault — saisissez UNIQUEMENT le chemin Vault, jamais la valeur du secret. » Le chemin doit commencer par secret/ ; sinon l'erreur affichée est « Le chemin doit commencer par « secret/ ». » Le chemin devient obligatoire dès que le type d'authentification n'est pas « Aucune ».

5. Complétez éventuellement : En-têtes statiques (JSON non secret) — objet JSON validé côté client, aide : « Objet JSON d'en-têtes NON secrets (jamais de justificatif ici) » ; Délai d'expiration (ms) ; Chemin de santé (optionnel) (exemple : /health).
6. Validez. Message : « Outil MCP global enregistré. »

Notion clé à saisir : vous ne saisissez jamais un secret, et jamais non plus un ensemble de secrets. Vous saisissez le chemin du coffre et le nom des sous-clés qui y sont stockées. L'aide le précise : « Renseignez les NOMS des sous-clés stockées sous ce chemin Vault (jamais leurs valeurs). »

#Action pas à pas — modifier l'authentification d'un outil

1. Cliquez Modifier l'authentification sur la ligne.
2. Ajustez le type et les sous-clés.
3. Message : « Authentification de l'outil mise à jour. »

#Action pas à pas — créer un prompt global

1. Onglet Prompts, cliquez Nouveau prompt.
2. Renseignez :

3. Validez. Message : « Prompt global créé. »

Effet de bord : la création produit trois objets liés — un modèle, une version de ce modèle, et une entrée de catalogue. Le corps vit dans le service d'orchestration de prompts ; le catalogue ne conserve qu'un lien gouverné.

#Action pas à pas — révoquer une entrée

1. Cliquez Révoquer sur la ligne (le bouton est désactivé si l'entrée est déjà révoquée).
2. Saisissez le Motif de révocation — obligatoire : le bouton de confirmation reste inactif tant que le champ est vide.
3. Lisez l'avertissement : « La révocation désactive toutes les liaisons / permissions associées. Motif obligatoire (audité). Action irréversible. »
4. Message : « Entrée révoquée. »

La révocation est l'outil de retrait d'urgence d'une capacité compromise. Son effet est large et immédiat : toutes les liaisons tombent.

#Permissions

registry:manage — administrateur plateforme uniquement, pour toutes les écritures des trois onglets.

#Écarts honnêtes

---

#3.12 Agents IA — /agents

Libellé : Agents IA · Groupe : Configuration plateforme · Sous-titre : « Tous les agents IA de la plateforme — registre central (source de vérité) : configuration + liaisons de bundle (skills / MCP / niveau de modèle) »

#Objet

Voir la flotte d'agents déclarés, inspecter le contenu d'un agent, activer ou désactiver un agent au niveau du registre central.

#Ce que vous voyez

Colonnes : Nom · Type · Capacités · Skills · Serveurs MCP · Transport · Niveau (jetons) · Santé · Statut · Modèle. Types d'agent : Statique ou Dynamique. Un compteur récapitule : « n agents · n statiques · n dynamiques ».

#Action pas à pas — inspecter un agent

1. Cliquez la ligne de l'agent.
2. La modale Détail de l'agent affiche : Capacités · Skills liés · Serveurs MCP · Santé, ainsi que le transport.

#Action pas à pas — activer ou désactiver un agent

1. Repérez la ligne dans Enregistrements du registre central.
2. Cliquez Activer ou Désactiver.
3. Message : « Agent activé. » ou « Agent désactivé. »

Effet. Le basculement est écrit dans le registre central, qui est la source de vérité pour l'ensemble de la plateforme. Désactiver un agent le retire de la résolution pour tous les locataires — ce n'est pas une action portée par un locataire.

#Contraintes

#Permissions

agents:manage — administrateur plateforme uniquement.

#Erreurs possibles

Un registre vide n'est pas normal en exploitation. Il signifie presque toujours que le registre central n'a jamais été alimenté, ou que le service d'orchestration ne le joint pas. Voir le tableau de dépannage (§8).

---

#3.13 Workforce (personnel virtuel) — /workforce

Libellé de navigation : ⚠️ MANQUANT · Groupe : Configuration plateforme · Sous-titre : « Membres du personnel virtuel, files de tâches et équipes du locataire sélectionné »

#Écart d'affichage à connaître avant tout

La clé de traduction nav.workforce n'existe ni en français ni en anglais. Les seize entrées de navigation sont bien présentes dans le code, mais quinze seulement ont un libellé. Conséquence directe et visible :

• l'entrée de la barre latérale ne s'affiche pas correctement ;
• le fil d'Ariane est incomplet ;
• le titre <h1> de la page — qui est dérivé de la clé de navigation — est affecté ;
• la palette de commandes et le copilote de console échouent également sur cette clé.

Deuxième clé manquante sur la même page : workforce.noTeams, utilisée quand aucune équipe n'existe. L'état vide du panneau Équipes est donc lui aussi défectueux.

Ces deux corrections sont des prérequis de lancement. Voir §9.

#Objet

Superviser le personnel virtuel du locataire : effectifs, autonomie, équipes, charge, et mise en pause.

#Ce que vous voyez

Vue d'ensemble des effectifs — cinq compteurs : Effectifs · Actifs · Équipes · Tâches ouvertes · Tâches terminées.

Membres du personnel — Nom · Rôle · Autonomie · Équipe · Statut · Tâches ouvertes · Actions. Colonnes triables sur le nom, l'autonomie, le statut et les tâches ouvertes ; filtre de texte disponible.

Statuts : Actif · En pause · Hors service.

Équipes — Nom · Clé d'équipe · Description · Coordinateur.

#Action pas à pas — mettre en pause ou reprendre un membre

1. Sélectionnez le locataire.
2. Sur la ligne du membre, cliquez Mettre en pause (bouton rouge) ou Reprendre (bouton secondaire).
3. Message : « Statut du membre mis à jour. »
4. Les compteurs de la vue d'ensemble se rafraîchissent automatiquement.

Le bouton bascule selon l'état : un membre En pause ou Hors service affiche Reprendre ; un membre Actif affiche Mettre en pause.

#Permissions

⚠️ Attention : l'action pause/reprise est gardée par la capacité agents:manage, et non par une capacité dédiée au personnel virtuel. Un opérateur plateforme ne peut donc pas mettre un membre en pause — il faut le rôle administrateur plateforme. Le message affiché est « Requiert le rôle Administrateur plateforme. »

C'est une contrainte à connaître pour l'astreinte : mettre en pause un agent en dérive n'est pas une action d'opérateur. Pour l'astreinte de niveau opérateur, la voie disponible est l'interruption d'exécution depuis la page Flotte d'agents (§3.2), qui, elle, relève de fleet:interrupt.

#Statut fonctionnel

Le personnel virtuel est livré en phase 1 : embauche depuis l'interface, assignation à une file, activité et organigramme. C'est prouvé en ligne sur les environnements de développement et de production. Les phases suivantes — délégation, escalade, autonomie étendue, direction virtuelle — sont Planifiées et ne doivent pas être présentées comme disponibles.

---

#3.14 Rôles IA — /roles

Libellé : Rôles IA · Groupe : Configuration plateforme · Sous-titre : « Composez des capacités sur des rôles métier à l'échelle de la plateforme. »

#Objet

Attacher des capacités globales à un rôle virtuel et fixer son plafond d'autonomie.

#Prérequis bloquant

Si le drapeau des rôles virtuels est désactivé, la page affiche : « Rôles virtuels IA désactivés — Le plan des rôles virtuels IA n'est pas activé sur cet environnement (REGISTRY_VIRTUAL_ROLES_ENABLED désactivé). »

Ce drapeau est désactivé par défaut dans tous les services concernés, et il n'est activé dans aucun manifeste de déploiement. Sur un environnement livré tel quel, cette destination est donc inopérante. C'est un écart à assumer, pas un défaut d'installation.

Un second encadré rappelle la portée : « Portée globale (plateforme) — Les actions ici s'exécutent en tant que tenant plateforme sur le catalogue global. L'administration plateforme (registry:manage) est requise pour écrire ; le tenant plateforme n'est jamais soumis aux droits d'accès. »

#Ce que vous voyez

#Action pas à pas — lier une capacité à un rôle

1. Choisissez un rôle dans Choisir un rôle. Sans sélection : « Choisissez d'abord un rôle ci-dessus. »
2. Choisissez le Type de capacité : Compétences, Outils ou Prompts.
3. Le catalogue global s'affiche : Nom · Risque · Approuvé (Oui / Non) · action.
4. Cliquez Lier au rôle. Le bouton est inactif sur une capacité non approuvée, avec la mention « Doit être approuvée pour être liée. »
5. Confirmez : « Lier la capacité — Confirmez la liaison de cette capacité globale approuvée à la portée agent du rôle. Rien n'est auto-approuvé. »
6. Message : « Capacité liée au rôle. »

Le bandeau du rôle indique en permanence le contenu du bundle : « n compétence(s) liée(s) », « n outil(s) lié(s) », « n prompt(s) lié(s) ».

#Action pas à pas — réviser un plafond d'autonomie

1. Ouvrez le panneau RPA & autonomie.
2. Choisissez le Plafond d'autonomie parmi N0, N1, N2, N3.
3. Cliquez Enregistrer le plafond. Message : « Plafond d'autonomie enregistré. »

La règle de calcul est affichée et il faut la comprendre :

« Autonomie effective = min(plafond, plan.role.max_autonomy). »

Autrement dit : le plafond que vous fixez ici borne le rôle, et le plan commercial du locataire le borne encore davantage. Vous ne pouvez jamais accorder plus que ce que le plan autorise.

Comportement de sécurité complémentaire : en cas de dégradation ou de valeur inconnue, la résolution retombe sur N1 — le système échoue vers le bas, jamais vers le haut.

Un encadré Gouverné complète : « Le browser_action RPA d'un rôle passe toujours par le plan agent-runtime gouverné (refus par défaut, dry-run, bail→egress→provision→exécution). Le plafond d'autonomie borne un rôle ; le forfait le borne davantage. Lier un outil RPA nécessite registry.rpa. »

#Action pas à pas — découvrir et importer une compétence en ligne

1. Panneau Recherche de compétences en ligne : « Découvrez et importez des compétences depuis des sources en ligne (lecture seule, egress restreint). »
2. Choisissez la Source : Catalogue curé ou GitHub.
3. Saisissez la recherche (exemple affiché : « extraction de factures ») et cliquez Découvrir.
4. Les candidats s'affichent : Candidat · Licence · Risque (aperçu).
5. Cliquez Importer, puis confirmez : « La compétence est importée via le pipeline gouverné (provenance → vérif. signature → classification du risque → validation + scan de secrets) et reste en attente de revue (SoD). Jamais auto-approuvée. »
6. Message : « Compétence importée (en attente de revue) », suivi de « nom : statut « statut » — en attente d'approbation (SoD). »

États dégradés : « Aucun candidat trouvé. » ou « Source en ligne indisponible — aucun résultat. »

La recherche en ligne est réservée au plan Entreprise : le droit registry.online_search est désactivé sur les plans Gratuit et Équipe.

#Permissions

registry:manage — administrateur plateforme uniquement. Message de refus affiché : « Nécessite l'administration plateforme (registry:manage). »

#Écarts honnêtes visibles dans l'interface

Trois panneaux portent explicitement la mention Ébauche et un texte commençant par « TODO » :

Ces mentions sont visibles par l'utilisateur final. Elles doivent disparaître avant le jour J, soit par implémentation, soit par retrait du texte. Voir §9.

---

#3.15 Démo — /demo

Libellé : Démo · Groupe : Configuration plateforme · Sous-titre : « Provisionnez, réinitialisez ou supprimez le tenant de démonstration isolé — piloté par le module Démo (activé par flag, isolé par RLS). »

#Objet

Disposer d'un locataire de démonstration réaliste, reproductible et strictement isolé des locataires réels.

#Prérequis bloquant

Le module est gouverné par le drapeau DEMO_MODULE_ENABLED, désactivé par défaut. Tant qu'il l'est, la page affiche : « Le module Démo est désactivé. Activez le flag DEMO_MODULE_ENABLED (portée tenant, pour le seul tenant de démo) dans Feature-flags, puis provisionnez. » Le mot « Feature-flags » est un lien direct.

Les trois boutons d'action sont désactivés, avec la mention : « Activez d'abord le flag DEMO_MODULE_ENABLED pour déverrouiller ces actions. »

#Ce que vous voyez

État du module Démo — six champs : Activé · Provisionné · Ressources · Version du manifeste · Tenant de démo · Projets. Rafraîchissement automatique toutes les 15 secondes, plus un bouton Actualiser.

Le locataire de démonstration est épinglé : d3300000-0000-4000-8000-000000000001 par défaut. Le service refuse tout autre locataire.

#Action pas à pas — provisionner

1. Vérifiez que Activé affiche bien la pastille verte.
2. Choisissez le Mode de provisionnement :

3. Cliquez Provisionner. Message : « Démo provisionnée ».
4. Vérifiez que Provisionné est passé à Oui et que Ressources affiche un compte non nul.

Le mode Rédigé est le bon choix par défaut pour une démonstration commerciale : il est déterministe, gratuit et rejouable à l'identique. Réservez le mode Agentique aux démonstrations où l'on veut montrer les agents en action.

#Action pas à pas — réinitialiser

1. Cliquez Réinitialiser. Aucune confirmation n'est demandée.
2. Message : « Démo réinitialisée ».

Le provisionnement est idempotent : les ressources sont créées ou mises à jour par clé naturelle. Une réinitialisation ramène donc le locataire à l'état du manifeste.

#Action pas à pas — supprimer

1. Cliquez Supprimer.
2. Confirmation : « Supprimer la démo ? — Archive les projets de démo et oublie le manifeste. Le tenant reste isolé par RLS ; réversible via Provisionner. » L'identifiant du locataire est rappelé.
3. Message : « Démo supprimée ».

La suppression est donc réversible : elle archive et oublie, elle ne détruit pas le locataire.

#Permissions

demo:manage — administrateur plateforme uniquement. Le texte d'aide ajoute : « Toutes les actions n'opèrent que sur le tenant de démonstration réservé et exigent le rôle ADMIN. »

#Écart honnête

Le tableau du manifeste de démonstration est inerte. Le panneau Manifeste de démo n'affiche jamais le détail ligne à ligne des ressources : la liste qui l'alimente est codée en dur à vide dans la page. Seul le résumé de compte s'affiche — « n ressources semées dans le tenant de démonstration. » Les colonnes définies (Type · Clé naturelle · État) ne sont jamais rendues. Voir §9.

---

#3.16 Configuration — /config

Libellé : Configuration · Groupe : Configuration plateforme · Sous-titre : « URL des services control-plane et identité agissante (12-factor) »

#Objet

Déclarer qui vous êtes (en mode dev-headers) et vérifier où le portail envoie réellement ses requêtes.

#Panneau 1 — Identité Platform-Admin

Comportement selon le mode d'authentification :

En mode dev-headers — le panneau est modifiable :

1. Saisissez l'Identifiant administrateur (UUID). Aide : « UUID de l'utilisateur agissant, forwardé en X-User-ID. » Exemple de format affiché : 00000000-0000-0000-0000-000000000000.
2. Cliquez Appliquer.
3. Cochez les Rôles plateforme voulus : Lecteur, Opérateur plateforme, Administrateur plateforme. Les cases prennent effet immédiatement, sans validation.
4. Les rôles retenus s'affichent en pastilles sous le formulaire.

En mode jwt — le panneau est en lecture seule : il affiche l'Administrateur agissant dérivé du jeton et ses rôles, avec la mention « Identité dérivée de la session Keycloak (jeton) — non modifiable ici. » Si rien n'est défini : Non définie.

Le texte d'aide rappelle la nature des valeurs : « L'administrateur agissant est transmis via l'en-tête X-User-ID sur les actions de gouvernance (séparation des tâches, audit). Ni l'UUID ni les rôles ne sont des secrets. »

#Panneau 2 — URL des services

Tableau à trois colonnes : Service · Variable d'environnement · URL cible, avec une pastille passerelle ou direct par ligne. Neuf lignes — le service de démonstration n'y figure pas.

C'est votre premier réflexe de diagnostic : quand un panneau reste vide, ouvrez cette page et vérifiez que la cible affichée est bien celle attendue.

#Actions

Aucune action serveur. Le panneau d'identité écrit dans le stockage local du navigateur ; le panneau d'URL est en lecture pure.

#Permissions

config:read — accessible aux trois rôles. Aucune garde n'empêche un lecteur de se déclarer administrateur plateforme en mode dev-headers : c'est précisément pourquoi ce mode ne doit jamais être exposé publiquement.

#Point de sécurité

En mode dev-headers, cette page est le mécanisme d'authentification. Elle ne vérifie rien : elle enregistre une déclaration. Toute la sécurité repose alors sur le contrôle serveur — lequel, par défaut, fait la même hypothèse. C'est le point unique le plus important de tout ce guide.

---

#4. Procédures d'exploitation (runbooks)

Seize procédures. Chacune indique son déclencheur, le rôle requis, les étapes numérotées, et les critères de vérification — c'est-à-dire ce que vous devez voir à l'écran pour affirmer que la procédure a réussi.

---

#R1 — Créer un locataire de bout en bout

Déclencheur : nouvelle organisation cliente, nouveau pilote, nouvel espace interne. Rôle requis : administrateur plateforme (tenants:manage, users:manage, budgets:manage).

1. Ouvrez Locataires.
2. Cliquez Nouveau locataire.
3. Saisissez le Slug en respectant la règle : minuscules, chiffres, tirets, 3 à 40 caractères. Choisissez-le stable : il n'est pas modifiable ensuite.
4. Saisissez le Nom affiché (celui que verront les utilisateurs).
5. Effacez la valeur starter du champ Plan et saisissez un code réel : gratuit, team ou enterprise.
6. Validez. Attendez le message « Locataire créé. »
7. Repérez la nouvelle ligne dans le registre et cliquez Sélectionner.
8. Vérifiez que le sélecteur de la barre supérieure porte bien le nouvel identifiant.
9. Ouvrez Utilisateurs et créez le premier compte : c'est le futur propriétaire (voir R2).
10. Attribuez-lui le rôle OWNER.
11. Ouvrez Budgets & quotas et créez un budget de portée tenant avec une limite non nulle (voir R8).
12. Ouvrez État système et vérifiez que le tableau de bord répond pour ce locataire.

Critères de vérification

Pièges

• Laisser starter dans le champ Plan → locataire rattaché à un plan inexistant.
• Oublier le rôle OWNER → le locataire existe mais personne ne peut y travailler.
• Oublier le budget → aucune limite de dépense, aucun signal de dérive.

---

#R2 — Intégrer un nouvel utilisateur et lui donner le bon rôle

Déclencheur : arrivée d'une personne dans une organisation cliente. Rôle requis : administrateur plateforme (users:manage).

1. Sélectionnez le locataire d'accueil dans la barre supérieure. Vérifiez-le deux fois : un utilisateur créé dans le mauvais locataire devra être supprimé et recréé.
2. Ouvrez Utilisateurs, cliquez Nouvel utilisateur.
3. Saisissez le Courriel professionnel.
4. Saisissez un Mot de passe conforme : au moins 8 caractères, une majuscule, une minuscule, un chiffre. Ce mot de passe est provisoire et doit être transmis par un canal distinct du courriel.
5. Renseignez Prénom et Nom — facultatifs mais indispensables à la lisibilité du journal d'audit.
6. Validez. Message attendu : « Utilisateur créé. »
7. Sur la ligne du nouvel utilisateur, cliquez Modifier.
8. Dans Rôles (Keycloak), choisissez un seul rôle, le plus faible qui permette le travail attendu :

9. Cliquez Ajouter. Message attendu : « Rôle ajouté. »
10. Fermez le formulaire et vérifiez la colonne Rôles dans le tableau.

Critères de vérification

Rappel de moindre privilège. Les rôles sont composites : OWNER implique ADMIN, qui implique PUBLISHER, etc. N'empilez jamais plusieurs rôles ; un seul suffit toujours.

---

#R3 — Retirer un accès en urgence

Déclencheur : départ non planifié, compte compromis, comportement anormal. Rôle requis : administrateur plateforme (users:manage). Objectif de temps : moins de trois minutes.

1. Sélectionnez le locataire concerné.
2. Ouvrez Utilisateurs et filtrez sur le courriel.
3. Cliquez Modifier.
4. Retirez tous les rôles : cliquez la croix × sur chaque pastille. Il n'y a pas de confirmation ; l'effet est immédiat sur le serveur d'identité. Le bloc doit finir par afficher « Aucun rôle ».
5. Passez le Statut à Suspendu.
6. Validez. Message attendu : « Utilisateur mis à jour. »
7. Ouvrez Flotte d'agents et interrompez toute exécution attribuée à cette personne (voir R14).
8. Ouvrez Audit & conformité, filtrez sur Acteur = identifiant de la personne, et exportez les 30 derniers jours (voir R12).
9. Ne supprimez pas le compte. La suppression est irréversible et détruit la lisibilité du journal.

Critères de vérification

⚠️ Ce que cette procédure ne fait pas. Il n'existe aucun moyen de suspendre un locataire entier depuis le portail : le service concerné n'expose pas ce point d'entrée, et l'écran l'annonce. Pour couper l'accès d'une organisation complète, il faut retirer les rôles utilisateur par utilisateur, ou passer par une intervention d'exploitation hors portail.

---

#R4 — Approuver ou rejeter une revue en respectant la séparation des devoirs

Déclencheur : un pair vous transmet un identifiant de sujet à réviser. Rôle requis : administrateur plateforme (secret_access:approve), différent du soumetteur.

1. Vérifiez votre identité agissante sur la page Configuration. Sans elle, toute action sera refusée localement en 428.
2. Ouvrez Gouvernance & SoD.
3. Choisissez le Type de sujet : Version de skill ou Serveur MCP.
4. Collez l'Identifiant du sujet (UUID). Le bouton reste inactif tant que le format n'est pas un UUID canonique.
5. Cliquez Charger les revues.
6. Instruisez la demande avant de cliquer :

7. Pour la classe de risque Élevé, examinez le contenu du sujet sur la page Registre : provenance, licence, instructions, chemin de coffre, forme d'authentification.
8. Cliquez Approuver (2ᵉ contrôle) ou Rejeter.
9. Si le bouton d'approbation est désactivé, lisez le motif :

10. Rechargez les revues et vérifiez le verdict.

Critères de vérification

Ce que vous signez. Pour un sujet à haut risque, votre approbation transmet automatiquement l'attestation de revue de sécurité. Ne cliquez jamais « pour débloquer » sans avoir lu le contenu.

---

#R5 — Enregistrer un serveur d'outils MCP

Déclencheur : un locataire ou une équipe demande l'accès à un outil externe. Rôle requis : administrateur plateforme (registry:manage).

Phase A — préparer le coffre (hors portail)

1. Faites déposer le justificatif dans le coffre de secrets par la personne habilitée.
2. Récupérez le chemin et le nom des sous-clés. Jamais les valeurs.
3. Notez la forme d'authentification attendue par le serveur.

Phase B — enregistrer dans le portail

4. Ouvrez Registre, onglet Outils (MCP).
5. Cliquez Nouvel outil.
6. Renseignez Nom du serveur, URL / endpoint, Description.
7. Choisissez le Transport : http, sse ou stdio.
8. Choisissez le Type d'authentification et renseignez les sous-clés correspondantes :

9. Renseignez le Chemin Vault du justificatif. Il doit commencer par secret/. Il devient obligatoire dès que l'authentification n'est pas « Aucune ».
10. Renseignez éventuellement les En-têtes statiques (JSON non secret), le Délai d'expiration (ms) et le Chemin de santé.
11. Validez. Message attendu : « Outil MCP global enregistré. »

Phase C — faire approuver

12. Notez l'identifiant du serveur créé.
13. Transmettez-le à un autre administrateur plateforme, qui exécute R4.
14. Après approbation, l'outil devient liable à un rôle (R7 / §3.14).

Critères de vérification

Pièges

• Coller une valeur de secret dans le champ de chemin → incident, rotation immédiate.
• Oublier de faire approuver → l'outil reste inutilisable, sans message d'erreur explicite.

---

#R6 — Publier une compétence globale

Déclencheur : une compétence réutilisable doit être offerte à tous les locataires. Rôle requis : administrateur plateforme (registry:manage), et un second administrateur pour l'approbation.

1. Ouvrez Registre, onglet Skills.
2. Cliquez Nouveau skill.
3. Nom du skill — court, explicite, sans nom de client.
4. Description du déclencheur — au moins 20 caractères. Décrivez quand la compétence doit s'activer, pas ce qu'elle fait. C'est ce texte qui pilote la sélection automatique.
5. Version (semver) — commencez à 0.1.0.
6. Contenu / instructions — le corps de la compétence.

Le contenu est analysé à la recherche de secrets. Un jeton, une clé ou un mot de passe collé ici bloquera la publication, et il aura tout de même transité. Relisez avant de valider.

7. Validez. Message attendu : « Skill global créé (brouillon). »
8. Notez l'identifiant.
9. Transmettez-le à un autre administrateur, qui exécute R4 sur le type Version de skill.
10. Après approbation, la compétence est liable aux rôles.

Variante — import du seed curaté

1. Onglet Skills, panneau Importer le seed de skills globaux.
2. Lisez le manifeste : Capacité, Source, Licence.
3. Cliquez Importer les n skills.
4. Lisez le rapport : « n importés », « n ignorés », « n bloqués ».
5. Chaque élément importé reste En attente SoD. Traitez-les un à un avec R4.

L'import est idempotent : relancer ne crée pas de doublon (résultat Déjà présent).

Critères de vérification

---

#R7 — Réviser un plafond d'autonomie

Déclencheur : un rôle virtuel doit gagner ou perdre en autonomie. Rôle requis : administrateur plateforme (registry:manage). Prérequis : le drapeau des rôles virtuels doit être actif ; sinon la page affiche « Rôles virtuels IA désactivés ».

1. Ouvrez Rôles IA.
2. Sélectionnez le rôle dans Choisir un rôle.
3. Lisez la pastille du plafond courant (« plafond Nx »).
4. Ouvrez le panneau RPA & autonomie.
5. Choisissez le nouveau Plafond d'autonomie :

6. Cliquez Enregistrer le plafond. Message attendu : « Plafond d'autonomie enregistré. »
7. Calculez l'autonomie effective : min(plafond du rôle, maximum du plan du locataire).

8. Si le plan borne en dessous du plafond demandé, dites-le au demandeur. Élever le plafond dans le portail ne change rien tant que le plan ne suit pas.

Critères de vérification

Comportement de sécurité : en cas de valeur inconnue ou de dégradation, la résolution retombe sur N1. Le système échoue vers le bas.

---

#R8 — Définir un budget et réagir à un dépassement

Déclencheur : ouverture d'un locataire, ou dérive de consommation constatée. Rôle requis : opérateur plateforme (budgets:manage).

Partie A — poser le budget

1. Sélectionnez le locataire.
2. Ouvrez Budgets & quotas, cliquez Nouveau budget.
3. Portée — suivez la convention d'équipe. Formes acceptées par l'aide : tenant, project:FB, credential:abc.
4. Limite (USD) — nombre ≥ 0, pas de 0,01.
5. Seuil d'alerte (%) — laissez 80 sauf raison contraire.
6. Seuil critique (%) — laissez 95 sauf raison contraire.
7. Validez. Message attendu : « Budget créé. »

Partie B — réagir à un dépassement

8. La carte passe en Alerte, Critique ou Épuisé.

9. Ouvrez Fenêtres de quota et identifiez le Modèle de limite le plus consommé.
10. Ouvrez Flotte d'agents et repérez les exécutions les plus coûteuses.
11. Ouvrez Gouvernance & SoD, panneau Audit des accès aux justificatifs, et lisez la colonne Coût (USD) pour attribuer la dépense.
12. Décidez :
    • Relever la limite → Modifier sur la carte, ajustez, validez. Message : « Budget mis à jour. »
    • Restreindre → interrompez les exécutions en cause (R14), et abaissez le plafond d'autonomie du rôle concerné (R7).
13. Consignez la décision et son motif.

Critères de vérification

Rappel : supprimer un budget conserve l'historique de consommation ; seul le lien est dissocié.

---

#R9 — Activer un drapeau de fonctionnalité progressivement

Déclencheur : mise à disposition d'une nouvelle fonctionnalité. Rôle requis : opérateur plateforme (flags:manage).

1. Ouvrez Feature-flags sur l'environnement de qualification d'abord.
2. Cliquez Nouveau flag.
3. Clé — minuscules, chiffres, ., _, -, premier caractère alphanumérique, 128 caractères maximum. Choisissez une clé stable : elle n'est pas modifiable.
4. Portée — Locataire pour un pilote, Global pour une bascule plateforme.
5. Déploiement (%) — laissez 0.
6. Description — indiquez la date de création, le responsable et la date de retrait prévue.
7. Validez. Le drapeau est créé désactivé.
8. Relisez la ligne du tableau avant toute activation.
9. Cliquez Activer. Le drapeau est actif à 0 % : encore inerte pour tout le monde.
10. Montez le pourcentage par paliers, en observant entre chaque :

11. Pour ajuster : Modifier → Déploiement (%) → validez. Message : « Feature-flag mis à jour. »
12. En cas de dérive : cliquez Désactiver. Effet immédiat, sans confirmation.
13. Rejouez la séquence complète en production.

Critères de vérification

⚠️ Le bouton d'activation n'a pas de confirmation. Sur un drapeau global en production, un clic engage toute la plateforme.

⚠️ Un drapeau créé ici ne pilote pas les services backend. Les drapeaux réellement implémentés côté services sont des variables d'environnement. Voir §5.3 et §9.

---

#R10 — Changer le modèle de langage par défaut

Déclencheur : nouveau modèle disponible, changement de coût, incident fournisseur. Rôle requis : administrateur plateforme (models:manage).

1. Faites déposer le justificatif du fournisseur dans le coffre (hors portail) et récupérez le chemin.
2. Ouvrez Modèles & adaptateurs.
3. Notez la configuration par défaut actuelle — c'est votre point de retour arrière.
4. Cliquez Nouvelle config modèle.
5. Renseignez Clé, Fournisseur, Identifiant modèle.
6. Renseignez le Chemin Vault (secret/…). Doit commencer par secret/.
7. Ne cochez pas encore « Modèle par défaut ».
8. Validez. Message : « Configuration de modèle créée. »
9. Créez ou ajustez l'adaptateur qui pointe vers cette clé (§3.9), en recopiant la clé exactement.
10. Testez sur un locataire de recette ou sur le locataire de démonstration.
11. Une fois le test concluant : Modifier la configuration → cochez Modèle par défaut → vérifiez que Activé est coché → validez.
12. Rechargez et vérifiez qu'une seule ligne porte la pastille « Par défaut ».
13. Ouvrez Gouvernance & SoD et vérifiez que le chemin de coffre apparaît bien dans Politiques d'accès Vault.

Critères de vérification

Retour arrière : rouvrez l'ancienne configuration, recochez Modèle par défaut, décochez-la sur la nouvelle.

Piège classique. Un modèle par défaut désactivé casse tout sans message clair. Vérifiez toujours les deux cases ensemble.

---

#R11 — Durcir une politique d'exécution

Déclencheur : revue de sécurité, incident, préparation d'une mise en production. Rôle requis : administrateur plateforme (policies:manage).

1. Ouvrez Garde-fous & exécution.
2. Relevez l'état courant : Réseau, Egress (allowlist), Durée max (s), Système de fichiers. Notez-le : c'est votre point de retour arrière.
3. Cliquez Modifier sur la politique.
4. Politique réseau — laissez ou renforcez le préfixe deny-. L'interface refuse toute valeur qui ne commence pas par deny-.
5. Egress (allowlist) — réduisez la liste au strict nécessaire. Format : hôtes séparés par des virgules. Retirez tout hôte non justifié par un besoin écrit.
6. Durée max (secondes) — abaissez jusqu'à la valeur qui n'interrompt pas les traitements légitimes les plus longs. Une durée trop généreuse est une fenêtre d'exfiltration.
7. Système de fichiers — visez un espace de travail éphémère uniquement.
8. Validez. Message : « Politique d'exécution mise à jour. »

Volet garde-fous

9. Vérifiez qu'il existe une règle de refus sur les actions sensibles (déploiement en production, écritures de fichiers larges).
10. Vérifiez que les règles de refus ciblées ont une priorité plus petite que les règles d'autorisation larges — la plus petite priorité est évaluée en premier.
11. Cochez Exiger une approbation (HITL) même si autorisé sur les actions à effet irréversible.
12. Testez avec Évaluer une action : saisissez l'action, cliquez Évaluer, lisez le verdict, le nombre de règles correspondantes et l'identifiant appliqué.

Critères de vérification

Nuance importante. Si l'encadré « Évaluateur non raccordé » s'affiche, cela signifie que le simulateur de l'interface est absent — pas que les règles sont inertes. Le texte le dit explicitement : « Les règles ci-dessus restent réelles ». Testez alors par une exécution réelle sur un environnement de recette.

Attention aux nouvelles politiques. Les champs Egress et Système de fichiers n'existent pas dans le formulaire de création. Une politique fraîchement créée a donc une allowlist vide : avec un réseau en deny-, aucune sortie n'est autorisée. Éditez-la immédiatement après création.

---

#R12 — Produire un rapport de conformité Loi 25

Déclencheur : demande d'audit, revue trimestrielle, incident. Rôle requis : opérateur plateforme (audit:export).

1. Sélectionnez le locataire concerné. Un rapport porte sur un seul locataire.
2. Ouvrez Audit & conformité.
3. Exécutez d'abord R13 (vérification de la chaîne) : un rapport dont la chaîne est rompue n'a aucune valeur probante.
4. Descendez au panneau Rapports de conformité Loi 25.
5. Renseignez Période — début et Période — fin.
6. Cliquez Générer le rapport. Message attendu : « Rapport de conformité généré. »
7. Lisez la nouvelle ligne : Période · Événements · Chaîne vérifiée · Généré par · Créé le.
8. Vérifiez que Chaîne vérifiée affiche Oui.
9. Cliquez Exporter (JSON). Le fichier loi25-report-<identifiant>.json est produit par le navigateur.
10. Déposez le fichier dans votre coffre documentaire de conformité.

Critères de vérification

Une période sans événement produit un rapport valide horodaté, pas une erreur. C'est une attestation d'absence, et elle a de la valeur.

L'export JSON est local au navigateur : il ne laisse aucune trace serveur. Si votre politique impose de tracer les extractions, consignez-les manuellement.

---

#R13 — Vérifier l'intégrité de la chaîne d'audit

Déclencheur : contrôle hebdomadaire, préalable à tout rapport, soupçon d'altération. Rôle requis : lecteur suffit (config:read).

1. Sélectionnez le locataire.
2. Ouvrez Audit & conformité.
3. Cliquez Vérifier la chaîne.
4. Lisez le résultat :

5. En cas de rupture :
   1. Capturez l'écran : identifiant, motif, position.
   2. N'effectuez plus aucune écriture sur ce locataire.
   3. Alertez le responsable sécurité.
   4. Générez tout de même un rapport de conformité : il figera la constatation.
   5. Ouvrez le processus de réponse à incident en six phases (guide de durcissement).

Critères de vérification

---

#R14 — Interrompre une exécution d'agent

Déclencheur : boucle, coût anormal, comportement inattendu, incident de sécurité. Rôle requis : opérateur plateforme (fleet:interrupt).

1. Sélectionnez le locataire.
2. Ouvrez Flotte d'agents.
3. Identifiez l'exécution : nom de l'agent, statut En cours ou En file, étape courante, horodatage de mise à jour.
4. Avant de couper, cliquez la ligne pour ouvrir le Détail du run : Projet, Budget d'étapes, Démarré, Erreur du run. Notez ces informations : elles disparaissent de la vue active après interruption.
5. Cliquez Interrompre.
6. Lisez la confirmation : « Interrompre le run ? — Le run passera à l'état terminal « failed ». Cette action est irréversible. »
7. Confirmez. Message attendu : « Run interrompu. »
8. Vérifiez que le statut affiche Échoué.
9. Si le motif est un coût : enchaînez sur R8.
10. Si le motif est un comportement anormal : envisagez R7 (abaisser le plafond) ou §3.13 (mettre le membre du personnel virtuel en pause — nécessite le rôle administrateur).

Critères de vérification

Il n'y a pas de reprise : la seule suite est une nouvelle exécution.

Il n'existe pas d'interruption de masse ni de vue tous-locataires : le service isole les exécutions par locataire, et l'interface l'annonce (« Agrégation cross-tenant — écart backend »). Pour un incident touchant plusieurs locataires, répétez la procédure locataire par locataire.

---

#R15 — Provisionner puis réinitialiser le locataire de démonstration

Déclencheur : préparation d'une démonstration, remise à zéro après passage. Rôle requis : administrateur plateforme (demo:manage, flags:manage).

Phase A — activer le module

1. Ouvrez Feature-flags.
2. Cherchez la clé DEMO_MODULE_ENABLED. Si elle n'existe pas, créez-la avec la portée Locataire — le locataire de démonstration, jamais un autre.
3. Cliquez Activer.
4. Ouvrez Démo et vérifiez que le champ Activé est passé au vert.

Phase B — provisionner

5. Choisissez le Mode de provisionnement :
   • Rédigé (déterministe, sans LLM) — recommandé pour une démonstration commerciale : reproductible et sans consommation.
   • Agentique (exécutions LLM réelles via passerelle) — pour montrer les agents à l'œuvre ; consomme du budget réel.
6. Cliquez Provisionner. Message attendu : « Démo provisionnée ».
7. Attendez le rafraîchissement automatique (15 secondes) ou cliquez Actualiser.
8. Vérifiez : Provisionné = Oui, Ressources non nul, Version du manifeste renseignée, Projets listés.

Phase C — réinitialiser après la démonstration

9. Cliquez Réinitialiser. Aucune confirmation n'est demandée.
10. Message attendu : « Démo réinitialisée ».
11. Vérifiez que le compte de ressources correspond de nouveau au manifeste.

Phase D — retirer (optionnel)

12. Cliquez Supprimer, puis confirmez : « Archive les projets de démo et oublie le manifeste. Le tenant reste isolé par RLS ; réversible via Provisionner. »
13. Message attendu : « Démo supprimée ».

Critères de vérification

Le tableau du manifeste n'affichera jamais le détail des ressources : c'est un écart connu (§9). Seul le résumé « n ressources semées » s'affiche. Ce n'est pas une panne.

Ne créez jamais le drapeau DEMO_MODULE_ENABLED en portée Globale. Cela ouvrirait le module de démonstration sur tous les locataires.

---

#R16 — Basculer un environnement de dev-headers vers jwt

Déclencheur : ouverture d'un environnement à des utilisateurs réels, durcissement avant lancement. Rôle requis : administrateur plateforme + équipe d'exploitation. Criticité : cette bascule a déjà provoqué une interruption de service. Suivez l'ordre.

1. Préparer le serveur d'identité. Vérifiez le domaine d'identité, le client public PKCE du portail d'administration, et la déclaration de l'URI de redirection <origine>/auth/callback.
2. Trancher la question du domaine. La configuration partagée du backend décrit sso comme domaine réellement exploité et qualifie kyspectra de résiduel. Faites arbitrer ce point avant la bascule ; un domaine erroné rend la vérification de signature impossible.
3. Vérifier la règle de sortie réseau vers le serveur d'identité. Sur un espace en refus-par-défaut, l'absence de cette règle empêche la passerelle de récupérer les clés de signature : elle redémarre en boucle et tout le portail tombe, avec un symptôme qui ressemble à une erreur de partage de ressources entre origines. C'est un incident déjà survenu en production.
4. Basculer le backend en mode jwt.
5. Vérifier la santé de la passerelle avant de toucher au portail : elle doit répondre et servir l'agrégat de santé.
6. Reconstruire le portail avec le mode jwt et les paramètres du serveur d'identité.
7. Déployer le portail.
8. Tester la connexion : ouvrez le portail, vérifiez la redirection vers l'écran de connexion, authentifiez-vous, vérifiez le retour sur /auth/callback.
9. Vérifier l'identité dérivée : page Configuration → le panneau doit être en lecture seule avec la mention « Identité dérivée de la session Keycloak (jeton) — non modifiable ici. »
10. Vérifier les rôles : les pastilles doivent refléter les rôles du jeton, pas des cases cochées.
11. Vérifier chaque destination : parcourez les seize et confirmez qu'aucune n'affiche d'erreur d'autorisation.
12. Vérifier le tableau de santé : l'agrégat doit répondre. Sous jwt, il exige le jeton — un tableau entièrement rouge après bascule signale un jeton non transmis.

Critères de vérification

Retour arrière : reconstruire et redéployer le portail en dev-headers, et repasser le backend en dev-headers. Les deux doivent bouger ensemble, dans les deux sens.

---

#5. Réglages globaux — inventaire exhaustif

Trois familles de réglages coexistent. Ne les confondez pas : elles n'ont ni le même cycle de vie, ni la même portée, ni le même risque.

#5.1 Famille A — réglages locaux au navigateur

Ces valeurs vivent dans le stockage local du navigateur. Elles ne sont pas synchronisées entre postes et disparaissent avec le profil du navigateur.

En mode jwt, l'identité et les rôles ne sont plus des réglages : ce sont des lectures du jeton. Le portail les affiche sans permettre de les modifier.

#5.2 Famille B — réglages de plateforme, persistés

Ces réglages sont écrits côté serveur et s'appliquent à tout le monde.

#5.3 Famille C — variables d'environnement du portail

Toutes préfixées NEXT_PUBLIC_ et inlinées au moment de la construction. Les modifier exige une reconstruction puis un redéploiement ; il n'existe aucun moyen de les changer depuis l'interface.

#Routage vers les services

Règle de résolution rappelée : variable dédiée → passerelle → port local. La page Configuration affiche la cible réellement retenue et une pastille passerelle ou direct.

#Authentification

#Semis de développement

Aucune de ces variables n'est un secret — ce sont des URL, des identifiants publics et des UUID. Elles sont visibles dans le paquet servi au navigateur, par construction. N'y placez jamais une clé, un jeton ou un mot de passe.

#5.4 Variables d'environnement des services backend

Ces variables ne se règlent pas depuis le portail, mais elles conditionnent ce que le portail peut faire. Les valeurs ci-dessous sont celles du code.

⚠️ Constat à connaître. Vingt-cinq noms de drapeaux apparaissent dans les documents de conception (préfixes IGNITION_, MKT_, STAFF_, WORKFORCE_) sans exister nulle part dans le code. Ce sont des noms de conception, pas des réglages. Ne les cherchez pas et ne les documentez pas comme configurables.

#5.5 Rapport entre drapeaux du portail et drapeaux des services

Point de confusion fréquent, à énoncer clairement :

Créer dans la page Feature-flags une clé qui porte le nom d'une variable de service ne modifie pas ce service. L'unique exception documentée est DEMO_MODULE_ENABLED, que la page Démo indique explicitement d'activer par ce chemin.

---

#6. Sécurité et conformité

#6.1 Isolation multi-locataire, et pourquoi un 404 plutôt qu'un 403

Chaque requête portée transporte un identifiant de locataire. La résolution suit une précédence stricte :

1. L'en-tête X-Tenant-ID ;
2. À défaut, le locataire porté par le jeton vérifié ;
3. À défaut, le paramètre de requête.

Si l'identifiant demandé est en désaccord avec celui du jeton, la réponse est 404 — pas 403.

Ce choix est délibéré et il faut savoir l'expliquer.

Un 403 est une fuite d'information. Il permet d'énumérer les identifiants d'un concurrent, de confirmer qu'une organisation est cliente, de deviner des volumes. Le 404 supprime ce canal. C'est un masquage d'existence, exigence directe de la protection des renseignements personnels.

Conséquence pratique pour vous : un 404 sur une ressource que vous savez exister signifie presque toujours un mauvais locataire sélectionné, pas une ressource supprimée. C'est le premier réflexe de diagnostic.

Un unique aménagement existe : un administrateur de plateforme vérifié peut cibler le locataire technique de plateforme. C'est ce qui permet aux pages Registre et Rôles IA de fonctionner.

#6.2 Journal d'audit chaîné

Chaque entrée porte une empreinte calculée à partir de son contenu et de l'empreinte de l'entrée précédente. Modifier une entrée passée invalide toutes les suivantes.

Propriétés :

Ce que le journal ne fait pas : il ne trace pas l'export JSON local (produit par le navigateur), et il ne remplace pas les journaux d'infrastructure.

#6.3 Séparation des devoirs

Trois barrières successives :

Le rejet reste possible par le soumetteur : retirer sa propre demande n'est pas un contournement.

Le second contrôle est asymétrique par conception : proposer un élargissement (secret_access:widen) est ouvert à l'opérateur ; l'approuver (secret_access:approve) est réservé à l'administrateur. Un opérateur ne peut donc jamais boucler seul le cycle.

Implication d'organisation. Il faut au moins deux administrateurs plateforme distincts en exploitation. Avec un seul, aucune publication de capacité globale ne peut être approuvée : la plateforme se bloque par construction. Prévoyez-en trois pour couvrir les absences.

#6.4 Refus par défaut

Message affiché quand la table de garde-fous est vide : « Aucune règle de garde-fou. L'évaluation refuse toute action par défaut. »

#6.5 Gestion des secrets par coffre

Règle unique : le portail ne voit jamais un secret. Il ne manipule que des chemins et des noms de sous-clés.

Trois contrôles concourants :

1. Validation de forme — un chemin qui ne commence pas par secret/ est refusé.
2. Analyse de contenu — les instructions de compétence sont analysées à la recherche de secrets avant publication.
3. Séparation des devoirs — l'élargissement d'un accès à un justificatif exige un second contrôle.

En cas de suspicion de secret exposé :

1. Effectuez la rotation du secret dans le coffre.
2. Corrigez ou supprimez la configuration fautive.
3. Révoquez la capacité concernée avec un motif explicite.
4. Exportez le journal d'audit sur la période.
5. Ouvrez la procédure de réponse à incident.

#6.6 Que faire en cas d'incident de confidentialité

Réaction immédiate, dans l'ordre :

1. Constater et horodater. Notez l'heure, le locataire, la ressource, le canal de découverte.
2. Figer. Vérifiez la chaîne d'audit (R13) et générez un rapport de conformité sur la période (R12) : cela fige la constatation avec attestation d'intégrité.
3. Contenir. Retirez les accès (R3), interrompez les exécutions (R14), révoquez les capacités impliquées (§3.11), désactivez le drapeau qui exposait la fonctionnalité (R9).
4. Qualifier. Déterminez la nature des renseignements en cause, le nombre de personnes concernées, et si le risque est sérieux — c'est ce dernier point qui déclenche l'obligation de déclaration.
5. Notifier. Selon la qualification, informez l'autorité compétente et les personnes concernées. Les délais et le contenu relèvent du responsable de la protection des renseignements personnels, pas de l'administrateur plateforme.
6. Corriger et consigner. Corrigez la cause, documentez, et versez le rapport de conformité au registre des incidents.

Ce que le produit vous apporte pour cette procédure :

---

#7. Supervision quotidienne, hebdomadaire et mensuelle

#7.1 Santé des services

Neuf services sont sondés. Trois états, à distinguer rigoureusement :

Une bascule répétée entre En service et Hors service sur un service à réplique unique indique presque toujours une sonde de vitalité couplée à la base de données : à la moindre latence, le conteneur est redémarré. Voir §8.

#7.2 Indicateurs à suivre

#7.3 Rituel quotidien — 10 minutes

1. État système, locataire principal : lisez le bandeau de synthèse.
2. Vérifiez qu'aucun service n'est Hors service ni en Sonde indisponible.
3. Lisez Brèches SLO récentes et Incidents ouverts.
4. Flotte d'agents : repérez les exécutions bloquées ou en échec anormal.
5. Budgets : vérifiez qu'aucune carte n'est passée en Alerte ou au-delà.
6. Gouvernance : traitez les revues en attente qui vous ont été signalées.
7. Répétez les points 1 à 5 pour chaque locataire actif significatif.

#7.4 Rituel hebdomadaire — 45 minutes

1. Vérifiez la chaîne d'audit de chaque locataire actif (R13). Consignez le nombre d'entrées.
2. Revue des accès : parcourez la page Utilisateurs de chaque locataire. Cherchez les comptes sans activité, les rôles trop élevés, les OWNER multiples.
3. Revue des dérogations : toute dérogation Autoriser sans motif écrit est à réexaminer.
4. Revue des drapeaux : tout drapeau à 100 % depuis plus d'un mois devrait être retiré du code puis supprimé. Tout drapeau à 0 % depuis longtemps est probablement mort.
5. Revue des budgets : comparez la consommation à la semaine précédente.
6. Revue du registre : vérifiez qu'aucune entrée n'est restée en attente de revue plus d'une semaine.
7. Revue de la flotte : proportion d'échecs, durées anormales.

#7.5 Rituel mensuel — 2 heures

1. Rapport de conformité Loi 25 par locataire (R12), avec export et archivage.
2. Revue complète des accès : liste nominative, rôle, justification, date de dernière connexion. Faites valider par le responsable de chaque locataire.
3. Revue des politiques d'exécution : chaque hôte de l'allowlist d'egress doit avoir une justification écrite. Retirez les autres.
4. Revue des garde-fous : vérifiez l'ordre des priorités ; testez cinq actions sensibles avec Évaluer une action.
5. Revue des modèles : coût par modèle, pertinence du modèle par défaut, configurations orphelines.
6. Revue des serveurs d'outils MCP : chaque serveur est-il encore utilisé ? Ses justificatifs ont-ils été renouvelés ?
7. Revue des plafonds d'autonomie : chaque rôle en N2 ou N3 est-il toujours justifié ?
8. Test de retour arrière : sur l'environnement de qualification, désactivez puis réactivez un drapeau, et mesurez le temps de bascule.
9. Revue des écarts connus (§9) : lesquels ont été corrigés, lesquels persistent ?

#7.6 Ce que la supervision ne couvre pas

---

#8. Dépannage administrateur

#8.1 Tableau symptôme → cause → action

Trente entrées, classées par famille. La colonne « Cause » indique la cause la plus probable, pas la seule.

#8.2 Arbre de décision : « un panneau ne s'affiche pas »

#8.3 Réflexes de diagnostic, dans l'ordre

1. Quel locataire est sélectionné ? — cause n°1 des symptômes inexplicables.
2. Quelle identité et quels rôles ? — page Configuration.
3. Quelle URL cible ? — page Configuration, colonne URL cible et pastille passerelle/direct.
4. Quel état de santé ? — page État système, en distinguant « Hors service » de « Sonde indisponible ».
5. Quel message exact ? — le portail distingue soigneusement « non raccordé », « désactivé par indicateur » et « indisponible ». Ces trois mots appellent trois actions différentes.
6. Le mode d'authentification est-il cohérent des deux côtés ?

---

#9. Écarts connus et limites actuelles

Section franche. Tout ce qui suit est vérifié dans le code au 2026-08-17. Rien n'est minimisé.

#9.1 Défauts d'affichage — à corriger avant le jour J

#9.2 Fonctionnalités non raccordées

#9.3 Écarts backend affichés honnêtement dans l'interface

Ces trois écarts sont signalés à l'utilisateur par des encadrés dédiés. C'est le comportement voulu.

#9.4 Fonctionnalités derrière un drapeau désactivé par défaut

⚠️ Vingt-cinq noms de drapeaux figurent dans les documents de conception sans exister dans le code (préfixes IGNITION_, MKT_, STAFF_, WORKFORCE_). Ce sont des noms de conception, jamais des réglages livrés. Ne les documentez pas comme configurables, ne les annoncez pas.

#9.5 Écarts de configuration et de données

#9.6 Limites d'architecture assumées

#9.7 Ce qui est Planifié et ne doit jamais être annoncé comme disponible

#9.8 Synthèse : les six prérequis de lancement issus de ce guide

---

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.