Databricks open-source « Omnigent », une « meta-harness » qui gouverne Claude Code, Codex et Cursor au niveau plateforme — le même pari qu'AppManager fait depuis le début, mais sur des actions métier, pas du code
Le 13 juin, Databricks/Mosaic a publié Omnigent en open source (licence Apache 2.0) : une couche de contrôle unique posée au-dessus des agents de coding qu'on utilise déjà — Claude Code, Codex, Cursor, Pi, agents maison. Sandbox OS qui verrouille l'accès système, secrets injectés uniquement via un proxy de sortie sur requêtes approuvées, budgets de coût et permissions conditionnelles : pas de réglage dans le prompt, du contrôle au niveau de la plateforme elle-même.
Omnigent n'est pas un agent de plus, c'est une couche qui s'assoit au-dessus de ceux qui existent déjà, avec deux promesses concrètes documentées dans le repo GitHub et le billet de Matei Zaharia (cofondateur de Databricks), Kasey Uhlenhuth et Corey Zumar : d'abord, ne jamais donner un secret directement à l'agent — les identifiants ne transitent que par un proxy de sortie, sur des requêtes déjà approuvées ; ensuite, des politiques contextuelles capables de suivre un état dynamique, par exemple « après qu'un agent a téléchargé un nouveau paquet npm, exiger une approbation humaine avant tout git push ». À ça s'ajoutent des budgets de coût explicites — mettre l'agent en pause et demander confirmation tous les 100 dollars dépensés — et un sandbox OS qui verrouille l'accès système et intercepte le trafic réseau.
Ce qui frappe, ce n'est pas la liste de fonctionnalités — c'est qui la publie. Databricks/Mosaic n'est pas un vendeur de compliance à la recherche d'un marché : c'est un des acteurs d'infrastructure IA les plus sérieux du secteur, et sa conclusion est que gouverner des agents de coding en production exige du contrôle au niveau de la plateforme, pas la confiance dans le prompt ou dans le modèle pour bien se comporter tout seul. Chez AppH, on applique exactement le même principe depuis le premier jour, mais sur un terrain différent : ce n'est jamais un agent qui décide qu'une action métier — envoyer un devis, répondre un e-mail client, déclencher une automatisation — est assez anodine pour se passer d'une approbation. C'est la structure du produit qui l'impose, pas un réglage qu'on pourrait un jour desserrer.
Pour AppH
- Un acteur d'infra IA de premier plan — pas un petit vendeur de niche — arrive à la même conclusion que nous : gouverner des agents en production exige du contrôle au niveau plateforme, pas seulement un bon prompt. Ça confirme le pari qu'on a fait depuis le début, pas qu'on rattrape une tendance après un incident.
- Le principe qu'Omnigent applique au code (npm, git push) est structurellement le même qu'AppManager applique aux actions métier (devis, e-mail, automatisation) : jamais d'exécution directe par l'agent, toujours un point d'approbation humaine avant qu'une action réelle ne parte.
Contre / la limite honnête
- Ce n'est pas une comparaison produit à produit : Omnigent gouverne des agents de développement (Claude Code, Codex, Cursor) sur de l'infrastructure technique — paquets npm, commits, accès OS. AppH gouverne des agents qui agissent sur les opérations d'une PME — CRM, facturation, stock. Deux domaines différents, les mettre en concurrence directe serait malhonnête.
- On n'a pas testé Omnigent nous-mêmes — tout ce qu'on sait vient du billet de blog officiel et du README GitHub, pas d'un audit de sécurité indépendant. Impossible de vérifier depuis l'extérieur si le sandbox tient réellement ses promesses en conditions réelles.
Le titre facile serait « même Databricks nous donne raison » — mais la vraie leçon n'est pas qu'un acteur d'infra IA valide notre approche, c'est que la question du contrôle d'agent ne se pose plus au niveau du prompt nulle part dans le secteur, du code à la gestion d'entreprise. Omnigent le fait pour du code parce que c'est là que Databricks opère ; AppH le fait pour des opérations métier de PME parce que c'est là qu'on opère. Le point commun n'est pas le produit, c'est le principe : un agent ne devrait jamais être seul juge de ce qui est « assez anodin » pour agir sans qu'un humain regarde d'abord. C'est vrai pour un git push comme pour un devis envoyé à un client.
Vérifié par un humain d'AppH