OpenAI vend l'usine à agents

Mise à jour : l'usine contrôle maintenant l'horloge

OpenAI vient d'ajouter une horloge à son usine à agents.

L'Agents API peut désormais lancer des automatisations planifiées selon une expression cron ou à une date précise. Une planification peut ouvrir une nouvelle session pour un travail indépendant ou revenir dans une session existante pour reprendre le fil du contexte. OpenAI propose aussi un outil facultatif qui permet à l'agent de créer et gérer les planifications de sa session en langage naturel.

Cela ressemble à une petite commodité.

Ce n'en est pas une.

Dès qu'un agent peut décider qu'un travail doit avoir lieu plus tard, l'application ne sert plus seulement à lancer des tâches. Elle devient le système d'exploitation des promesses.

« Vérifie ce prix chaque matin. »

« Reviens sur ces incidents dans une heure. »

« Poursuis l'enquête après la prochaine mise à jour des données. »

Ces promesses survivent maintenant au tour de conversation qui les a créées. Elles ont besoin d'un propriétaire, d'un budget, d'un mécanisme d'annulation, d'une piste d'audit et d'un compte rendu honnête de ce qui s'est réellement passé.

Cron est la partie facile.

Le produit, c'est tout ce qui se trouve entre « lance-toi à 9 h » et « le travail est terminé ».

Une invocation terminée n'est pas un travail terminé

La documentation d'OpenAI énonce la distinction la plus importante avec une franchise bienvenue.

Chaque exécution planifiée crée une invocation. Si cette invocation est marquée comme terminée, cela signifie que le message a bien été livré à la session cible.

Cela ne signifie pas que l'agent a terminé sa tâche.

Cette seule phrase devrait dicter toute l'interface.

Un agent planifié traverse au moins quatre états différents :

• la planification existe et peut se déclencher
• une invocation a tenté de livrer la tâche
• la session a accepté puis exécuté le travail
• le travail a produit le résultat attendu

Il existe un cinquième état si l'utilisateur doit être prévenu : l'application a bien affiché ou envoyé le résultat.

Réunir ces états sous une seule coche verte, c'est condamner le système à mentir.

Un rapport matinal peut être livré à une session occupée, accepté plus tard, échouer pendant un appel d'outil et ne jamais atteindre l'utilisateur. Le planificateur peut malgré tout avoir parfaitement rempli sa mission.

C'est la même erreur qu'avec les files de messages : accuser réception de l'enveloppe ne veut pas dire que le processus métier qu'elle contient est terminé.

OpenAI fournit les invocations et les événements de session. L'application doit encore les relier pour construire un statut honnête.

Mettre en pause ne veut pas dire arrêter

Le deuxième avertissement utile concerne l'annulation.

Mettre une planification en pause ou la supprimer empêche les prochaines livraisons. Cela n'arrête pas le travail déjà accepté par une session. Il faut annuler séparément le tour actif.

Là encore, le détail d'implémentation devient une exigence produit.

Lorsqu'un utilisateur appuie sur « pause », il veut généralement dire l'une de ces deux choses :

• ne lance pas une nouvelle exécution
• arrête ce que cette automatisation est en train de faire

Ce sont deux commandes différentes. Une interface sérieuse doit proposer les deux.

La même séparation vaut pour les modifications. Mettre à jour une planification ne réécrit pas une invocation déjà placée dans la file. Un nouveau prompt, un nouveau budget ou une nouvelle destination peuvent ne s'appliquer qu'à la prochaine exécution, tandis que l'ancienne instruction attend toujours son tour.

Si cette différence reste invisible, le système finira parfois par suivre exactement l'ordre reçu tout en donnant l'impression de désobéir.

Les planifications créées par l'agent ont besoin d'un propriétaire humain

Le nouvel outil d'automatisation permet à un agent de créer, consulter, modifier, mettre en pause, reprendre et supprimer les planifications de sa session.

C'est puissant, car l'agent peut transformer un engagement pris dans la conversation en comportement persistant.

