Tableau de bord
Société Alpha
Ici tu définis comment le cabinet travaille : les procédures (la suite d'étapes pour traiter un dossier) à partir de compétences d'agents. C'est le modèle — il se déroule ensuite sur chaque dossier (vue Dossiers). Chaque étape peut passer par une porte Écluse (validation humaine) ; les playbooks (PowerShell, Python…) sont propose-only, validés avant exécution.
Les skills de la box — briques réutilisables (IA, Python, PowerShell…) que les agents enchaînent dans les workflows, sous Écluse.
Le cerveau de la box, en action.
pav8 ne se contente pas de surveiller : elle corrèle, déduit la cause, décide et agit — en autonomie, sous contrôle.
La boucle autonome
du signal brut à l'action — comment l'information traverse le cerveauLes agents au travail
anneau vert = en action à l'instantDécisions autonomes
ce que l'IA a tranché — avec le pourquoiDerniers traitements par élément
sur quel équipement l'IA est intervenue en dernier, et avec quel résultatConseil d'experts
tour de table multi-agents animé par le DSILes concepts, en chiffres
chaque brique d'intelligence, branchée sur la boxVue d'ensemble agrégée sur une fenêtre — disponibilité, incidents, état par cible et principaux indicateurs, à partir de l'historique profond.
Disponibilité par cible
Principaux indicateurs (top)
Choisis un produit à superviser : clique une tuile, renseigne les accès, la sonde s'auto-configure. Les modules ai sont générés par l'IA pour un équipement non couvert.
Catalogue des sondes
L'équipe : un rôle, un visage, une fiche de poste. Chaque agent raisonne via l'IA (modèle réglable) et dispose d'outils (🚦 = action validée à l'Écluse · ✨ = outil créé par un agent). Il peut créer un outil (creer_outil) ou un playbook (creer_skill) — validés à l'Écluse.
L'équipe métier de ta box : un rôle, un visage, une fiche de poste. Chaque agent raisonne via l'IA (modèle réglable) et agit sur les dossiers sous validation à l'Écluse. Tu peux en créer d'autres en langage naturel.
Le détail des accès d'un agent : sous quel compte il agit sur chaque système (moindre privilège). Choisis un agent pour voir ses identités.
Des réunions animées par le DSI (David) : tu choisis un sujet, un ordre du jour et les agents invités (et éventuellement une planification). Au lancement, chaque invité fait son tour de table, puis le DSI synthétise et tranche. Idéal pour un incident : « comment le résoudre le plus vite ».
Nouvelle réunion
Réunions
Les projets — c'est toi qui les crées. La cheffe de projet Chloé les cadre (objectif → tâches), coordonne les agents de métier, et tu suis l'avancement en Kanban (à faire · en cours · fait).
Nouveau projet
L'historique des passages d'agents (déclenchés par planification, incident ou demande). Clique un run pour voir son analyse et le détail des outils appelés — entrée & résultat.
File des runs
Journal d'audit — chaque action des agents est tracée : qui, quoi, quand, sur quel élément, avec quel résultat. Les actions et décisions sont consignées dans un journal append-only immuable (non modifiable), complété pour l'historique antérieur par les données persistées (runs, Écluse). Filtrable et exportable CSV.
Les skills sont des procédures nommées que les agents suivent. Un skill peut aussi porter un artefact d'automatisation que l'agent écrit — Ansible, PowerShell, Python ou sh — affiché pour revue. Propose-only : ces artefacts sont des modèles à exécuter manuellement (le système ne les lance pas tout seul). Pour de l'exécution réelle, les agents utilisent leurs outils (WinRM/SSH/kubectl…) sous validation Écluse. Les agents peuvent proposer de nouveaux skills.
Les skills sont des étapes réutilisables que les agents enchaînent dans les workflows (extraction, synthèse, contrôle de cohérence…). Un skill peut être une étape IA ou un playbook (PowerShell, Python…). Propose-only : validé à l'Écluse avant toute exécution. Tu peux en créer de nouveaux avec l'IA.
Historique des décisions
Les demandes & incidents — ouverts par un utilisateur (installation d'un logiciel, souci réseau…) ou par un agent via l'Écluse. Le helpdesk qualifie, suit et clôt ; ce qui demande une main humaine est escaladé à ComputerHelper.
File des tickets
Où en sont vos demandes
Chaque demande et chaque incident, avec son avancement, qui s'en occupe en ce moment, ce qui a été fait et la prochaine étape.
Les runners d'exécution (moteurs sur lesquels les agents lancent leurs playbooks, sous Écluse) et l'historique de ce qui a tourné — avec le résultat OK / NOK. Configurables dans Réglages → Runners d'exécution.
Les moteurs d'exécution des playbooks de tes skills (sous Écluse) et l'historique de ce qui a tourné (OK / NOK).
Exécutions
Les procédures du site — ce que les agents consultent (outil chercher_kb) avant de répondre à une demande ou d'agir. Recherche sémantique (RAG) : chaque article est enrichi par l'IA et retrouvé par similarité, même en paraphrase. Modèle réglable (local souverain, ou Voyage) dans Réglages.
Mnémosyne — la bibliothèque de veille. Des documents de recherche produits à la main, par ticket ou par la CI, consultables ici. Un document marqué RAG rejoint la base de connaissance (outil chercher_kb) : les agents s'en servent dans leurs recherches.
La carte vivante de l'infra du site : briques auto-découvertes depuis la supervision (par domaine, avec statut) + celles que tu ajoutes à la main. Les liens sont inférés (cœur réseau, sauvegarde→stockage) et annotables. Les agents la consultent (outil cartographie).
Carte de l'infrastructure
Comment le client se connecte (scénario A/B/C) et les identités des agents (comptes de service scopés). Le compte de bind est write-only. Le provisioning écrit dans l'annuaire du client → il ne s'exécute qu'une fois la box sur son réseau, et passe par l'Écluse.
Configuration
Sans annuaire : comptes cockpit locaux + lien magique, accès équipements scellés. Rien à provisionner dans un annuaire.
Plan de provisioning
Le provisioning part à l'Écluse pour validation, puis s'exécute quand la box atteint l'annuaire.
Identités de service par agent (multi-système)
Pour chaque agent, choisis un profil de droits (moindre privilège) par système. « Relancer » réconcilie l'état réel : Kubernetes crée le compte de service + le rôle scopé + le token (et le câble à la sonde) ; AD passe par l'Écluse ; les briques fédérées (vCenter, Windows) réutilisent le compte AD de l'agent via son groupe. Les équipements non fédérés (UniFi, Veeam, NAS…) n'apparaissent pas ici : leur accès se gère par un identifiant scellé par équipement, dans « Accès aux équipements ».
Credential d'admin Kubernetes (pour provisionner)
Un token de ServiceAccount avec droits de création (SA, ClusterRole, ClusterRoleBinding, TokenRequest). Sert uniquement au provisionnement, scellé dans la box.
Credential d'admin Synology (pour créer les comptes DSM)
Un compte DSM autorisé à gérer les utilisateurs. La box crée un compte orgabox-<agent> avec un mot de passe généré, scellé. (MFA à désactiver sur ce compte de service.)
Accès aux équipements (hors AD)
Les comptes de service / clés API par équipement (vCenter, Synology, UniFi…) — write-only, scellés dans la box, réutilisés par les sondes et les agents. Chaque éditeur a sa propre mécanique : tu crées une fois un accès à moindre privilège, tu le renseignes ici.
Les agents proposent des améliorations (nouveaux savoir-faire, révisions de skills, outils) à partir de l'activité réelle du cabinet ; tu valides. Rien n'est créé ni activé sans ton approbation — ouroboros bridé : la boucle se referme sur ta décision.
Propositions d'amélioration
Le moteur IA des agents — provider, modèle et clé. La clé est write-only (jamais réaffichée) et vit dans un secret ; la prise en compte est immédiate, sans redéploiement. Provider-agnostique : Claude (forfait/API) ou passerelle locale souveraine.
Automatismes planifiés
Active ou désactive les tâches qui tournent toutes seules : réconciliation SRE (self-healing temps réel), scan infra, maintenance prédictive, revue sécurité. Effet immédiat (à chaud).
Consignes du site
Contexte & règles propres à ce client, injectés dans le contexte de TOUS les agents (horaires d'activité, équipements à ne pas toucher, contacts, spécificités…). Éditable à tout moment ; effet immédiat au prochain run.
Runners d'exécution
Moteurs d'exécution des playbooks que les agents rédigent eux-mêmes (sous Écluse). Pointe un équipement supervisé existant : un runner Windows (WinRM → PowerShell/PowerCLI, ex. actions vCenter) et un runner Linux (SSH → Ansible/sh). Les identifiants restent scellés dans l'équipement pointé. Les agents ciblent alors « runner-windows » / « runner-linux ».
Moteur IA
Gouvernance
Coupe tous les agents d'un coup, plafonne la dépense IA, et suis les coûts du jour. En forfait le coût est 0 € ; le budget agit en mode API facturé (disjoncteur : runs en pause au-delà du plafond).
Disque du nœud
Après avoir ajouté du disque côté vCenter (puis validé l'extension du disque virtuel), récupère l'espace pour le cluster k3s : extension en ligne partition → volume → système de fichiers. Non destructif. L'action passe par l'Écluse (validation humaine) et s'exécute à l'approbation.
Légifrance — référentiel réglementaire (RAG)
Connecte l'API Légifrance (DILA via PISTE, OAuth2) pour enrichir le RAG avec les textes officiels (CGI, LPF…). Souverain : on tire la loi publique dans la KB locale ; au requêtage, tout reste hors-ligne. Clés via piste.gouv.fr (app abonnée à l'API « Légifrance », prod approuvée). Le secret est write-only.
Numérotation des dossiers
Référence auto-attribuée à la création. Jetons : {CLIENT} {TYPE} {AAAA} {AA} {MM} {SEQ}.
Paramètres fiscaux (pré-chiffrage)
Paramètres millésimés du moteur assiette.calculer (CIR/CII). Source de vérité unique, versionnée. Un paramètre marqué « à affiner » rend tout chiffrage non opposable tant qu'il n'est pas confirmé sur le texte officiel (CGI art. 244 quater B / BOFiP). La mise à jour (nouveau millésime) passe par l'Écluse.
Voir les paramètres bruts (sources par ligne)
Ressources des conteneurs
Pour chaque conteneur : le Garanti (ressources qui lui sont réservées en permanence) et le Plafond (maximum qu'il ne peut pas dépasser). CPU : 1 = un cœur, 250m = ¼ de cœur. Mémoire : Mi ≈ Mo, Gi ≈ Go. « Consommée » = usage en temps réel. Augmenter une valeur redémarre le conteneur (brève interruption).
En-tête du cabinet
L'identité du cabinet utilisée en en-tête des rapports officiels et en signature des courriels générés depuis un dossier. Modifiable à chaud (aucun redéploiement).
La recherche sémantique de la base de connaissance (RAG). Par défaut : embedding local souverain (aucun appel externe). Pour la qualité maximale, branche un fournisseur — Voyage AI ou compatible OpenAI. Après un changement, réindexe la KB.
Embeddings (RAG)
Notifications e-mail
Un e-mail est envoyé uniquement à l'ouverture d'un incident de supervision, aux destinataires ci-dessous. Sobre, sans digest.
Connecteur mail (helpdesk)
La box lit une boîte support en IMAP (connexion sortante — compatible « sans port entrant ») : chaque nouveau mail ouvre un ticket helpdesk, les réponses au fil s'ajoutent au ticket. M365/Google : mot de passe d'application (OAuth2 à venir). L'accusé de réception utilise le SMTP configuré ci-dessus (Notifications e-mail).
Équipe & accès
Comptes, rôles et visibilité par espace. Rôles : Admin (tout + gestion des accès), Collaborateur (travaille sur les dossiers), Lecture (consultation). Visibilité : un compte sans espace attribué voit tous les dossiers ; cocher des espaces (bouton « Espaces ») restreint sa vue à ceux-ci. Les comptes de l'annuaire AD apparaissent à leur première connexion.
Annuaire Active Directory (LDAPS)
Les utilisateurs se connectent avec leur compte Windows du domaine. La box n'est pas jointe au domaine : elle lit l'annuaire via un compte de service en LDAPS et mappe les groupes de sécurité vers les rôles OrgaBox. Le rôle est réévalué à chaque connexion. Aucune synchro : rien à provisionner côté box.
OrgaBox-Admins/Approbateurs/Utilisateurs) directement dans l'annuaire via le compte de bind, et remplit le mapping. Idempotent. Le compte de bind doit pouvoir créer des objets (compte délégué, ou admin le temps de l'opération).
SSO cloud — Microsoft 365 / Entra ID (OIDC)
Les utilisateurs se connectent avec leur compte Microsoft 365. Crée une inscription d'application dans Entra ID (Azure AD), autorise l'URI de redirection ci-dessous, et mappe les app-roles (recommandé) ou des groupes Entra vers les rôles OrgaBox. Rôle réévalué à chaque connexion.
Zone de maintenance
Réinitialise l'historique d'exploitation : tickets, incidents, notes, propositions Écluse et runs d'agents. Irréversible. Ne touche pas à la config (agents, accès, runners, secrets, connaissance).
Réinitialiser les dossiers (retest)
Ramène tous les dossiers à l'étape « Ouverture » et vide l'historique d'exploitation (statuts, chiffrages figés, échéances, runs d'agents, audit). La confirmation d'opposabilité des paramètres fiscaux est conservée (c'est un acte de l'expert, indépendant des dossiers). Les pièces d'entrée sont conservées (liasse + tes dépôts) et complétées si une pièce de base manque ; en revanche les documents produits par les agents (livrables, rapports, courriers, dossiers complets) sont supprimés. Les fils de chat et rattachements de livrables (locaux au navigateur) sont effacés. Irréversible.