Souveraineté et architecture

« Souverain » est un mot très utilisé. Chez graal il a une seule définition, reprise à l’identique partout :

1. la plateforme et les données tournent dans l’infrastructure choisie par le client ;
2. aucun service tiers n’est nécessaire au fonctionnement : ni SaaS, ni télémétrie, ni polices ou captcha externes ;
3. l’éditeur, qui intègre et supporte aussi la plateforme, est de droit français (GRAAL.SYSTEMS SAS) ;
4. le code des pipelines est exportable et les formats sont ouverts (Parquet, S3, SQL, API MLflow).

Le reste de cette page dit comment chacun de ces points se vérifie dans l’architecture, plutôt que de le répéter autrement.

Deux namespaces, et rien au-dessus

L’installation occupe deux namespaces d’un cluster que vous administrez :

Namespace	Ce qui y vit
namespace applicatif	console, API, moteur low-code, services de plateforme
namespace d’exécution	les jobs et les espaces de travail des utilisateurs

La séparation n’est pas cosmétique : un espace de travail exécute du code d’utilisateur. Aucun secret de la plateforme n’est matérialisé dans ce namespace-là, et les images de runtime y sont tirées anonymement, sans secret de tirage. Un utilisateur qui lance un notebook ne peut pas lire les identifiants de la plateforme, parce qu’ils ne sont pas dans son namespace.

Au-dessus de ces deux namespaces, l’installation ne demande rien :

• aucune CRD — graal n’ajoute aucun type d’objet à votre cluster ;
• aucun objet cluster-scoped : ni ClusterRole, ni ClusterRoleBinding, ni StorageClass, ni ClusterIssuer ;
• aucun Secret, Role, RoleBinding, NetworkPolicy, ResourceQuota ni LimitRange : vos garde-fous restent écrits par vous, et une politique que le locataire s’accorde lui-même n’est pas une politique ;
• aucun namespace : c’est votre équipe plateforme qui les crée, avec leur quota et leur politique réseau.

Autrement dit, graal n’a pas besoin d’un compte d’administration du cluster — ni pour s’installer, ni pour fonctionner. Et cette affirmation ne demande pas de nous croire : le rendu du chart se relit avant d’être appliqué, et il ne contient aucun des objets ci-dessus.

Tous les pods, y compris ceux des utilisateurs, respectent le profil PSA restricted : runAsNonRoot, toutes les capacités Linux retirées, profil seccomp RuntimeDefault.

Aucune ressource distante

Ni pendant l’installation, ni à l’exécution, ni dans l’interface :

• aucune police depuis un CDN : les polices sont auto-hébergées dans les paquets de la console et du site — c’est vérifié automatiquement sur le résultat du build, pas seulement écrit dans une règle ;
• aucun script tiers : pas d’analytics, pas de pixel, pas de captcha externe ;
• aucune télémétrie : la plateforme n’appelle pas son éditeur. Il n’y a pas de « désactiver la télémétrie » à cocher, parce qu’il n’y a rien à désactiver ;
• aucune image tirée d’un registre public à notre nom : les images viennent du registre que vous contrôlez.

Conséquence : une instance coupée d’Internet continue de fonctionner. Pour un environnement isolé dès l’installation, voir la page Déploiement.

Vos données restent chez vous

Ce qui est produit	Où ça vit
Données, fichiers, buckets	Votre stockage objet S3
Tables	Apache Iceberg, sur votre stockage objet
Catalogue des tables	Votre base PostgreSQL, un schéma par locataire
Métadonnées, projets, droits	Votre base PostgreSQL
Identités, sessions	Votre Keycloak (un realm par tenant, annuaire fédérable)
Journaux d’exécution	Votre cluster
Secrets de projet	Chiffrés au repos dans votre base

Il n’y a pas de plan de contrôle chez l’éditeur, donc pas de copie de vos métadonnées ailleurs.

Les secrets d’un projet (vos identifiants vers vos propres systèmes) sont chiffrés au repos (AES-256-GCM), avec une clé dérivée par HKDF-SHA256 d’un sel que vous générez et que vous seul détenez — une clé distincte par locataire. Ce sel se génère une fois et se sauvegarde comme une clé de chiffrement de base de données : la procédure est sur la page Installation.

Les agents IA et le modèle de langage que vous choisissez

La plateforme et les données restent chez vous. Dès que vous branchez un agent sur un modèle de langage hébergé par un tiers, ce que les outils MCP renvoient à cet agent passe par le modèle que vous avez choisi. La frontière est donc « rien ne sort sans que vous ayez choisi où ça va ».

Ce que graal vous donne pour tenir cette frontière : un agent n’a que les droits de son compte, aucun outil de suppression n’est activé par défaut, et les outils de lecture sont bornés par le RBAC par projet. Si votre politique interdit toute sortie, adossez l’agent à un modèle que vous hébergez — et la plateforme fonctionne aussi sans aucun agent.

Réversibilité

La question utile n’est pas « pouvez-vous exporter ? » mais « que reste-t-il si vous partez ? ».

• Le code des pipelines est du code : un pipeline dessiné dans l’éditeur low-code s’exporte en Pandas ou PySpark et tourne ailleurs, sans graal.
• Les formats sont ouverts : Parquet, Iceberg et S3 pour les données, SQL pour l’interrogation.
• Le suivi d’expériences est compatible avec le client MLflow : les expériences se relisent avec un outillage standard.
• Les identités sont dans votre Keycloak, pas dans un annuaire propriétaire.

Ce qui ne se transporte pas : les écrans, l’ordonnancement et la gouvernance par projet — c’est le produit.

Hébergeurs qualifiés

SecNumCloud et HDS qualifient des offres d’hébergement et des hébergeurs, pas un logiciel installé chez vous. graal est déployable chez un hébergeur qualifié SecNumCloud ou certifié HDS, ou dans votre propre datacenter : c’est l’offre d’hébergement retenue qui porte la qualification.

Le contexte réglementaire — SREN, Data Act, DORA, NIS2 — est traité sur la page publique Souveraineté, avec ses sources et leurs dates de consultation.

Pour aller plus loin

• Installation — prérequis et variables qui comptent
• Architecture — composants, images, réseau
• Sécurité et gouvernance
• Agents IA (MCP) — ce qu’un agent peut faire, et sous quels droits