C'est aussi le moment où une phrase anodine devient une infrastructure.

« Continue de vérifier » peut vouloir dire trois exécutions, trois mois ou jusqu'à ce qu'une clé API oubliée épuise son budget. Retirer ensuite l'outil d'automatisation ne supprime pas les planifications déjà enregistrées. Elles continuent d'exister tant que l'application ne les suspend pas ou ne les efface pas.

Chaque planification créée par un agent a donc besoin d'un propriétaire et de limites :

• qui l'a autorisée
• à quelle session et à quel objectif elle appartient
• quand elle expire
• combien elle peut dépenser par exécution et au total
• quels outils et quelles données elle peut utiliser
• si plusieurs exécutions peuvent se chevaucher
• quels résultats exigent une approbation
• où les résultats et les échecs sont signalés
• comment un humain peut la retrouver et l'arrêter

La planification en langage naturel est une bonne interface de saisie.

Ce n'est pas un modèle de gouvernance.

Nouvelle session ou ancien contexte : un choix d'architecture

OpenAI permet de cibler une nouvelle session ou une session existante.

Ce choix paraît minuscule dans une requête API. Il change pourtant le modèle d'échec.

Une nouvelle session est plus facile à isoler et à reproduire. Elle démarre sans le poids des conversations accumulées, mais l'application doit lui fournir les faits, les identifiants et les artefacts nécessaires à l'exécution.

Une session existante préserve la continuité. Elle peut se souvenir de la raison de l'automatisation et de ce qui s'est passé auparavant. Elle peut aussi hériter d'hypothèses périmées, d'un contexte gonflé, d'un outil resté dans un état ambigu ou d'une instruction raisonnable la semaine dernière et dangereuse aujourd'hui.

OpenAI recommande de réserver l'agent principal à l'objectif durable, à la planification et aux résumés concis, puis de déléguer le détail des exécutions à des sous-agents. C'est une approche saine : sans cela, les résultats récurrents peuvent remplir le contexte censé préserver la continuité.

La leçon plus profonde est simple : la mémoire n'est pas gratuite sous prétexte que le fournisseur la stocke.

Il faut toujours décider ce qui mérite de survivre.

Le nouveau lock-in inclut le temps

L'Agents API avait déjà déplacé le lock-in au-dessus du modèle.

Sessions, compaction, sandboxes, sous-agents, état du navigateur, événements d'approbation et connexions aux outils privés vivent tous dans le runtime autour du modèle.

Les automatisations planifiées ajoutent une nouvelle couche : l'état temporel.

Le fournisseur peut désormais conserver non seulement ce que l'agent sait et l'endroit où il s'exécute, mais aussi ce qu'il a promis de faire plus tard. Migrer signifie alors reconstruire les planifications, les fuseaux horaires, les invocations en attente, la logique de retry, les pauses, les liens vers les sessions et les preuves qu'une exécution a eu lieu ou non.

OpenAI précise aussi que les exécutions récurrentes reçoivent un léger délai aléatoire et qu'une session occupée peut les retarder davantage. C'est un comportement d'infrastructure raisonnable. Cela veut aussi dire qu'une planification n'est pas un minuteur de précision.

Avant de lui confier un travail sérieux, il faut décider :

• Le workflow est-il idempotent en cas de retry ?
• Que se passe-t-il lorsqu'une exécution est en retard, manquée ou chevauche la suivante ?
• Quel fuseau horaire gouverne la planification, y compris lors des changements d'heure ?
• L'utilisateur peut-il distinguer la prochaine exécution, la dernière livraison, le tour actif et le dernier résultat réussi ?
• Les exigences d'approbation expirent-elles entre la planification et l'exécution ?
• Le budget ou les permissions d'outils peuvent-ils changer avant le lancement ?
• Comment réconcilier les exécutions après une panne du fournisseur ?
• Peut-on exporter les planifications et leur historique vers un autre runtime ?

Le planificateur est un ajout utile.

