Aller au contenu

Référence

Catalogue de modules

Le catalogue de modules d'Olivares AI — ce que chaque module gouverne et observe, et où l'actionnement est live, provisionné à la demande.

Dernière mise à jour:

Olivares AI est une plateforme modulaire : un moteur plus un catalogue de modules de capacités plus des connecteurs. Un module consomme des événements normalisés du noyau, déclare ses entités dans le modèle de données partagé, et expose sa propre API et ses vues — sans re-architecturer le reste.

Le binaire standard câble 29 packages de modules, organisés ci-dessous en domaines de capacité numérotés (le tableau regroupe plusieurs packages dans un seul domaine, et quelques entrées sont de la plomberie fondamentale ou post-v1). Lisez-le comme un catalogue, pas une liste de fonctionnalités à cocher : gouverner/observer est large et actif à travers l’environnement ; l’actionnement est la partie étroite et contrôlée — chaque ligne est marquée live, provisionné à la demande (503 jusqu’à configuration), ou point d’accès fermé par défaut. La plateforme est pré-1.0. Voir Transparence et limites pour comment nous formulons ce qui est et n’est pas construit.

Au-delà du catalogue numéroté, il y a un module de support live-ingest (numéroté XXIV dans le code) : le tap d’événements en direct que les autres modules lisent. C’est de la plomberie plutôt qu’une surface autonome, il n’est donc pas compté parmi le catalogue numéroté.

Comment lire le statut de chaque module

Chaque module a deux moitiés, et la distinction honnête entre elles est tout l’intérêt :

  • Gouverner / Observer — cataloguer, observer, comparer, contrôler, rapporter. Ceci est construit et câblé aujourd’hui pour les modules marqués comme live ci-dessous. Le produit est lecture d’abord et détective par défaut : il surveille et gouverne hors bande, il ne se place pas dans le chemin de requête.
  • Actionner — agir sur votre infrastructure réelle (déployer, déclencher, dispatcher, envoyer, appliquer). Ceci est délibérément étroit et tombe dans trois états :
    • live — câblé dans le binaire par défaut, pas de provisionnement requis.
    • on-demand — le backend est construit et câblé à un point d’injection mais reste fermé par défaut jusqu’à ce qu’un opérateur le provisionne via config ; jusque-là, une action approuvée est honnêtement « déclarée, pas actionnée » (par exemple, deploy apply/retire retournent un 503 clair).
    • seam — une interface déclarée et fermée par défaut sans backend par défaut encore.

La séparation est le contrat : le produit observe et gouverne largement, et actionne sur un sous-ensemble petit, principalement contrôlé par provisionnement. Rien ici ne prétend une exécution que le code ne fait pas.

Découverte et état en direct

#ModuleGouverner/ObserverActionnerCe qu’il fait
IInventaire et découvertelive—Découvre et catalogue passivement les agents, sessions, serveurs MCP, outils, modèles, fournisseurs et identités non-humaines à travers l’environnement.
IIOpération en direct et sessionslive—Suit l’état en temps réel de chaque session d’agent — action en cours, tokens/coûts en direct, une timeline rejouable — dérivé des signaux, jamais fabriqué.
IIICarte d’accès et de ressources (R/RW)live—Le différenciateur : quel agent lit (R) ou lit-écrit (RW) quelle ressource, et si cet accès est permis ou simplement observé. Voir la visite.
XXIISanté, SLA et disponibilitélive—Fiabilité des agents et serveurs MCP — sain, dégradé ou en panne, et la carte de dépendances — dérivée des signaux observés, pas par sondage de votre infra.

Capacités, identité et gouvernance

#ModuleGouverner/ObserverActionnerCe qu’il fait
VMCP, skills et capacitéslive—Gestion visuelle des serveurs MCP, skills, plugins/sous-agents et quel agent est câblé à quel outil. Voir la visite MCP.
VIIdentité, permissions et gouvernanceliveon-demandGouverne qui et quoi peut faire quoi, avec approbation HITL. Les actionneurs de cycle de vie d’identité en écriture sont opt-in et fermés par défaut jusqu’à provisionnement. Voir la visite identité.
VIIIDonnées, connaissance et contexteliveliveLe plan de données gouverné — bases de connaissances et RAG avec rédaction avant indexation, récupération gouvernée, et traçabilité sur le plan de données gouverné — les données de gouvernance d’Olivares restent dans une infrastructure que vous contrôlez ; les requêtes vers les modèles hébergés vont aux fournisseurs que vous choisissez. La récupération lexicale est le défaut ; les embeddings sémantiques par modèle sont câblés à la demande.
XIVCatalogue interne et marketplacelive—Curate et permet à l’organisation de réutiliser des agents, serveurs MCP, skills et templates approuvés et versionnés ; les demandes d’instanciation passent par la gouvernance.

Déploiement et pile de modèles

