graal Agentic Platform
Vos agents IA font avancer vos processus.Sous des garanties mesurées.
Livraison logicielle, exploitation IT, arrivées et départs, changement de données : des workflows que portent des agents et des personnes. Chaque garantie est un contrôle que la plateforme exécute elle-même, et toute écriture vers un système tiers attend par défaut une validation humaine. Open source, sous licence Apache 2.0, sur votre infrastructure.
Workflows d’agents
Des processus portés par des agents et par des personnes
Un workflow est une suite d’états que vous écrivez. Chaque transition dit qui agit — un agent, une personne ou la plateforme —, ce qu’elle produit et quelles garanties doivent tenir avant de passer. Le même moteur porte quatre familles de processus.
Livraison logicielle
Un ticket devient une spécification, un code testé et relu, puis une mise en production. Des agents spécifient, implémentent et relisent ; des personnes valident ; le train de livraison met en production.
Exploitation IT
Un constat d’exploitation devient un changement planifié, validé, appliqué puis vérifié. L’agent instruit et propose ; une personne décide ; la plateforme applique et mesure.
Arrivées et départs
Compte, groupes, poste de travail, badge. Un agent prépare le plan d’accès, les ressources humaines le valident, chaque écriture part à sa date — et se défait au départ.
Changement de données
Un agent propose une modification de vos données. Elle passe par des garanties et par une validation humaine avant que la Data Platform ne l’applique.
États, transitions, acteurs
Un agent (un rôle, un modèle, un budget), une personne (un groupe, un délai, un rappel, une escalade) ou la plateforme, qui exécute elle-même une action, sans agent et sans coût.
Validé dès qu’il est écrit
Un état inatteignable, une reprise sans fin, une garantie inconnue ou sans objet : le workflow est refusé à l’écriture, pas au milieu d’un ticket.
Éditeur visuel et YAML
La carte, la vue pas à pas et le YAML modifient le même brouillon. Chaque version est conservée, comparable et restaurable.
Plusieurs workflows par projet
Arrivées et départs dans un même projet : chaque ticket naît dans le workflow que le routage lui désigne et reste sur sa version.
Votre outil de suivi reste l’interface
GitHub, GitLab ou Jira — ou le suivi intégré, pour le travail qui n’existe nulle part ailleurs. La plateforme y écrit l’état, le coût et les preuves.
Des tâches pour les personnes
Une personne reçoit aussi des tâches : un formulaire à remplir et une phrase à attester, comme la remise d’un badge.
N’importe quel agent
Claude Code, Codex, Gemini CLI, Goose, OpenCode… derrière un seul protocole
La plateforme pilote chaque agent par ACP, un protocole ouvert. Le workflow nomme un rôle, pas un produit : vous changez d’agent sans réécrire le processus.
Source : Dépôt du protocole ACP, licence Apache 2.0 (consulté le 19/10/2026)
Un registre d’agents
Internes — la plateforme les lance — ou externes — ils se connectent. Chaque agent a des versions qui ne changent jamais, un propriétaire, un budget, une date d’expiration, et se révoque d’un geste.
Des agents prêts à l’emploi
Un catalogue d’agents, un par rôle : trier, spécifier, développer, tester, relire, vérifier la production. Vous les installez, puis vous les adaptez.
Des compétences
Une bibliothèque de compétences que les agents emportent. Importées d’un dépôt à un commit précis, analysées avant usage, retenues pour une seconde personne quand elles portent un risque. Une compétence ne déclare aucun droit.
Une porte MCP pour Claude et les autres
Claude, ou tout client MCP, se connecte avec un jeton à portée limitée ou par votre SSO : il ouvre des tickets, suit leur avancement et voit les décisions en attente. Il n’en prend aucune.
Des droits qui se recoupent
Un agent qui agit pour une personne ne peut faire ni plus que ce que l’agent est autorisé à faire, ni plus que ce que la personne peut faire.
Chaque agent se mesure
Exécutions, taux de réussite, coût par nature et par projet, dépense du jour : la page d’un agent dit ce qu’il fait et ce qu’il coûte.
Garanties et validations
Des garanties qui refusent, un humain qui décide
Une garantie est un contrôle que la plateforme exécute, jamais une consigne écrite dans les instructions de l’agent. Quand elle échoue, la transition ne passe pas.
Tests réellement exécutés
La plateforme lance elle-même les tests du dépôt et remplace ce que l’agent déclare.
Portée du changement respectée
Les fichiers modifiés restent dans les chemins autorisés ; ce qui en sort est annulé.
Aucun secret
Le contenu du changement est analysé : un secret trouvé bloque la transition.
Analyses de sécurité
Les contrôles de sécurité de votre intégration continue passent.
Revue approuvée
Le verdict de la revue est lu, pas déduit : une revue qui demande des changements bloque l’étape.
Provenance signée
La provenance de la construction est signée avant la mise en production.
Faits métier mesurés
Un chiffre qui compte est mesuré par la plateforme ou calculé par une étape déterministe ; toute valeur citée doit se retrouver dans les sources.
Schéma de sortie
Chaque livrable respecte le schéma que vous avez écrit dans le workflow.
Validation humaine
Toute écriture vers un système tiers attend une personne
Créer un compte, commander un poste, désactiver un badge, ouvrir une modification : une écriture est une action gouvernée. Elle attend une décision, tant que vous n’avez pas autorisé l’opération.
01
L’agent propose
La proposition porte son identité, ses paramètres et ses compensations. Rien n’est écrit.
02
Une autre personne décide
Ni celle qui propose, ni le propriétaire de l’agent. Elle s’authentifie de nouveau au moment de décider, et deux approbateurs distincts peuvent être exigés.
03
La plateforme exécute, une fois
Chaque effet est consigné avant d’être tenté : un effet fait ne se refait pas, et un échec déclenche, à rebours, les compensations de ce qui avait été fait.
Modèles, outils et budgets
Le modèle de votre choix, chaque appel compté
Les agents appellent le modèle par une passerelle que vous tenez : hébergé chez vous ou chez un fournisseur, il change sans que le workflow change.
Une clé plafonnée par exécution
Chaque exécution reçoit sa propre clé, plafonnée à ce qui reste de budget et révoquée à sa fin, quelle que soit la façon dont elle se termine.
Un registre des coûts
Chaque appel de modèle et chaque appel d’outil y figure, avec son projet, son ticket, son étape et son agent. Export CSV.
Des budgets qui s’emboîtent
Par étape, par ticket, par projet et par jour. Un budget donné au lancement ne peut que resserrer les autres, jamais les élargir.
Budget épuisé : une personne décide
L’étape s’arrête, elle n’est jamais relancée d’elle-même, et le ticket attend une décision. Ajouter du budget est une décision, inscrite au journal avec son auteur.
Un catalogue d’outils tenu comme du code
Les API tierces et les serveurs MCP que vos agents peuvent appeler sont déclarés dans un fichier relu en revue. L’agent ne détient jamais d’identifiant : il ne voit que les noms que vous avez choisis, et la plateforme appelle pour lui, avec la clé du fournisseur. Un outil découvert naît fermé.
Un bac à sable jetable
Chaque exécution a son espace, son jeton court et un réseau fermé par défaut : la sortie passe par un relais dont vous écrivez la liste. Le conteneur de l’agent ne détient aucun identifiant durable de système tiers : seulement des jetons courts, valables le temps de l’exécution.
Preuves et audit
Ce que l’agent a fait, mesuré par la plateforme
Ce que la plateforme affiche vient de ce qu’elle a constaté, pas du récit de l’agent. Chaque signal dit d’où il vient : déclaré par l’agent, observé par la plateforme, ou déduit.
Des preuves mesurées
Tests exécutés, qualité, taille du changement, faits métier : une étape que l’agent dit terminée n’est affichée comme faite qu’une fois les garanties passées.
Un journal d’audit
Qui a proposé, qui a décidé, depuis combien de temps cette personne était authentifiée, et chaque effet appliqué, clé par clé. Exportable en CSV.
Le coût par ticket
De la spécification à la mise en production, ce que chaque ticket a coûté, étape par étape.
Des indicateurs de livraison
Fréquence de mise en production, délai de livraison, taux d’échec, temps de rétablissement : les quatre mesures, par projet.
Un constat plutôt qu’une correction silencieuse
Un agent qui voit un problème hors de son champ le signale. Le constat est dédoublonné, trié, puis relié à un nouveau ticket.
Mises en production sous contrôle
Un déploiement à la fois, sous contrôle
Les changements prêts sont regroupés dans un train de livraison. La file de fusion, le train et les fenêtres de synchronisation de votre outil GitOps sont trois verrous indépendants : un changement n’atteint la production que dans les règles.
Le train de livraison
Il regroupe ce qui est prêt, ouvre sa fenêtre, exige sa validation, déploie par paliers et revient en arrière si la santé se dégrade.
La voie express
Un correctif urgent part tout de suite, avec une observation plus courte, sous sa propre validation.
Le gel motivé
Un train gelé exige un motif, et un retour arrière le gèle de lui-même : on ne relance pas par réflexe.
Avec la Data Platform
Indépendantes, et complémentaires
graal Data Platform et graal Agentic Platform s’installent, s’utilisent et s’achètent chacune seule. Ensemble, elles se complètent en trois points.
01
Les agents de l’Agentic Platform opèrent la Data Platform par son serveur MCP, sous un compte de service limité à un projet ; chaque appel est tracé des deux côtés.
02
Un changement de données proposé par un agent est gouverné de bout en bout : branche, garanties (tests exécutés, qualité des données sur échantillon, faits mesurés), validation humaine, application par l’API de la Data Platform, preuves jointes au ticket.
03
Un même socle : le SSO de l’entreprise (OIDC, SAML, LDAP), les mêmes conventions d’audit, la même installation (Helm, sans droit d’administration du cluster, pods restreints), sur votre infrastructure.
Déploiement
Chez vous, par un chart Helm
L’Agentic Platform s’installe sur votre Kubernetes par un chart Helm, sans droit d’administration du cluster. La plateforme, ses agents et ses données tournent dans votre infrastructure ; le modèle est celui que vous choisissez.
Un chart Helm
Les composants tournent sans privilèges dans votre cluster. Vous branchez votre base PostgreSQL, votre fournisseur d’identité OIDC, votre stockage objet et votre passerelle de modèles ; pour un essai, le chart sait embarquer la base et la passerelle.
Un essai sous Docker
Une commande lance la plateforme sur un poste, avec des agents simulés tant qu’aucune clé de modèle n’est posée. Vous voyez le workflow, les garanties et la validation avant d’installer quoi que ce soit.
Votre infrastructure
Sur site, en cloud privé ou chez l’hébergeur de votre choix. Vous branchez votre SSO, votre outil de suivi de tickets et votre dépôt de code.
Open source, Apache 2.0
Le code est ouvert, sous licence Apache 2.0 : vous le lisez, l’installez et l’adaptez. L’éditeur propose un abonnement — support, correctifs de sécurité, mises à jour qualifiées, images signées — et des Services graal.
Questions fréquentes
Quels agents puis-je utiliser ?
Claude Code, Codex, Gemini CLI, Goose, OpenCode, et tout agent qui parle ACP. Le workflow nomme un rôle, pas un produit : vous changez d’agent sans le réécrire, et chaque agent passe par les mêmes garanties.
Quel modèle utilise la plateforme ?
Celui que vous choisissez, hébergé chez vous ou chez un fournisseur, derrière la passerelle de la plateforme. Chaque exécution reçoit une clé plafonnée, et chaque appel entre au registre des coûts.
Un agent peut-il écrire en production ?
Pas seul. Par défaut, toute écriture vers un système tiers est une action gouvernée : l’agent la propose, une autre personne la décide après s’être authentifiée de nouveau, puis la plateforme l’exécute. Vous pouvez autoriser une opération à s’exécuter sans attendre ; un changement de code n’atteint la production que par le train de livraison.
Que se passe-t-il quand le budget est épuisé ?
L’exécution s’arrête, elle n’est pas relancée d’elle-même, et le ticket attend une personne. Donner plus de budget est une décision, inscrite au journal d’audit avec son auteur.
Faut-il la Data Platform ?
Non. Les deux plateformes sont indépendantes : l’Agentic Platform porte aussi des processus sans donnée, comme les arrivées et départs, l’exploitation ou la livraison logicielle. Avec la Data Platform, vos agents opèrent aussi la donnée, sous les mêmes garanties.
Quelle licence ?
Open source, sous licence Apache 2.0. L’abonnement de l’éditeur apporte le support, les correctifs de sécurité, les mises à jour qualifiées et les images signées, avec des utilisateurs et des agents illimités, sans facturation à l’usage.
Voir vos agents faire avancer un processus
Une démonstration sur votre cas : le workflow, les garanties qui refusent, la validation humaine et le coût de chaque ticket.