Agent IA en production : pourquoi le modèle compte moins que la boucle de contrôle

OpenAI a présenté Presence le 22 juillet 2026 comme un produit déployé pour des agents vocaux et conversationnels. La fiche ne décrit pas seulement un modèle. Elle réunit des règles métier, des actions autorisées, des simulations, des évaluations, des escalades humaines et un processus d’amélioration assisté par Codex.

Le produit reste réservé à des entreprises éligibles dans un programme de disponibilité générale limitée. Les déploiements sont conduits par les équipes d’OpenAI et certains intégrateurs. Ce n’est donc pas, à ce stade, un service autonome que toute entreprise peut activer seule.

OpenAI indique que son propre support téléphonique en anglais résout 75 % des demandes entrantes sans assistance humaine et que la boucle d’amélioration a réduit les transferts de 15 points en dix jours. Ces chiffres viennent d’OpenAI. Aucun protocole indépendant n’est publié dans l’annonce, ils ne peuvent donc pas servir de référence universelle.

Une politique de remboursement évolue. Un outil interne renvoie un nouveau code d’erreur. Une demande jusque-là rare devient fréquente. Le modèle peut rester identique alors que le comportement attendu a changé.

L’exploitation consiste à repérer cet écart, retrouver le contexte utile et décider si la réponse vient des connaissances, d’une permission, d’une règle, d’un outil ou du modèle. Remplacer immédiatement le modèle masque souvent le vrai problème.

Chaque étape produit un artefact vérifiable. Une équipe peut ainsi expliquer pourquoi elle modifie l’agent et revenir à la version précédente si le résultat se dégrade.

Copier une conversation de production dans un prompt ne suffit pas. Il faut retirer les données inutiles, conserver les éléments qui ont influencé la décision et enregistrer la version des règles, des connaissances et des outils utilisés.

Le test doit vérifier un résultat métier. L’agent a-t-il appliqué la bonne règle ? A-t-il demandé une validation avant l’action ? A-t-il choisi le bon outil ? S’est-il arrêté lorsque l’information manquait ? Une note globale de style ne répond à aucune de ces questions.

• Conserver un identifiant de cas sans recopier un dossier client complet
• Versionner les règles et les jeux d’évaluation
• Tester les appels d’outils et les refus, pas seulement le texte final
• Comparer la version candidate à celle qui tourne réellement
• Exiger une approbation avant tout changement de comportement en production

Manulife et Microsoft ont annoncé le même jour le déploiement d’Agent 365 comme registre central pour observer, gouverner et sécuriser les agents. Manulife prévoit aussi d’étendre Microsoft 365 Copilot à plus de 30 000 salariés. Cette communication conjointe montre l’échelle visée, mais ses gains de productivité déclarés restent des chiffres fournis par les entreprises concernées.

Une PME ou une ETI n’a pas besoin de reproduire cette infrastructure. Un registre plus simple peut déjà relier chaque agent à un propriétaire, une mission, des données, des outils, des droits, une version, un budget, des évaluations et une procédure d’arrêt.

Le NIST travaille sur les standards, l’identité et l’autorisation des agents. OWASP documente les risques propres aux systèmes autonomes et aux connexions MCP. Ces travaux convergent vers la même exigence : savoir quelle identité agit, avec quel accès et sous quel contrôle.

Presence peut convenir à une entreprise éligible qui cherche un accompagnement OpenAI pour des agents vocaux ou conversationnels. Une plateforme existante peut réduire le temps d’intégration lorsque ses limites correspondent au besoin. Une construction dédiée reste pertinente lorsque les données, les outils, la réversibilité ou le choix des modèles imposent un contrôle différent.

La décision ne se prend pas sur une démonstration. Elle compare l’éligibilité, les données, les canaux, les permissions, les évaluations, l’exploitation, la réversibilité et le coût total. Attendre reste une option valable si le processus n’a pas de propriétaire, de baseline ou de critère d’arrêt.

Le bon premier périmètre est fréquent, observable et suffisamment borné pour être testé. Ses actions sont réversibles ou soumises à validation. Les données accessibles sont connues et le coût actuel du processus peut être estimé.

Avant de brancher un outil, écris la décision attendue, les motifs de refus, le moment de l’escalade et la mesure qui entraînera l’arrêt du pilote. Le modèle vient ensuite.

• Une décision métier et un propriétaire identifiés
• Un jeu de cas réels nettoyés et rejouables
• Des permissions minimales par environnement
• Une baseline de qualité, de coût et de délai
• Des seuils d’escalade et d’arrêt écrits avant le lancement