Il montre aussi très clairement ce qu'OpenAI vend vraiment.

Pas seulement de l'intelligence.

Pas seulement de l'exécution.

De la continuité, de l'infrastructure et maintenant du temps.

L'usine à agents peut continuer de tourner après le départ de tout le monde.

Cela rend le control plane plus précieux.

Cela fait aussi des contrôles honnêtes une partie du produit, pas une couche que les développeurs pourront ajouter plus tard.

Mise à jour : l'usine est devenue une API

L'usine n'est plus seulement un service enterprise.

OpenAI en fait une infrastructure que les développeurs peuvent louer.

À DevDay, l'annonce la plus bruyante était GPT-6.1 Sol, un modèle moins cher pour le code et le travail professionnel.

L'annonce la plus importante était tout ce qu'OpenAI a placé autour.

L'Agents API est entrée en bêta publique le 10 septembre. OpenAI dit proposer le harness de Codex comme service managé, avec orchestration des sessions, compaction du contexte, récupération, sessions durables, sandboxes hébergées, outils et sous-agents. Le 29 septembre, OpenAI a ajouté computer use, afin qu'un agent puisse piloter un navigateur hébergé par OpenAI pendant que l'application du développeur gère les approbations de sites et la connexion aux comptes.

Le même cycle de lancement a ajouté Secure MCP Tunnel, une connexion sortante entre le réseau d'un client et OpenAI. ChatGPT, Codex, la Responses API et d'autres produits OpenAI compatibles peuvent ainsi appeler un serveur MCP privé sans que celui-ci accepte du trafic entrant depuis internet.

Assemblons les pièces.

OpenAI peut maintenant héberger l'agent, conserver sa session, compacter son contexte, coordonner ses sous-agents, lui donner un navigateur, le connecter à des outils privés et retransmettre son travail vers l'application.

Ce n'est pas une API de modèle accompagnée de quelques utilitaires.

C'est un control plane pour agents.

L'abstraction remonte encore d'un étage

Les premières API de modèles utiles vendaient des tokens.

La couche suivante a vendu des appels d'outils, des sorties structurées, des fichiers, de la recherche et du travail en arrière-plan.

L'Agents API vend la boucle.

Les développeurs peuvent toujours fournir leur propre environnement ou passer par un fournisseur compatible. OpenAI dit aussi que le harness repose sur des composants open source. Ce sont de vraies portes de sortie.

Mais le produit par défaut est clair : envoyez la tâche dans un runtime managé par OpenAI et laissez OpenAI opérer la machine complexe qui l'entoure.

C'est séduisant parce que cette machine est complexe.

Un agent long-running a besoin de plus qu'un prompt et une boucle while. Il lui faut un état qui survive à une connexion coupée. Il lui faut une compaction du contexte qui ne supprime pas silencieusement la contrainte importante. Il lui faut des permissions d'outils, de l'isolation, des événements de progression, des retries, une annulation, de la récupération et une trace de ce que chaque sous-agent a fait.

La plupart des équipes ne veulent pas construire tout cela avant même de savoir si le workflow est utile.

OpenAI propose donc un très bon échange :

Confiez-nous la complexité opérationnelle.

Confiez-nous aussi le centre de l'architecture.

Computer use rend la frontière visible

Le navigateur montre comment ce produit veut répartir les responsabilités.

OpenAI héberge le navigateur et exécute la boucle de l'agent. L'application du développeur reçoit une demande lorsque l'agent veut visiter un site ou se connecter. L'application doit montrer la demande à l'utilisateur, collecter son approbation ou ses identifiants, puis renvoyer la décision.

C'est la bonne forme.

L'agent ne devrait pas approuver son propre accès.

Mais un événement d'approbation n'est pas encore un produit d'approbation.

Les développeurs doivent toujours décider :

