Du chatbot au travail delegue : pourquoi l'IA agentique a besoin d'un control plane runtime

L'unité de travail de l'IA a changé

La meilleure façon de comprendre le moment actuel de l'IA est de constater que son unité de travail a changé. À l'époque des chatbots, l'unité était l'interaction : un utilisateur posait une question, un modèle répondait, puis le résultat était généralement recopié ailleurs par un humain.

Dans la phase agentique, l'unité devient le travail délégué. OpenAI a décrit ce basculement très clairement en juin 2026 : les agents peuvent fonctionner de manière autonome pendant des minutes ou des heures, orchestrer des appels à des outils, interagir avec des environnements et itérer vers un objectif. Ses recherches sur Codex ont aussi montré un déplacement net vers des tâches à horizon plus long, avec de nombreux utilisateurs confiant des travaux estimés à plus de 30 minutes ou une heure de travail humain.

C'est important parce que le travail délégué n'a pas le même profil de risque que le chat. Une réponse de chat peut être fausse. Un agent délégué peut être faux, coûteux, sur-privilégié, difficile à attribuer, et déjà engagé au milieu d'un workflow avant que quelqu'un ne s'en aperçoive.

Pourquoi le sujet brûlant, ce sont les agents, pas seulement les modèles

La course aux modèles continue, mais le sujet côté entreprise a changé. Des modèles plus rapides et moins chers aident, bien sûr. Mais la question opérationnelle est désormais : quel travail l'organisation peut-elle déléguer en sécurité ?

C'est ce qui explique pourquoi les équipes IA parlent de :

• agents de codage, d'analyse, de finance, de support et d'opérations qui tournent longtemps
• workflows multi-agents qui se transmettent des tâches entre systèmes
• connecteurs, plugins et serveurs MCP qui permettent aux agents d'agir sur les données métier
• croissance des coûts liée aux retries, aux boucles d'outils, au gonflement du contexte et aux agents parallèles
• auditabilité des actions déléguées

Les recommandations publiées par OpenAI en juillet 2026 sur la gestion des investissements IA font le même constat côté finance. Le prix du token ne suffit pas. Les dirigeants doivent comprendre le travail utile par dollar dépensé, voir qui utilise quels produits et modèles, gouverner les workflows avancés avant leur passage à l'échelle, et aligner la capacité sur la demande.

C'est précisément là que l'infrastructure devient stratégique. Si les agents effectuent du travail, l'entreprise doit savoir quel agent, sous quelle identité, avec quels outils, dans quel budget, et avec quel résultat final.

La couche manquante est la gouvernance runtime

Beaucoup d'organisations traitent encore la gouvernance IA comme une checklist de pré-production : choisir un provider, approuver un modèle, publier des règles d'usage acceptable et organiser des revues périodiques.

C'est trop lent pour l'IA agentique. Les agents prennent des décisions dans le chemin d'exécution. Ils décident quand appeler un outil, combien de contexte utiliser, s'il faut réessayer, s'il faut demander plus de capacité et s'il faut continuer une chaîne. Une politique statique ne voit pas assez.

Le point de contrôle doit être au runtime. Pour les systèmes agentiques en production, le gateway doit pouvoir répondre à cinq questions pendant que la requête est en cours :

• Ce workload est-il autorisé à utiliser ce modèle ?
• Cet agent est-il autorisé à appeler ce serveur MCP et cet outil précis ?
• Le prompt ou le payload d'outil est-il risqué ?
• Le budget et le quota sont-ils réservés avant l'appel upstream ?
• L'enregistrement final montrera-t-il l'identité, le résultat de politique, le coût, la latence et le statut ?

Sans ces réponses, l'IA agentique devient un ensemble de processus autonomes invisibles, reliés par des clés provider partagées et des logs dispersés.

Comment Odock s'aligne sur le travail délégué