#ModuleGouverner/ObserverActionnerCe qu’il fait
VIIDéploiement et intégrationliveon-demand (503)Planifie et gouverne les déploiements/câblages vers l’infrastructure — le seul module qui peut la muter. Chaque changement est contrôlé HITL, plan-avant-application et enregistré au registre. L’exécuteur est câblé à la demande : apply/retire retournent 503 jusqu’à provisionnement.
XGestion des modèles et fournisseursliveroutage uniquementGouverne et route à travers toute la pile de modèles — Claude, OpenAI, Gemini, inférence locale — avec tarification de référence vérifiée par l’opérateur. La résolution de route est live ; l’appel de modèle lui-même s’exécute à la demande une fois un identifiant d’inférence provisionné.

Les modèles hébergés ne sont pas auto-hébergeables. Le module X peut router vers Claude (directement ou via Bedrock/Vertex/Foundry), mais cette inférence atteint toujours l’API du fournisseur. Seuls les modèles véritablement auto-hébergés (vLLM/Ollama) fonctionnent entièrement hors ligne ; l’air-gap s’applique au plan de contrôle Olivares, pas à l’inférence hébergée.

Coûts, qualité et conformité

#ModuleGouverner/ObserverActionnerCe qu’il fait
XICoûts et AI FinOpsliveliveComptabilise les dépenses IA depuis le flux de coûts fournisseur et applique les budgets — au plafond, un contrôle budgétaire throttle/block refuse la dépense (fermé par défaut). Voir la visite FinOps.
XIIQualité, évaluations et testslive—Note les sorties candidates contre des suites dorées versionnées avec des scoreurs déterministes plus un juge LLM, produisant des preuves cross-modules. Voir la visite évaluations.
XIIIConformité et réglementairelive—Mappe ce que la plateforme observe et audite déjà sur des frameworks (AI Act européen, NIST AI RMF, ISO/IEC 42001, SOC 2, GDPR, OWASP Agentic) et émet des preuves consommables par les auditeurs. Conçu en vue de, pas certifié. Voir la visite conformité.

Sécurité et assurance

#ModuleGouverner/ObserverActionnerCe qu’il fait
IXSécurité, garde-fous et auditliveliveLe plan défensif : garde-fous sur le texte d’entrée/sortie/outil des agents (PII, secrets, injection de prompt, OWASP Agentic Top 10), détection d’anomalies sur la dérive observée, et timelines d’incident reconstituables. Les découvertes émettent en direct ; les preuves stockent un hash plus un extrait réduit, jamais la charge utile brute.
XVIISandbox de test d’agentsliveon-demandExécutions isolées et éphémères de scénarios d’agents contre des ressources mockées, plus rejeu déterministe. Le runner synthétique in-process est live ; le runtime isolé au niveau OS est câblé à la demande.
XVIIIRed-teaming et tests adversariauxliveon-demandUn harnais de robustesse défensive (injection de prompt, jailbreak, exfiltration, empoisonnement d’outil) mappé sur OWASP Agentic et MITRE ATLAS. Les exécutions isolées sont câblées à la demande et rapportent DEGRADED — jamais un faux succès — jusqu’à ce qu’un runtime sandbox soit provisionné.

Coordination, voix et sortie

#ModuleGouverner/ObserverActionnerCe qu’il fait
IVCommunication inter-agents et orchestrationliveon-demandDérive le graphe de délégation/communication en direct depuis les arêtes observées et gouverne les agents planifiés/autonomes. En déclencher un est biphasé et contrôlé HITL ; le dispatch en direct est fermé par défaut jusqu’à ce qu’un dispatcher soit provisionné.
XVIntégrations de sortie et notificationsliveliveLe routeur de notifications — décide quel signal va à qui, par quel canal ; les connecteurs (Slack/Teams, PagerDuty/Opsgenie, webhook signé, SIEM) livrent. Le dispatch est live ; les destinations sont provisionnées par l’opérateur.
XVIAgents vocaux et temps réelliveon-demandObserver-et-gouverner pour les agents conversationnels/temps réel : gouverne qui peut ouvrir une session, avec quel modèle, sous quelle politique de refus par défaut. L’ouverture est contrôlée HITL ; l’actionnement passe par un dispatcher fermé par défaut jusqu’à ce qu’un fournisseur vocal soit provisionné.

Plateforme et reporting

#ModuleGouverner/ObserverActionnerCe qu’il fait
XIXAPI propre et manage-as-codelive—Gérer le plan de contrôle lui-même par API/IaC, plus une surface d’événements orientée intégrateur (abonnements durables, retries, dead-letter, rejeu). Fondamental.
XXMulti-tenancy et gestion d’organisationlive—Hiérarchie d’organisation et admin délégué pour les MSP et grandes organisations. Fondamental.
XXITableaux de bord exécutifs et reportinglive—Vues de haut niveau pour la direction aux côtés de la console technique.
XXIIIGestion/fine-tuning de modèles proprespost-v1—Gouverner les modèles entraînés ou hébergés par l’entreprise. Post-v1 — pas câblé aujourd’hui.

Note transversale : le coupe-circuit

Au-delà de tout module individuel, le coupe-circuit de l’environnement câble un contrôle d’arrêt dans chaque point d’actionnement : deploy, orchestration fire, voice open, exécution de modèle et dépense budgétaire. Un arrêt est une application positive et fermée par défaut — un état d’arrêt illisible est traité comme arrêté, jamais comme un laissez-passer. Voir la visite coupe-circuit.

Voir aussi

Rechercher la documentation