• ce que l'utilisateur accepte réellement
• si l'approbation couvre une page, une origine, une action ou le reste de la session
• comment garder les identifiants hors du contexte du modèle et des logs
• ce qui se passe si la demande expire pendant la connexion
• comment montrer à l'utilisateur ce que le navigateur a fait après son accord
• quelles actions exigent une seconde confirmation avant de modifier des données

OpenAI fournit le mécanisme.

L'application possède encore le sens.

Cette distinction sera facile à ignorer dans les démos et impossible à ignorer après le premier incident.

Un accès privé n'est pas une exécution privée

Secure MCP Tunnel résout un vrai problème enterprise.

Une entreprise peut garder un serveur MCP derrière son firewall, exécuter le client de tunnel d'OpenAI dans son réseau et n'ouvrir qu'une connexion HTTPS sortante. OpenAI met les requêtes MCP en attente, le client les transmet localement, puis la réponse revient par le même tunnel.

C'est bien mieux que de demander à chaque entreprise d'exposer un nouvel endpoint public parce que l'agent a besoin d'un outil.

Mais cela change aussi le diagramme de confiance.

Le serveur privé reste privé.

La requête passe tout de même par un endpoint de tunnel hébergé par OpenAI.

La documentation d'OpenAI apporte une autre distinction utile : les changements de métadonnées du tunnel apparaissent dans les audit logs de la plateforme, et les logs de conformité normaux continuent de s'appliquer au niveau de l'app. En revanche, le trafic du control plane du tunnel et les requêtes de transport individuelles ne sont pas émis comme événements d'app dans la ChatGPT Compliance Platform par le chemin du tunnel.

Cela ne rend pas le tunnel dangereux.

Cela veut dire que les équipes de sécurité doivent cartographier quel système conserve quelle preuve avant de qualifier le workflow d'auditable.

"Le serveur n'est pas public" répond à une question réseau.

Cela ne répond pas à toutes les questions sur les données, l'autorisation, la rétention, l'observabilité ou la réponse aux incidents.

Le nouveau lock-in se trouve dans la mémoire opérationnelle

Le lock-in modèle est facile à décrire.

Vos prompts fonctionnent mieux avec un modèle. Vos évaluations visent son comportement. Votre budget suppose ses prix.

Le lock-in du runtime est plus profond.

Il vit dans l'historique des sessions, le comportement de la compaction, les définitions d'outils, les événements d'approbation, les hypothèses de sandbox, les traces des sous-agents, la sémantique des retries et le chemin de récupération après un échec partiel.

On peut remplacer le nom d'un modèle dans un appel API.

Remplacer le système qui se souvient du travail, décide quel contexte survit, planifie les outils et reconstruit une session cassée ressemble davantage au remplacement d'un environnement d'exécution.

Cela ne veut pas dire que les développeurs devraient refuser l'Agents API.

Une infrastructure managée est souvent exactement le bon choix.

Cela veut dire que la revue d'architecture doit cesser de faire comme si le modèle était la seule dépendance importante.

Avant de placer un travail sérieux sur un runtime agentique hébergé, il faut demander :

• Pouvons-nous exporter toute la session, les événements d'outils, les approbations et les traces des sous-agents ?
• Pouvons-nous reproduire le workflow avec un autre runtime ?
• Quel état nous appartient, et quel état n'existe que chez le fournisseur ?
• Pouvons-nous fixer la version du modèle, du harness et des contrats d'outils ?
• Que devient une session en cours pendant une panne du fournisseur ou un changement d'API ?
• Pouvons-nous arrêter tous les agents enfants depuis une seule surface de contrôle ?
• Quelles actions sont réellement imposées par nos systèmes plutôt que seulement demandées dans le prompt ?
• Où enquêtons-nous lorsque le log de l'application, celui du tunnel et la trace du fournisseur se contredisent ?

L'usine est devenue plus facile à louer.

L'acheteur doit encore savoir où se trouvent les sorties de secours.

Le vrai produit de DevDay

GPT-6.1 Sol sera peut-être plus rapide, moins cher ou meilleur sur un benchmark particulier.

