Le provider Terraform est-il open source, et sous quelle licence ?

Oui. Le provider, terraform-provider-olivares, est publié sous AGPL-3.0-only — et non Apache-2.0. Il gère votre propre control plane auto-hébergé (agents, politiques, déploiements, liaisons d'identité, budgets) de façon déclarative via l'API stable du produit. Planifiez en conséquence si votre modèle de distribution est sensible au copyleft.

Olivares AI remplace-t-il notre fournisseur d'identité ?

Non. Ce n'est pas un IdP. Il fédère l'identité des agents en lecture seule — il lit les registres depuis Entra Agent ID, AWS AgentCore Identity et Google Agent Identity et les réconcilie avec un registre SPIFFE/WIF, de sorte que le graphe d'accès porte une attribution ferme ou approximative pour chaque arête. Il n'émet aucune information d'identification et n'écrit rien en retour dans ces registres.

L'intégration Backstage est-elle un vrai plugin ou une iframe ?

La cible de conception est un plugin natif, en lecture d'abord, qui expose l'inventaire des agents, les sessions en direct et la carte d'accès R/RW à l'intérieur de votre portail, authentifié auprès du control plane. C'est une intégration au portail, pas un second tableau de bord. Considérez la profondeur du plugin comme pré-1.0 — consultez la référence des modules pour l'état d'avancement.

Intégrez vos agents IA dans la plateforme que vous exploitez déjà

Le problème : les agents arrivent plus vite que votre plateforme ne peut les modéliser

Vous exploitez une plateforme de développement interne. Vous disposez d’un catalogue de services, d’un IdP, d’une infrastructure as code, d’une réconciliation GitOps et d’un portail que les ingénieurs ouvrent réellement. Cette mécanique existe précisément pour que rien d’important ne tourne sans être modélisé — aucun service sans propriétaire, aucun accès sans politique, aucun changement sans diff.

Les agents IA rompent ce contrat. Une session Claude Code, un serveur MCP, un agent autonome planifié — chacun peut lire et écrire à travers les mêmes bases de données, magasins d’objets et API que vos services manipulent, mais ils apparaissent en dehors du catalogue. Ce sont les développeurs qui les déploient, ce n’est pas vous qui les provisionnez. Ils s’authentifient le plus souvent au moyen de comptes de service partagés. Et les hyperscalers ont aggravé la situation en faisant de l’identité des agents une primitive en disponibilité générale dans trois registres mutuellement incompatibles.

Le signal du marché est sans détour. Gartner s’attend à ce que plus de 40 % des projets d’IA agentique soient annulés d’ici fin 2027 (Gartner, presse), et l’étude IBM Cost of a Data Breach 2025 (Ponemon) a constaté que, parmi les organisations ayant subi une violation liée à l’IA, environ 97 % ne disposaient pas de contrôles d’accès à l’IA adéquats. Une conclusion préliminaire du MIT issue du projet NANDA — the GenAI Divide, via Fortune, août 2025, pas encore évaluée par les pairs — rapporte qu’environ 95 % des projets pilotes de GenAI n’ont montré aucun impact mesurable sur le compte de résultat, et que les outils achetés à l’extérieur ont réussi environ deux fois plus souvent que les développements internes. Rapporté au métier d’une équipe plateforme, tout cela pointe dans la même direction : c’est dans la prolifération d’agents non gouvernés et non modélisés que la valeur s’échappe et que le risque s’infiltre.

Comment Olivares AI s’intègre à la plateforme que vous exploitez déjà

Olivares AI est une plateforme ouverte et auto-hébergeable qui découvre les agents IA présents sur votre infrastructure, cartographie ce que chacun peut lire et écrire, puis gouverne et audite cet accès. L’objectif de conception pour les équipes plateforme n’est pas une console de plus — c’est de faire des agents des citoyens de premier rang de la plateforme que vous exploitez déjà.

Les agents comme entités de catalogue à part entière

La plateforme découvre les agents, les serveurs MCP, les sessions et les identités non humaines, et construit une carte d’accès : un graphe de chaque arête agent → base de données / magasin / API, chacune marquée en lecture (R) ou en lecture-écriture (RW). Ce graphe est l’entrée de catalogue que l’agent aurait dû avoir depuis le début — ce qu’il est, ce qu’il touche, et si ce qu’il touche correspond à ce qu’il est autorisé à toucher.

Cette dernière distinction est le cœur du produit. Les arêtes sont classées autorisé vs observé, de sorte que la dérive par rapport au moindre privilège est visible plutôt que supposée. Voir la carte d’accès et la page de concept sur autorisé vs observé.

La nuance d’honnêteté compte ici et nous la gardons à découvert : la fidélité R/RW est à plusieurs niveaux. La couverture est clean sur les sources dotées d’un audit natif, lossy là où les arêtes sont grossières, et opaque là où il n’existe aucun signal passif de lecture/écriture ; l’attribution est firm quand une source porte une identité par agent et approximate quand un compte partagé la masque. La carte affiche le niveau plutôt que de feindre la certitude — voir fidélité.

Gestion comme code : un provider Terraform/OpenTofu

Pour une équipe plateforme, le config-as-code est un prérequis incontournable. Olivares AI fournit terraform-provider-olivares, qui gère votre propre control plane auto-hébergé de façon déclarative via son API stable. Le provider expose des ressources et des sources de données pour les agents, les politiques, les déploiements, les liaisons d’identité d’agents, les budgets, la configuration des capacités et les routes de notification, avec import, plan/apply et gestion de la dérive — de sorte que les agents que vous gouvernez sont réconciliés de la même manière qu’ArgoCD ou Flux réconcilie déjà le reste de votre parc.

Un détail de licence à préciser, car il diffère du SDK de connecteurs : le provider est sous AGPL-3.0-only, et non Apache-2.0.

resource "olivares_agent" "billing_assistant" {
  name = "billing-assistant"
  # ...géré aux côtés du reste de votre plateforme, comme du code
}

resource "olivares_policy" "billing_least_privilege" {
  # intention de moindre privilège, versionnée dans Git, réconciliée comme tout le reste
}

Le HCL ci-dessus illustre la forme, ce n’est pas un contrat à copier-coller — générez-le à partir du schéma publié par le provider lui-même. Le produit est pré-1.0 : considérez la couverture des ressources comme suivant la surface de l’API, et vérifiez la référence des modules pour savoir ce qui est câblé aujourd’hui.

Compatibilité avec votre IdP — fédération, pas remplacement

Olivares AI n’est pas un fournisseur d’identité et ne cherche pas à en être un. Il fédère l’identité des agents en lecture seule : il lit les registres depuis Microsoft Entra Agent ID, AWS AgentCore Identity et Google Agent Identity, et les réconcilie avec un registre SPIFFE/WIF, de sorte que chaque arête de la carte d’accès porte une attribution ferme ou approximative. Les identités dédiées d’agents et de charges de travail se résolvent en attribution ferme ; les principaux de blueprint, les fournisseurs d’informations d’identification et les agents à compte de service restent approximatifs plutôt que d’être promus à une identité fabriquée. Il n’émet aucune information d’identification et n’écrit rien en retour dans ces registres — la fédération est strictement en lecture seule.

Il met aussi en évidence une classe de dérive utile pour la sécurité de plateforme : les informations d’identification statiques à longue durée de vie détectées sur des identités d’agents, conformément aux recommandations des Five Eyes 2026 en faveur d’informations d’identification à courte durée de vie. L’authentification client OAuth basée sur SVID (les travaux draft-ietf-oauth-spiffe-client-auth) est implémentée comme design-toward — il n’y a aucune revendication de conformité tant qu’un serveur d’autorisation n’a pas publié le flux correspondant. Voir identité et fédération.

Une intégration au portail : Backstage, en lecture d’abord

Si vos développeurs vivent dans Backstage, l’inventaire des agents devrait y vivre aussi. La cible de conception est un plugin natif, en lecture d’abord — inventaire, sessions en direct et carte d’accès R/RW rendus à l’intérieur du portail et authentifiés auprès du control plane — et non une iframe ni un second tableau de bord. La lecture d’abord est délibérée : elle correspond à la posture du produit (ci-dessous) et maintient l’intégration au portail à faible risque.

CLI d’abord, avec une API stable en dessous

Toute la plateforme tient dans un seul binaire Go, controlplane, qui démarre sur un graphe d’accès déjà peuplé ; la console web est embarquée dans la même origine que l’API. Tout ce que vous pouvez faire dans l’UI, vous pouvez le piloter depuis la CLI ou la surface OpenAPI 3.1, sur laquelle s’appuient le provider Terraform, un plugin Backstage et votre propre automatisation. Commencez par la référence de configuration, le workflow CLI et la surface de gouvernance MCP.

Ce que c’est — et ce que ce n’est pas

C’est un produit à vocation de sécurité, nous tenons donc une ligne ferme sur ce qu’il revendique.

Lecture d’abord et deny-closed. Il observe et gouverne largement ; il n’actionne pas largement. La plupart des actions sont à la demande en direct ou constituent une jointure déclarée et deny-closed — un apply de déploiement renvoie 503 jusqu’à ce que vous provisionniez un exécuteur, et non un no-op silencieux. Voir autorisé vs observé et la page honnêteté et limites.
Pré-1.0, open-core. Le catalogue compte 23 modules ; environ 20 sont câblés dans une installation standard. Rien ici n’implique que les 23 soient pleinement opérationnels — la référence des modules indique l’état d’avancement par module.
L’air-gap concerne le control plane, pas Claude. Le plan de gouvernance et d’observation s’exécute entièrement auto-hébergé et peut être isolé du réseau (air-gap). L’inférence Claude n’est jamais auto-hébergée — Anthropic ne publie aucun poids, donc tout appel à Claude atteint une API. Seuls les modèles que vous auto-hébergez réellement (vLLM, Ollama) tournent hors ligne. Voir sécurité.
Non certifié. Il est conçu en vue de l’EU AI Act, du NIST AI RMF, de l’ISO/IEC 42001, de SOC 2 et d’autres, avec des preuves d’audit issues d’un registre append-only chaîné par hachage. Il n’est pas certifié SOC 2 / ISO / EU AI Act. Voir conformité.
Il complète vos tours de contrôle ; il ne prétend pas les remplacer. La fédération d’identité et l’export de posture sont en lecture seule par conception.

Si vous voulez d’abord la vue architecturale, lisez l’architecture ; si vous voulez savoir où nous nous situons par rapport aux passerelles, à l’observabilité et aux tours de contrôle d’agents, voir la comparaison. Et si vous pesez la licence et la frontière de l’open-core, open source en est la version honnête.

Personas associés : responsables de la sécurité, SRE et sysadmin, et enseignement supérieur.