Olivares AI v26.8.0 est la première version publique et étiquetée d’un binaire Go auto-hébergé qui apporte aux agents IA que vous utilisez déjà — Claude Code, Codex, Grok Build et les autres — un travail durable, des accès ciblés et des preuves signées, sur votre propre matériel. J’en suis l’auteur. Cet article dresse l’inventaire de ce qui existe réellement dans le tag et place les lacunes à côté des fonctionnalités, car, pour un produit de cette catégorie, les lacunes font partie de la spécification.
1. Le problème, sans adjectifs
Les agents s’exécutent sur plusieurs machines et auprès de plusieurs fournisseurs. Aucun système durable ne sait qui détient une tâche, ce que chaque agent peut atteindre, ce qu’il a réellement atteint ni qui a transmis quoi à qui. Les autorisations résident dans plusieurs systèmes IAM ; les comportements, dans des journaux d’audit que personne ne lit. Toute équipe qui exploite sérieusement des agents a reconstruit manuellement une partie de la réponse — ici une feuille de calcul, là une convention de nommage, ailleurs une personne qui s’en souvient. C’est cette partie que le produit remplace.
2. Le cœur : un plan de travail partagé par les agents
Les unités de travail durables regroupent un cahier des charges, des dépendances, des critères d’acceptation, des décisions, un responsable et un historique d’événements — un document de commande unique, partagé par REST, la CLI et les appelants au sein du processus. Les baux transforment la responsabilité en une autorité cloisonnée et temporaire : acquérir, renouveler, libérer, reprendre, révoquer. Un détenteur obsolète ne peut pas continuer à agir, et une acquisition concurrente ne produit qu’un seul gagnant. Le lancement pour une tâche réserve, prend le bail, puis seulement ensuite lance la session, ce qui permet de réessayer sans risque. Les messages entre agents comportent des accusés de réception et des transmissions, avec rejeu et rejet des époques obsolètes. La délégation via A2A atteint un pair autorisé à travers une passerelle d’application et renvoie des reçus durables.
Tout cela fonctionne. Voici maintenant la limite, énoncée aussi clairement que les fonctionnalités : la messagerie est circonscrite à un workflow d’orchestration — il n’existe délibérément aucun bus de messages généraliste pour des agents arbitraires, et un test de démarrage échoue si quelqu’un en câble un par accident. Le mode fantôme et l’autorité finale ne sont pas implémentés. Le README présente les deux versants dans le même tableau.
3. Les intégrations, avec leur niveau de profondeur
Claude Code est intégré au niveau du hook PreToolUse/PostToolUse, avec des
paramètres administrés, le lancement, la connexion et l’arrêt depuis la console,
ainsi qu’un accès aux modèles par sujet. Codex et Grok Build sont, à ses côtés,
des interfaces de commande de premier ordre. gemini-cli, Cursor, opencode,
goose, cline, OpenHands, OpenClaw et Hermes sont livrés sous forme de
connecteurs — chacun précise ce qu’il peut faire appliquer et ce qu’il peut
seulement observer, car il s’agit de promesses différentes. Ollama et les autres
endpoints auto-hébergés sont inventoriés par un connecteur local conçu pour
rester en lecture seule.
4. La gouvernance là où l’agent agit
Un moteur d’autorisation Cedar — RBAC, couche de règles de refus, autorisations
positives ciblées — et quatre points d’application deny-closed : le hook de
Claude Code, un proxy d’inférence en ligne /v1/messages, une passerelle MCP
pour tools/call et une passerelle de délégation A2A. Une action non autorisée
est bloquée, soumise à l’approbation de deux personnes ou réécrite avant son
exécution. « Deny-closed » est mesuré, pas affirmé : un point ne compte que tant
qu’un test emprunte son chemin non configuré et vérifie le refus. Lorsqu’un
point n’est pas provisionné, la capacité est présentée comme de l’observation,
pas comme de l’application — et chaque connecteur indique laquelle des deux il
offre. S’y ajoutent les approbations à deux personnes, le break-glass et un
bouton d’arrêt d’urgence de l’ensemble du parc, activable en un clic mais qui
exige deux personnes distinctes pour remettre le parc en service.
5. Des preuves que vous pouvez transmettre
Un registre d’audit en ajout seul, chaîné par hachage, avec des points de contrôle signés par Ed25519. Des exports en CEF, LEEF, syslog, OTLP et OCSF ; un envoi au moins une fois vers Splunk HEC, Microsoft Sentinel, Datadog, New Relic ou un webhook HMAC. Des preuves de conformité mises en correspondance avec 26 catalogues de référentiels — correspondances techniques des contrôles et dossiers de preuves à faire examiner par votre conseil juridique ou votre auditeur, et non des certifications. Le catalogue du produit lui-même le précise.
6. Les chiffres et le script qui les produit
30 modules. 158 intégrations. 26 catalogues de référentiels. Quatre points
d’application deny-closed. 68 commandes CLI regroupées. Aucun de ces chiffres
n’est une arithmétique marketing : scripts/check-public-counts.sh déduit les
quatre premiers de l’arborescence et fait échouer le build si le README diverge
du code ; le total de la CLI est maintenu par un test qui refuse toute commande
non regroupée. Le nombre d’intégrations est transparent sur son unité — les
répertoires de connecteurs contenant du code Go, dont douze sont des packages de
contrats partagés plutôt que des capacités — et le détail figure dans le dépôt.
Le parc de démonstration renvoie 20 nœuds, 13 arêtes, 8 accès inattendus et
2 autorisations inutilisées : des chiffres synthétiques, vérifiés par un test de
fumée exécuté sur le véritable binaire, présentés comme sortie de démonstration
et jamais comme la taille d’un déploiement client.
7. Un seul build, quelle que soit l’échelle
Le même binaire convient à un serveur domestique (SQLite, écoute sur loopback, un Compose de référence exécuté sans root et en lecture seule avec 1 CPU et 1 GiB), à un indépendant avec un tenant par client et des budgets qui refusent avant que la facture ne le fasse, à une équipe d’ingénierie avec des unités de travail partagées et le SSO, comme à une entreprise réglementée avec sécurité au niveau des lignes Postgres, installations air-gapped et archivage WORM. Plusieurs de ces capacités doivent être provisionnées ; elles ne sont pas présentes par défaut au premier démarrage — la documentation l’indique pour chacune d’elles.
8. Licence et argent, sans détour
AGPL-3.0 pour le cœur, les modules et la console web ; Apache-2.0 pour le SDK, les connecteurs et les SDK clients ; un petit ensemble d’add-ons commerciaux complémentaires, compilés uniquement avec un tag de build séparé et absents du binaire public. Le build ouvert constitue toute la plateforme — jamais limité en fonctionnalités, avec un nombre illimité de comptes utilisateurs. Une licence commerciale est une exception juridique à l’AGPL ; un abonnement est le justificatif qui permet de télécharger des artefacts signés, pas une clé qui active des octets déjà présents sur votre disque. Conditions commerciales sur demande : enterprise@olivares.ai. Hosted Cloud n’est pas commercialisé aujourd’hui ; le produit est auto-hébergé.
9. Chaîne d’approvisionnement
Les versions sont signées avec cosign et accompagnées d’une provenance SLSA,
d’une SBOM et d’OpenVEX, le tout vérifiable hors ligne avec
scripts/verify-release.sh. Artefacts : binaires linux et darwin
(amd64/arm64), packages .deb/.rpm/.apk avec une unité systemd renforcée,
une image de conteneur multiarchitecture et un bundle air-gap. Windows n’est pas
compilé — utilisez le conteneur Linux ou compilez depuis les sources.
10. Ce que nous avons refusé d’affirmer
Aucun utilisateur ni benchmark — il n’en existe aucun publiquement, et inventer
l’un ou l’autre serait la pire chose que puisse faire un produit de gouvernance.
Aucun SLA, aucun SOC 2, aucune certification. Aucune promesse selon laquelle
« rien ne quitte jamais votre réseau » : les modèles frontier fermés ne peuvent
pas être auto-hébergés, donc l’inférence qui les utilise atteint toujours l’API
du fournisseur. Le plan qui les entoure, lui, peut être auto-hébergé et isolé du
réseau, et les modèles que vous exécutez réellement vous-même (vLLM, Ollama)
gardent l’intégralité du chemin en interne. Il n’y a aucune télémétrie obligatoire
ni aucun trafic sortant du plan de contrôle par défaut ; le seul appel au
fournisseur est olivares upgrade, qui demande où se trouve la nouvelle version,
et --endpoint le redirige. Aucun kill switch distant. Aucune limite de postes
dans le moteur auto-hébergé.
Essayer
# Demo estate — synthetic data through the real engine, loopback-only:
task build && ./bin/olivares serve --seed-demo --insecure \
--listen 127.0.0.1:8901 --grpc-listen 127.0.0.1:8902 --data-dir "$(mktemp -d)"
# Real install — secure by default (TLS on, loopback, one-time setup token):
./bin/olivares quickstart
# Or the container image (registry tags carry no v prefix):
docker pull ghcr.io/olivaresai/olivares:26.8.0Lisez start/honesty-and-limits avant de déployer — c’est le contrat qui
indique ce qui fonctionne aujourd’hui, ce qui en est encore au stade de la
conception et ce que le produit choisit délibérément de ne pas faire.
Version : https://github.com/olivaresai/olivares/releases/tag/v26.8.0 · Dépôt : https://github.com/olivaresai/olivares · Documentation : https://docs.olivares.ai