Ces avantages bougeront encore.

Le signal durable de DevDay est qu'OpenAI veut posséder une plus grande partie du chemin entre une demande et un travail terminé.

Le modèle raisonne.

Le harness se souvient.

Le runtime exécute.

Le navigateur agit.

Le tunnel atteint les systèmes privés.

L'application approuve.

Cette dernière ligne compte. OpenAI fournit davantage de la machine, mais la responsabilité n'a pas disparu. Elle a été répartie entre davantage de frontières.

La plateforme agentique gagnante ne rendra pas seulement ces frontières puissantes.

Elle les rendra lisibles.

L'usine à agents est là.

Les développeurs doivent maintenant décider s'ils achètent des machines ou s'ils louent le sol sur lequel elles reposent.

La version courte

OpenAI ne vend plus seulement l'agent.

OpenAI vend l'usine autour de l'agent.

Le 22 juillet, OpenAI a présenté OpenAI Presence, un produit enterprise pour déployer des agents vocaux et chat dans les workflows clients et internes. La page officielle explique que Presence connecte les agents aux systèmes de l'entreprise, aux politiques, aux permissions, aux simulations, aux évaluations, aux garde-fous, aux chemins d'escalade et aux approbations humaines.

Beaucoup de noms.

C'est justement le point.

Presence ne dit pas : "voici un modèle plus intelligent, bonne chance."

OpenAI dit plutôt :

Nous allons vous aider à choisir le workflow, connecter les systèmes, définir les politiques, tester l'agent, surveiller les sessions en production, proposer des améliorations et déployer les changements sous approbation.

Très tranquille. Le chatbot est devenu un système opérationnel managé.

L'histoire utile n'est pas qu'OpenAI veut du revenu enterprise.

Évidemment qu'OpenAI veut du revenu enterprise.

L'histoire utile, c'est que les labs de modèles montent dans la stack : déploiement, contrôle qualité, intégration système et logiciel métier. OpenAI avait déjà lancé en mai l'OpenAI Deployment Company pour intégrer des Forward Deployed Engineers dans les organisations. Presence est la version produit de la même thèse.

Le modèle n'est plus toute la vente.

La vente, c'est :

Pouvons-nous rendre cet agent assez fiable pour toucher vos clients, vos dossiers d'assurance, vos tickets IT, vos achats et vos systèmes internes sans transformer chaque incident en réunion avec le juridique ?

C'est un business beaucoup plus difficile.

C'est peut-être aussi le vrai business de l'IA enterprise.

Presence n'est pas une surcouche

La version paresseuse de l'histoire ressemble à ceci :

OpenAI a lancé un agent de support client.

Très bien.

Encore un support bot.

Merci de patienter pendant que le futur redirige votre problème vers une base de connaissance.

Ce n'est pas assez.

OpenAI dit que Presence commence avec une tâche précise : questions de facturation, dossiers d'assurance, demandes IT des employés, support client, prospection commerciale, achats, RH. L'agent ne reçoit que les connaissances et accès système nécessaires à cette tâche. Le client définit les politiques : ce que l'agent peut faire, quand il doit demander une approbation et quand un humain doit reprendre.

Ce n'est pas une surcouche.

C'est de l'architecture de workflow.

Cela veut dire que le produit est moins la bulle de chat que la machine autour :

• procédures opérationnelles
• permissions
• accès aux outils
• simulations
• évaluations
• évaluateurs automatiques
• garde-fous
• règles d'escalade
• monitoring production
• gestion du changement
• approbation humaine

Magnifique. Nous avons rendu les agents prêts pour l'entreprise en les entourant d'exactement assez de processus pour que l'entreprise se reconnaisse.

Mais ce process n'est pas décoratif.

C'est le produit.

La veille de la première version de cet article, j'écrivais que les agents qui durent ont besoin de freins. Presence est la version commerciale de la même idée, côté entreprise : pas seulement "est-ce que l'agent peut agir ?", mais "est-ce que l'entreprise peut gouverner la façon dont il agit ?"