Odock a été conçu comme un AI governance gateway, pas seulement comme un proxy LLM. Cette distinction compte pour l'IA agentique, parce que le gateway se trouve sur le chemin entre applications, agents, providers de modèles et serveurs MCP.

L'architecture Odock sépare le management plane du runtime gateway. Les opérateurs configurent dans l'UI les organisations, équipes, providers, modèles, serveurs MCP, virtual API keys, budgets, quotas, règles de routage et politiques. Le gateway Go applique ensuite ces décisions sur le trafic LLM et MCP en direct, avec Postgres comme source of truth et Redis pour l'état du hot path.

Pour le travail délégué, les contrôles importants sont concrets :

Les virtual API keys donnent une identité à chaque workload. Chaque application, équipe, tenant, utilisateur ou agent peut disposer d'une clé scoped. Cette clé détermine l'accès aux modèles, l'accès MCP, l'héritage des politiques, les budgets, les quotas et l'état du cycle de vie.

La gouvernance MCP traite les outils comme des capacités. Odock ne considère pas un serveur MCP comme une simple connexion générique. Il peut autoriser ou bloquer des outils précis, appliquer des filtres sémantiques sur les payloads, injecter des credentials upstream sans exposer de secrets à l'agent, et enregistrer l'usage des outils.

Les budgets et quotas arrêtent le travail incontrôlé avant la dépense. Odock réserve le budget avant l'exécution upstream. Si le budget ou la fenêtre de quota est épuisé, la requête est bloquée avant que le coût provider ne soit engagé.

Le routage rend les workloads agents plus résilients. Les politiques de routage par clé peuvent utiliser des stratégies de failover, de priorité ou de round-robin afin que les workloads de production ne dépendent pas d'un seul chemin vers un modèle upstream.

Les usage records transforment le travail en preuve. Chaque requête est enregistrée avec son attribution, le modèle ou l'outil, le statut, le coût, l'usage de tokens, la latence et le résultat de politique. C'est la couche de preuve dont les équipes finance, sécurité et conformité ont besoin lorsque l'usage des agents commence à se multiplier.

Ce que les équipes plateforme devraient construire maintenant

L'IA agentique n'a pas vocation à devenir chaotique. Le modèle est maîtrisable si les équipes font de la gouvernance runtime un élément par défaut du déploiement.

Commencez par l'attribution. Les clés provider partagées ne sont pas compatibles avec le travail délégué. Chaque workload significatif a besoin d'un propriétaire, d'un périmètre et d'un chemin de révocation.

Puis contraignez les capacités. Ne donnez pas à un agent tous les outils exposés par un serveur. Publiez l'allowlist utile la plus étroite possible, bloquez explicitement les outils destructifs et inspectez les payloads avant exécution.

Ensuite, contrôlez la dépense avant l'exécution. Les tableaux de bord de coûts sont utiles, mais insuffisants. Les workloads agentiques peuvent boucler, réessayer et se paralléliser. Les réservations pré-exécution et les fenêtres de quota font la différence entre observer un pic et l'empêcher.

Enfin, rendez la preuve durable. La valeur du control plane n'est pas seulement de bloquer les requêtes risquées. C'est aussi de permettre à l'organisation de prouver plus tard ce qui s'est passé : qui a délégué le travail, ce que l'agent était autorisé à faire, quels contrôles se sont déclenchés, ce qui a été dépensé et quel a été le résultat.

C'est le niveau d'exigence pour l'IA agentique en production en 2026. Les organisations qui l'atteignent délégueront davantage de travail avec moins de friction opérationnelle. Celles qui ne le font pas continueront à découvrir leurs agents à travers les factures, les incidents et les demandes d'audit.

Sources

• OpenAI, How agents are transforming work, June 25, 2026
• OpenAI, How to manage AI investments in the agentic era, July 14, 2026
• Odock Architecture
• Odock Virtual API Keys
• Odock Budgets
• Odock MCP Governance