Architecture
La spécification, pour votre équipe plateforme
graal Data Platform d’abord : ce qu’elle installe, ce qu’elle crée à l’exécution, ce qu’elle ne crée jamais, et ce que vous fournissez une fois. Puis graal Agentic Platform : ses composants et ce qui encadre chaque run. De quoi valider une installation avant la première commande.
Data Platform · Le rendu
Deux namespaces, et rien au-dessus
La Data Platform s’installe dans un cluster Kubernetes ou OpenShift existant, sans objet à l’échelle du cluster.
- namespaces, fournis par votre équipe plateforme
- 2
- CRD : aucune ressource personnalisée
- 0
- droit cluster-admin, aucun rôle global
- 0
- des pods en PSA restricted, traitements compris
- 100 %
Data Platform · Composants
Ce qui tourne, et où
Toutes les images sont épinglées par empreinte et tirées du registre que vous désignez.
| Composant | Rôle | Namespace |
|---|---|---|
| Console | Interface web des équipes : projets, pipelines, jobs, catalogue, modèles, agents. | graal |
| API graal | Contrat REST décrit en OpenAPI ; droits, audit, secrets et orchestration des traitements. | graal |
| Passerelle LLM | Intégrée à l’API : modèles locaux ou fournisseurs choisis, quotas de jetons, journaux, masquage des données personnelles. | graal |
| Serveur MCP | Point d’entrée des agents IA, sous compte de service, avec les mêmes droits que l’API. | graal |
| Keycloak | Identité : un realm par organisation, fédération OIDC, SAML ou LDAP. | graal |
| PostgreSQL | Métadonnées, catalogue, secrets chiffrés, planification. | graal |
| Moteur low-code | Transforme un pipeline dessiné en code Pandas ou PySpark. | graal |
| Trino | SQL fédéré sur vos tables Apache Iceberg. | graal |
| Passerelle d’applications | Accès par le SSO aux notebooks Jupyter et VS Code et aux modèles servis. | graal |
| Traitements | Jobs, workflows, Spark, notebooks et modèles servis, lancés par l’API. | graal-run |
Data Platform · Flux
Qui parle à qui
Deux voies d’entrée, vos équipes et vos agents, et un seul jeu de droits.
01
Vos équipes
Le navigateur rejoint la console et l’API derrière votre SSO (OIDC ou SAML). Chaque requête porte l’identité de la personne et ses droits sur le projet.
02
Vos agents IA
Le client MCP parle au serveur MCP, qui appelle l’API sous un compte de service limité à un projet. Les actions sensibles attendent une validation humaine.
03
Les traitements
L’API crée les pods dans graal-run. Chaque run reçoit un jeton de courte durée et une politique réseau qui limite ses sorties à votre stockage, à l’API et à Trino.
04
Les données
Lues et écrites sur votre stockage S3, en Parquet et en tables Iceberg. Elles ne sont jamais copiées hors de votre cluster.
05
Les secrets
Chiffrés en base (AES-256-GCM), livrés au traitement en mémoire au démarrage. Ils n’apparaissent ni dans la spécification des pods ni dans les journaux.
06
L’observabilité
Métriques Prometheus et traces OpenTelemetry vers vos outils. Le contexte de trace suit la requête jusqu’au run.
Data Platform · Objets Kubernetes
Ce que graal crée, et ce qu’il ne crée jamais
Tous les pods, traitements compris, tournent en PSA restricted : utilisateur non privilégié, capacités retirées (drop ALL), profil seccomp RuntimeDefault.
À l’exécution, dans graal-run
- Les pods et les Jobs des traitements, dans graal-run
- Les Services et ConfigMaps propres à un run
- Une NetworkPolicy par run, créée avant ses pods
- Les Deployments des notebooks et des modèles servis
- Un propriétaire commun par run : une seule suppression nettoie tout
Jamais
- Un namespace
- Une CRD (CustomResourceDefinition)
- Un ClusterRole ou un ClusterRoleBinding
- Un ServiceAccount, un Role ou un RoleBinding : vous les fournissez
- Un objet hors de ses deux namespaces
Data Platform · Votre équipe plateforme
Ce que vous fournissez, une fois
C’est la première question d’un responsable de plateforme ; la réponse tient en cinq lignes.
- Deux namespaces
- graal pour la plateforme, graal-run pour les traitements, avec vos quotas et votre politique réseau de base.
- Un compte de service et un rôle namespacé
- Le rôle ne donne rien hors des deux namespaces ; la liste exacte de ses verbes est dans la documentation d’installation.
- Une base PostgreSQL
- La vôtre, ou celle que fournit le chart.
- Un stockage S3 et un registre d’images
- graal n’héberge ni l’un ni l’autre : il s’y branche.
- Un nom de domaine et un certificat TLS
- Pour la console, l’API, le serveur MCP et la passerelle d’applications.
Variables, sondes et valeurs du chart : documentation d’installation.
Data Platform · Exploitation
Ce que votre équipe plateforme exploite
- Haute disponibilité
- L’API tourne en plusieurs répliques ; planification et reprise des runs sont coordonnées par un bail en base, sans doublon ni perte de run.
- Sauvegarde
- PostgreSQL archivé en continu vers un bucket dédié ; la restauration est documentée et chronométrée.
- Hors ligne
- Chart OCI, liste d’images dérivée du rendu, copie avec empreintes et signatures ; aucune installation réseau à l’exécution.
- OpenShift
- Identifiants d’utilisateur et de groupe laissés à OpenShift ; images compatibles avec un UID arbitraire.
Agentic Platform
Six composants, sur le même socle
L’Agentic Platform s’installe comme la Data Platform : par Helm, sans droit d’administration du cluster, avec des pods restreints, sur votre infrastructure.
- API
- Reçoit les demandes de vos équipes et les événements de vos outils de suivi ; applique les droits par organisation et par projet.
- Orchestrateur de workflows
- Fait avancer chaque workflow, étape par étape : une étape confiée à un agent, une attente de validation par une personne, une action de la plateforme. Il décide, il n’appelle jamais un modèle.
- Exécuteurs jetables
- Chaque étape d’agent tourne dans un bac à sable : un espace de travail neuf, un jeton de courte durée, un réseau fermé par défaut. Le bac à sable est détruit à la fin du run.
- Passerelle de modèles
- Les agents n’atteignent un modèle que par elle : une clé par run, un plafond de dépense, un registre des coûts. Le modèle est celui de votre choix.
- Catalogue d’outils
- Les outils qu’un agent peut appeler (API, serveurs MCP) sont déclarés par votre entreprise. C’est la plateforme qui les appelle, avec l’identifiant qu’elle garde : l’agent n’en reçoit aucun.
- Preuves
- Chaque run laisse ses preuves : tests réellement exécutés, différences de code vérifiées, faits mesurés, coût. Les garanties lisent ces preuves et refusent quand elles manquent.
Trois verrous encadrent chaque run
- Aucun identifiant d’un système tiers n’est remis à l’agent.
- Le réseau de l’exécuteur est fermé, sauf pour les destinations que la politique du projet autorise.
- Toute écriture vers un système tiers attend une validation humaine ré-authentifiée.
Elle partage avec la Data Platform le SSO de l’entreprise, les conventions d’audit et la façon de s’installer ; ses agents opèrent la Data Platform par son serveur MCP, sous un compte de service limité à un projet. Elle demande PostgreSQL, un fournisseur d’identité et un stockage objet S3. Pour la découvrir : la page Agentic Platform; pour l’essayer sur un poste : l’essai local sous Docker.
Faites relire l’architecture par votre équipe plateforme
Le dossier d’architecture détaillé et le rendu du chart vous sont transmis sur demande, directement.