Les news du mois

Coûts et gouvernance de l’IA

En août, deux changements qui ne préviennent pas

Deux notes de version modifient un comportement par défaut, sans rien casser bruyamment : ce sont les plus dangereuses.

Et trois statuts à corriger dans vos supports, tous passés en GA en août :

• RBAC « assume a role »
• Secrets Unity Catalog
• Contrôle d’accès au compute serverless

Les droits deviennent plus fins, et plus contextuels

Deux chantiers de préversion documentés fin août touchent au même endroit, la façon d’écrire un droit, et ils vont dans deux directions opposées : l’un découpe, l’autre contextualise.

Les échéances qui tombent

Deux échéances à mettre dans un calendrier, et la première est déjà derrière nous.

Ingénierie et accès aux données

Harness, meta-harness, et pourquoi le mot compte

Dans une même réunion, le mot « agent » peut désigner un modèle, un outil de code, un serveur MCP, un endpoint de LLM et un workflow d’orchestration. Personne n’a tort au sens strict, chacun nomme un étage différent d’une même pile. Mais tant que la pile n’est pas explicite, les décisions se prennent sur le mauvais étage : on choisit un modèle quand le problème est l’outillage, on interdit un usage quand il suffirait de le contraindre.

Ce que fait un harness, et pourquoi deux harnesses ne se valent pas

Un harness est l’échafaudage logiciel qui transforme un modèle en agent capable d’agir. Cinq briques :

• la boucle d’exécution : raisonner, appeler un outil, observer le résultat, recommencer jusqu’au bout de la tâche ;
• les outils exposés : ce que l’agent peut réellement faire, lire un fichier, lancer un test, ouvrir une pull request ;
• la gestion du contexte : ce qu’il garde, ce qu’il résume, ce qu’il oublie, et c’est là que se joue une bonne moitié de la qualité ;
• les permissions : ce qu’il fait sans demander, et ce qui exige une validation humaine ;
• l’interface : terminal, éditeur, revue de code, ce qui détermine qui l’utilise vraiment.

Claude Code, Codex, Cursor sont des harnesses.

La démonstration la plus nette du mois vient d’ailleurs, du côté des documents. Le mode précision d’ai_extract, passé GA à la mi-août, atteint 94,7 % de justesse sur l’extraction structurée de documents complexes, sept points au-dessus d’un modèle frontière en découpage-fusion, sur des documents allant jusqu’à 2 000 pages et des schémas de plus de 300 champs imbriqués.

Or ce n’est pas un modèle plus gros : ce sont des modèles d’extraction entraînés sur mesure, et surtout un harness qui découpe la tâche sémantiquement, lance des sous-agents en parallèle, conserve les résultats intermédiaires et les réconcilie. La thèse est transposable bien au-delà de l’extraction documentaire : le contexte long ne se règle pas par un modèle plus gros, mais par le dispositif autour du modèle.

Deux réserves d’usage, parce que le chiffre circulera : c’est un banc d’essai d’éditeur sur son propre produit, dont dix jeux de données sur quinze ne sont pas reproductibles, et le billet promet un avantage de coût qu’il ne chiffre nulle part. Les modes d’échec relevés sur les modèles frontière sont d’ailleurs plus instructifs que le score, en particulier des fusions finales qui ne respectent pas le schéma demandé. Autrement dit, tout pipeline d’extraction doit valider sa sortie contre son schéma, avant comme après cette annonce.

Trois raisons d’ajouter un étage au-dessus

Un meta-harness pilote les harnesses eux-mêmes, derrière une API commune. L’idée paraît abstraite mais elle répond à trois problèmes très concrets :

Financier

Les modèles propriétaires sont co-conçus avec un harness particulier, si bien que ce dernier devient un verrouillage de fait sur une famille de modèles. Or le premier levier de coût à l’échelle n’est pas la négociation tarifaire, c’est la capacité à migrer vite vers les modèles plus efficients, sur une frontière d’efficience qui avance plus vite que celle de l’intelligence. Et on ne migre pas si chaque développeur doit changer de harness : le coût de changement individuel est trop élevé. Le verrouillage coûte donc de l’argent, directement.

Gouvernance, et pas par des prompts