L'agent doit continuer à changer

Un détail du post d'OpenAI compte plus qu'il n'en a l'air.

Presence est conçu pour s'améliorer après le lancement.

OpenAI dit que les sessions de production et les escalades révèlent des gaps. Codex peut enquêter sur ces signaux et proposer des mises à jour. Les équipes peuvent tester les changements proposés contre la version en production, puis approuver un rollout contrôlé.

C'est ce qui rend le sujet différent d'une vieille automatisation.

Le logiciel enterprise traditionnel échoue souvent parce qu'il fige un processus qui change déjà. La politique change. Le produit change. Le client change. L'équipe support invente une exception. Le workflow diverge lentement de l'implémentation jusqu'au moment où tout le monde recopie des notes dans un spreadsheet nommé "temporaire."

Les agents IA accélèrent cette dérive.

Un agent qui parle à des clients va rencontrer de nouveaux edge cases tous les jours. Il va apprendre où la politique est ambiguë, où la base de connaissance est obsolète, où les utilisateurs posent des questions que personne n'avait prévues, et où le passage à l'humain arrive trop tard ou trop tôt.

Le vrai système n'est donc pas :

L'agent lance.

L'agent marche.

Terminé.

Le vrai système est :

L'agent lance.

L'agent échoue de manières intéressantes.

L'entreprise apprend.

Le workflow change.

Les évaluations changent.

L'agent change.

Le processus d'approbation décide si le changement est autorisé.

Cette boucle est le produit.

OpenAI ne vend pas seulement un agent qui répond au téléphone.

OpenAI vend une manière de continuer à changer l'agent après qu'il a répondu au téléphone.

C'est là que le SaaS devient nerveux

Presence met OpenAI dans une position étrange.

OpenAI reste une entreprise de modèles.

Elle devient aussi un intégrateur système.

Elle devient aussi un vendeur de logiciel enterprise.

Elle peut aussi devenir concurrente de certaines entreprises qui construisaient au-dessus de ses modèles.

Si Presence gère le support client, la prospection commerciale, les dossiers d'assurance, le help desk IT, les RH et les achats, OpenAI n'est plus seulement un fournisseur pour les logiciels de ces catégories. Elle entre sur leur territoire.

Pas forcément en les remplaçant.

Pas tout de suite.

Presence a encore besoin des systèmes de l'entreprise. Il doit se connecter aux CRM, outils de tickets, systèmes d'identité, bases de politiques, call centers, bases de connaissance, systèmes de facturation, outils RH et à cette application interne terrifiante construite en 2014 qui, pour une raison obscure, fait encore tourner la paie.

La forme probable à court terme est donc l'intégration, pas le remplacement total.

Mais la pression stratégique est évidente.

Si la couche agentique devient l'endroit où les conversations clients se passent, alors la couche agentique commence à posséder le workflow. Le SaaS sous-jacent devient l'un des systèmes que l'agent utilise.

Cela change le pouvoir.

La question pour les entreprises SaaS n'est plus seulement :

Pouvons-nous ajouter des fonctions IA ?

C'est :

Restons-nous le système de travail, ou devenons-nous un outil dans l'agent de quelqu'un d'autre ?

Très bonne question pour le prochain board meeting.

OpenAI veut aussi les leçons du déploiement

Il y a un autre élément discret ici.

OpenAI dit que Presence a été développé en collaboration avec son équipe Research, et que les enseignements généralisés des déploiements nourrissent la recherche et le développement produit.

C'est logique.

C'est aussi stratégiquement important.

Les entreprises qui voient les vrais déploiements d'agents vont apprendre où les agents échouent réellement.

Pas les échecs de benchmark.

Les vrais échecs :

• des clients qui formulent le même problème de cinq manières différentes
• des politiques qui se contredisent
• des outils qui retournent des états étranges
• des règles d'approbation trop strictes
• des chemins d'escalade trop lents
• des agents qui sonnent confiants mais ratent le vrai sujet
• des humains qui contredisent l'agent pour des raisons que l'évaluation n'avait pas captées

