produits · foundation
La couche sur laquelle tout repose.
La Foundation n'est pas une option : identity, secrets, access, metering et quotas arrivent avec chaque déploiement — et chaque produit s'appuie dessus dès le premier appel.
identity
Orgs, projets et clés qui bornent tout.
Le modèle de tenancy est assez simple pour s'expliquer d'un souffle et assez strict pour bâtir une activité dessus.
Chaque projet en relève — la frontière de propriété et d'appartenance.
Clés API, visibilité des modèles et chaque ressource créée vivent dans un projet. Les équipes ont leurs couloirs ; personne n'emprunte les credentials d'un autre.
À la création, et jamais ensuite — la console ne garde qu'un préfixe d'affichage qui ne peut jamais authentifier. La révocation est un clic, immédiate.
Les runs et automatisations ont leur propre identité, pour que « qui a fait ça » ait toujours une réponse.
secrets
Écrit une fois, jamais montré.
Les credentials qui font tourner les workloads IA — clés API de modèles, chaînes de connexion, tokens — sont exactement les valeurs qui finissent collées dans les tickets et les chats. Les secrets sont faits pour rendre ça impossible.
À la création, avec une confirmation délibérée — puis elle est scellée. Même la console ne peut plus l'afficher.
Chaque secret est borné aux workloads qui peuvent le recevoir. Un run obtient un secret parce que celui-ci lui a été accordé, par son nom.
On fait tourner en ajoutant une nouvelle version ; les consommateurs suivent le secret, pas une copie.
Chaque création, version, grant, révocation et livraison — pour tout le projet, dans l'ordre.
pour votre relecteur sécurité
Les credentials d'upstream n'existent jamais en clair dans une config, un fichier d'environnement ou une variable CI — seulement comme valeurs scellées avec des grants nommés et un historique d'audit complet.
access
Le moindre privilège, avec un veto.
L'autorisation dans Quark est assez simple pour être relue en réunion.
Accordées aux personnes et aux comptes de service — le côté allow de l'histoire.
Un deny correspondant annule tout le reste, quels que soient les rôles accordés. Quand vous devez dire « jamais », la plateforme le tient.
Une base raisonnable laisse le projet respirer ; tout ce qui est sensible est à un grant explicite du verrouillage.
Les workloads reçoivent les secrets et permissions qui leur ont été accordés — et rien d'autre, nulle part sur la plateforme.
en dessous
Un substrat construit pour inspirer confiance.
La couche de gouvernance repose sur un substrat conçu pour être digne de confiance.
Les services de la plateforme s'authentifient mutuellement sur un transport chiffré, les workloads portent leurs propres identités, et votre console comme vos clients API parlent clés et tokens.
Les services de la plateforme vérifient qui demande, pas seulement quelle clé a été présentée.
L'isolation est appliquée à chaque appel, pas déduite de la position réseau.
Pour les workloads aux exigences plus strictes, les runs peuvent être durcis ou confidentiels — l'isolation est un curseur, pas un fork.
metering
Le metering par défaut.
L'usage n'est ni échantillonné ni estimé ; il est émis par les produits au fil du service.
Chaque completion via le gateway est attribuée à la clé API qui l'a faite. Équipes, produits et clients ont leurs propres clés — et leur propre colonne qui répond dans le ledger.
Appels au gateway, temps de sandbox, constructions d'index, et le reste remontent séparément. Quand la dépense bouge, vous savez quel produit l'a bougée.
Requêtes, tokens et les unités de travail propres à la plateforme, chacune suivie pour soi — pas de « unités » mélangées qui n'expliquent rien.
Les synthèses de dépense et d'usage vivent sur la page d'accueil de la plateforme, pas enterrées dans un export.
quotas
Des quotas qui s'appliquent vraiment.
Un budget qui se contente de rapporter est une newsletter. Les quotas s'appliquent là où l'usage arrive.
Pour une clé, un produit ou tout le projet.
Chaque quota montre son état — sain, proche du plafond ou dépassé — avec la marge rendue en barre lisible d'un coup d'œil.
Quand un quota est épuisé, tout usage supplémentaire est refusé jusqu'au renouvellement de la fenêtre. Les dépenses folles sont stoppées par la plateforme, pas par qui se trouve être réveillé.
Les plafonds par clé sur requêtes et tokens vous donnent un second point d'application exactement là où se fait la dépense modèle.
pour qui approuve la facture
Chaque équipe peut avoir sa clé et ses quotas — et l'expérience d'une équipe ne peut jamais devenir discrètement la facture de l'entreprise.
les questions
Construit pour les questions que vous poserez vraiment.
L'usage par clé, sur une page.
L'usage par produit, sur la même page.
États des quotas avec marge, sans export.
Oui — un quota est à quelques champs.
contact
Parlez-nous de faire tourner Quark.
Parlez-nous de vos charges — nous vous montrerons ce que votre propre cloud peut faire.