Les contrôles habituels sont binaires, alors que la dangerosité d’une action dépend de l’histoire de la session : un git push peut être sain dans la plupart des cas mais risqué après que l’agent a lu du contenu non fiable, puisque lire du contenu non fiable, accéder à du contenu sensible et communiquer vers l’extérieur est le scénario d’exfiltration classique. Une policy qui maintient un état de session voit cette différence.

• session : la règle vit le temps d’une conversation et voit l’histoire de ce qui précède ;
• agent : la règle suit un agent donné, quel que soit celui qui le lance ;
• serveur : la règle est posée par l’exploitant, et l’utilisateur ne peut ni la lire ni la lever.

C’est le niveau serveur, celui des garde-fous non contournables, qui se cadre avec un RSSI.

Composition

Les meilleurs résultats viennent de combinaisons, un agent économique qui exécute et un modèle frontière qui arbitre, ce qu’aucun harness ne sait faire depuis l’intérieur.

Omnigent en pratique : ce qu’il apporte, et ses deux versions

Omnigent, le projet open source signé Matei Zaharia, est l’implémentation de référence du meta-harness. Concrètement, il apporte quatre choses :

• une API commune devant les principaux agents de code, si bien que changer de harness tient en une ligne de configuration ;
• des agents décrits en YAML, donc versionnables et portables d’une équipe à l’autre ;
• des policies qui s’appliquent à tous les harnesses, avec l’état de session décrit plus haut ;
• une exécution en sandbox avec interception réseau : un token d’accès n’est jamais visible de l’agent, il est injecté dans le proxy de sortie sur les seules requêtes approuvées.

Il existe en deux versions, dont les périmètres diffèrent :

• l’open source, auto-hébergé : toutes les fonctionnalités, y compris les policies que vous écrivez vous-même, mais l’infrastructure est à votre charge ;
• le managé sur Databricks, en Beta : rien à héberger, intégration à Unity AI Gateway, sessions partageables et traces dans MLflow, mais seules les policies fournies en standard sont supportées, la sandbox Databricks n’existe que sur AWS, il n’y a pas de support Windows natif, donc il faut passer par WSL2, et la préversion doit être activée sur un workspace situé dans une région qui supporte la gateway.

À noter : l’apport le plus original d’Omnigent, des policies contextuelles écrites sur mesure, n’existe que dans la version open source à la date de rédaction de ce numéro. C’est une limite de jeunesse plus qu’un choix d’architecture, on peut donc s’attendre à ce qu’elle tombe, mais aucune échéance n’est annoncée. À cadrer avant un pilote, en gardant en tête la grille de positionnement : la gateway gouverne au niveau de la plateforme, le meta-harness au niveau du poste de travail.

Smart Routing : le même nom pour deux étages différents

Unity AI Gateway et Omnigent proposent depuis août une fonctionnalité appelée Smart Routing mais ce n’est pas la même chose : illustration parfaite du problème de vocabulaire.

Celui de la gateway choisit le modèle derrière l’appel : un petit modèle classe la tâche, puis le routeur escalade ou rétrograde selon la complexité. Les chiffres publiés à la mi-août sont bons, plus de 30 % de coût en moins par tâche, mais ils sont conditionnés :

• c’est un routeur pour agents de code, avec deux portes d’entrée seulement, Omnigent ou le lanceur ucode ; Claude Code et Codex lancés directement n’y ont pas droit ;
• seuls les modèles préfixés system.ai sont candidats, donc un modèle interne ou apporté par vos soins n’entre pas dans le routage ;
• l’utilisateur doit avoir accès à tous les modèles candidats, sinon le routage échoue.

Restriction de modèle et routage sont donc deux réglages couplés, ce qui n’est écrit nulle part ailleurs.

Celui d’Omnigent choisit le modèle et le harness, par session, au premier message, parmi des paires candidates déclarées en configuration.

Les skills : ce que l’agent lit, et qui en décide

Un harness se nourrit de fichiers de contexte, ces instructions qu’on écrit pour cadrer un agent. Jusqu’ici ils vivaient dans un dépôt Git, recopiés d’une équipe à l’autre, sans propriétaire ni audit. Fin août, Databricks en a fait un objet Unity Catalog : un skill est désormais un securable nommé catalogue.schéma.skill, en Beta. Rien n’est utilisable avant qu’un administrateur de compte n’ait activé la préversion « Unity AI ».