C'est un feedback extrêmement précieux.

Le lab qui opère la couche de déploiement obtient une meilleure carte de ce que les agents doivent améliorer. Il voit les cas d'usage, les modes d'échec, les workflows, les intégrations et les endroits où les entreprises acceptent de payer.

C'est un avantage de données.

Pas forcément au sens étroit des données d'entraînement.

Un avantage d'apprentissage produit.

Presence transforme le déploiement enterprise en boucle de feedback pour le lab.

La disponibilité limitée est un signal

Presence n'est pas en libre-service.

OpenAI dit que le produit est disponible pour des clients enterprise éligibles dans un programme de disponibilité générale limitée, avec des déploiements menés par des Forward Deployed Engineers d'OpenAI et certains intégrateurs globaux.

Cela compte.

Si c'était une fonction SaaS normale, le bouton dirait "Essai gratuit."

Ici, il dit : parlez à votre équipe de compte.

Ce n'est pas seulement du théâtre commercial enterprise. Cela dit ce que le produit demande encore.

Il demande du travail d'intégration.

Il demande de cartographier les politiques.

Il demande des revues d'accès.

Il demande de concevoir les évaluations.

Il demande de la gestion du changement.

Il demande des humains responsables.

L'absence de libre-service est un marqueur d'honnêteté utile. Les agents de production ne sont pas encore prêts à brancher pour les workflows sérieux. Le marché répète "agents." Le travail répond "implémentation."

C'est pour cela que l'OpenAI Deployment Company compte. Le lab construit un bras services parce que le modèle seul ne produit pas le résultat.

La capacité frontier est nécessaire.

Le muscle de déploiement est ce qui la rend facturable.

Ce que les acheteurs devraient demander

Presence peut être réellement utile.

Il pose aussi les bonnes questions côté acheteur.

Si une entreprise fait entrer un lab IA dans le support client, les dossiers d'assurance, les RH, l'IT, les ventes ou les achats, elle devrait savoir :

• Qui possède les procédures opérationnelles et définitions de politiques ?
• Quels systèmes l'agent peut-il lire ou modifier ?
• Quelles actions exigent une approbation ?
• Qu'est-ce qui compte comme résolution réussie ?
• Qui conçoit les évaluations ?
• Le client peut-il exporter les logs, évaluations, prompts et règles de politique ?
• Comment les changements proposés à l'agent sont-ils revus ?
• Un autre fournisseur peut-il faire tourner le même workflow plus tard ?
• Que se passe-t-il si OpenAI change le modèle sous-jacent ?
• Que se passe-t-il si le client veut utiliser un modèle non-OpenAI pour une partie du workflow ?
• Qui est responsable quand l'agent suit la politique mais que la politique est mauvaise ?

Ce dernier point va compter.

L'IA enterprise va échouer de manières ennuyeuses.

Pas toujours parce que le modèle hallucine.

Parfois parce que la politique était floue, l'intégration fragile, le chemin d'approbation mauvais, ou le processus métier déjà en désordre avant l'arrivée de l'agent.

L'agent ne va pas magiquement régler cela.

Il va le révéler à grande échelle.

Le fond du sujet

OpenAI Presence n'est pas la plus grosse histoire modèle de la semaine.

C'est peut-être l'histoire enterprise la plus importante.

Elle montre que les labs frontier ne veulent plus se contenter de fournir de l'intelligence. Ils veulent posséder la couche de déploiement : les politiques, évaluations, garde-fous, chemins d'escalade, workflows et boucles d'amélioration qui transforment un modèle en quelque chose qu'une entreprise peut mettre devant des clients.

C'est là que se trouve l'argent.

C'est là que se trouve la dépendance.

C'est là que seront les échecs.

La course aux agents ne concerne pas seulement le meilleur modèle.

Elle concerne l'usine qui transforme les modèles en travail.