Le point important n’est pas le stockage, c’est le partage. Il se fait par un octroi et non par une copie : l’agent du consommateur lit le skill vivant, sous vos droits et votre audit, et rien n’est dupliqué. Les privilèges sont littéralement ceux des volumes, READ VOLUME étant celui qu’on accorde pour partager.

Trois limites à connaître avant d’industrialiser :

• Il n’existe pas de CREATE SKILL. Aucun DDL, aucune API REST, ni Terraform ni bundle. Tout passe par un serveur MCP ou par ucode, et le seul chemin automatisable documenté est un notebook qui ne supprime jamais rien et publie sous votre identité.
• La gateway ne gouverne pas les skills. Un skill n’est pas un service : ni limite de débit, ni service policy, ni fractionnement de trafic. Il est gouverné par Unity Catalog, et seulement découvert via MCP.
• Les consommateurs documentés sont les agents de code externes, Claude Code, Codex, Gemini CLI et quelques autres. Ni Genie Code, ni Genie One, ni Agent Bricks : aucun pont n’est documenté entre les deux mondes.

Deux conseils. La documentation insiste sur un point, « the description matters most », puisque c’est sur la description que les agents font leur choix. Et rien n’est documenté pour renommer un skill : fixez le nommage avant le premier, préfixé par division si votre métastore est partagé.

Un mot, enfin, que ce numéro se doit de signaler puisqu’il parle de vocabulaire : « skill » désigne aujourd’hui trois objets différents, ceux d’Unity Catalog, ceux de Genie Code, et les user skills de Genie One. Ne l’employez jamais sans préciser lequel.

La mémoire : ce que l’agent retient, et ce que ça change dans votre analyse de risques

Un étage absent du schéma parce qu’il n’est pas de même nature : la mémoire. La recherche de Databricks en fait le troisième axe de mise à l’échelle, après les paramètres et l’inférence, et c’est le seul qui vous soit propre. Avec un avertissement posé d’emblée par les auteurs : plus de mémoire ne rend pas automatiquement un agent meilleur.

Deux distinctions posées par le billet, donc quatre types : épisodique ou sémantique, personnelle ou organisationnelle. Ce qu’un agent a vécu dans une session n’a ni la même durée de vie, ni le même régime d’accès, que ce qu’une organisation sait de son propre vocabulaire.

Résultat contre-intuitif : sur un espace Genie en production, des journaux de conversation non curés, filtrés par un simple juge automatique, ont fait passer la justesse de 2,5 % à plus de 50 %, dépassant après 62 enregistrements une référence construite à la main par des experts. L’ordre des travaux s’en trouve inversé : plutôt que documenter puis ouvrir, on ouvre, on récolte, on filtre. À deux conditions tout de même, le juge et la trace.

Gouvernance, pas barrière

Trois dispositifs portent, dans les notes de version du mois, la même clause : les budgets de la gateway sont « enforced approximately », le contrôle d’accès au compute serverless « might fail open » en cas d’incident de service, et l’auto-approbation de Genie Code, pourtant recommandée, est décrite comme « a productivity feature, not a security boundary ».

Et un quatrième cas, celui des politiques de masque ABAC, va plus loin : elles n’acceptent que trois expressions de colonne au maximum, et toutes doivent correspondre, sinon la politique ne s’applique pas et la donnée sort en clair. Un dispositif qui échoue en s’ouvrant ne se vérifie pas en relisant sa configuration, il se vérifie par l’absence : que voit un utilisateur sans attribut, que sort une table mal étiquetée.

Pour conclure

Un mot, une décision. La façon la plus simple de le vérifier chez vous tient en trois questions : combien d’outils d’agents tournent réellement dans vos équipes, sous quelles règles, et qui saurait le dire aujourd’hui ? Si les trois réponses ne viennent pas en une réunion, votre sujet n’est pas le modèle que vous avez choisi.

La valeur se déplace vers l’explicitation. Écrire ce que tout le monde savait sans le dire, poser une règle qui s’applique partout plutôt qu’un contrôle posé à la main. Des chantiers sans démo spectaculaire, ce sont eux qui décideront quels projets agentiques tiendront en production l’année prochaine.

Vous vous demandez ce qu’un meta-harness changerait dans votre contexte ? Échangeons pour l’évaluer sur vos usages réels.

À bientôt.

Donatien Tessier — Head of Data, I-Shane | Databricks Champion