OpenAI Presence : 7 leçons pour construire un agent IA vraiment exploitable

OpenAI a lancé Presence en juillet 2026 pour aider des entreprises à déployer des agents vocaux et conversationnels dans des flux réels. Le produit vise notamment le support client, certaines opérations commerciales et des demandes internes sensibles. La nouveauté attire naturellement l’attention sur le modèle. Pourtant, la partie la plus utile pour un fondateur ou une équipe produit se trouve ailleurs : OpenAI décrit un système complet autour du modèle.

Un agent exploitable ne se résume pas à une fenêtre de chat branchée sur des documents. Il reçoit un rôle précis, seulement les connaissances nécessaires, une liste d’actions autorisées, des règles d’approbation, des tests, un relais humain et un processus de mise à jour. Vous pouvez reprendre cette architecture même si votre entreprise n’est pas éligible à Presence et même si vous construisez avec une autre pile technique.

Ce qu’OpenAI Presence apporte réellement

Dans son annonce officielle du 22 juillet 2026, OpenAI présente Presence comme un produit déployé avec ses ingénieurs et certains intégrateurs. Il prend en charge des agents vocaux et chat capables de répondre, consulter des systèmes, effectuer des actions approuvées et transférer la demande à une personne.

Presence n’est pas un produit libre-service au moment de l’annonce. Cette limite compte. Une PME ne peut pas simplement créer un compte, importer sa base de connaissance et reproduire le dispositif. En revanche, l’annonce rend visible une méthode de conception que toute équipe peut appliquer à une échelle adaptée.

1. Donnez un seul métier à l’agent

OpenAI explique que chaque déploiement commence par un travail précis : résoudre un problème de facturation, traiter une demande d’assurance ou répondre à un ticket informatique interne. Ce choix réduit immédiatement le périmètre des données, des outils, des règles et des tests.

Remplacez « nous voulons un assistant IA » par une phrase observable :

L’agent aide un client authentifié à comprendre une facture, consulte les lignes concernées, applique la politique de remboursement approuvée et transfère le dossier lorsqu’une exception apparaît.

Cette phrase permet à l’équipe produit de dessiner le flux. Elle permet aussi à l’équipe métier de dire ce que l’agent ne doit jamais faire.

2. Limitez les connaissances au rôle choisi

Un agent qui reçoit toute la documentation de l’entreprise ne devient pas automatiquement plus utile. Il reçoit davantage de versions, de contradictions, de documents obsolètes et d’informations qu’il ne devrait peut-être pas voir.

Créez un registre simple pour chaque source :

Source	Propriétaire	Version	Rôle autorisé	Date de révision
Politique de remboursement	Finance	3.2	Support facturation	Chaque changement de prix
Catalogue produit	Produit	En production	Avant-vente	Chaque mise en ligne
Procédure d’incident	Opérations	7	Support interne	Trimestrielle

L’agent doit connaître la source qui fait autorité. Votre équipe doit savoir qui la corrige.

3. Séparez répondre, proposer et agir

Une réponse textuelle, une proposition d’action et une action réelle ne présentent pas le même risque. Dessinez trois niveaux :

1. Répondre : expliquer une règle ou afficher une information autorisée.
2. Proposer : préparer une modification qu’une personne confirme.
3. Agir : écrire dans un système, déclencher une transaction ou contacter un tiers.

Commencez au niveau le plus bas qui crée déjà de la valeur. Ajoutez une action seulement lorsque vous pouvez définir son autorisation, son annulation, sa trace et son contrôle.

4. Écrivez le relais humain avant le scénario idéal

Un agent utile ne cherche pas à éviter tout transfert. Il reconnaît le moment où une personne doit reprendre. OpenAI cite les règles d’escalade comme une composante centrale de Presence.

Définissez des déclencheurs explicites :

• le client conteste son identité ou les données affichées ;
• la demande exige une exception à une politique ;
• deux sources autorisées se contredisent ;
• l’action ne peut pas être annulée ;
• la confiance du système passe sous le seuil choisi ;
• le client demande une personne.

Transmettez aussi le contexte déjà collecté. Un relais qui oblige le client à tout répéter n’est pas un vrai relais.

5. Testez des décisions, pas seulement des formulations

OpenAI décrit des simulations et des évaluations qui vérifient le résultat, le respect des règles, l’usage correct des outils et l’escalade. Appliquez la même logique avec une bibliothèque de cas.

Chaque test doit contenir une demande, le contexte disponible, les actions autorisées, le résultat attendu et les motifs de transfert. Ajoutez des cas ordinaires, des données manquantes, une instruction contradictoire, une tentative de contourner la politique et une panne d’un système connecté.

Ne notez pas seulement si la réponse « semble bonne ». Vérifiez si l’agent a choisi la bonne source, demandé l’autorisation au bon moment et laissé une trace exploitable.

6. Traitez la production comme une source de travail

Après la mise en ligne, les demandes réelles révèlent les formulations imprévues, les trous documentaires et les cas d’escalade mal définis. Presence transforme ces signaux en propositions d’amélioration que l’équipe peut tester et approuver.

Votre version plus simple peut suivre le même cycle :

1. collecter les échecs et les transferts avec leur identifiant ;
2. classer la cause : connaissance, règle, outil, interface ou périmètre ;
3. corriger une source ou un scénario de test ;
4. rejouer la bibliothèque avant de déployer ;
5. publier progressivement et surveiller le changement.

Le modèle change, mais votre responsabilité produit reste stable.

7. Construisez d’abord le flux sans IA

Avant de choisir un modèle, dessinez le parcours avec des décisions déterministes. Où l’identité se vérifie-t-elle ? Quelle base fait autorité ? Qui approuve l’action ? Comment le système annule-t-il une erreur ? Que voit la personne qui reprend ?

Si votre équipe ne peut pas expliquer le flux sans parler de « magie IA », elle ne peut pas encore le tester. Le modèle doit améliorer une opération comprise, pas masquer une opération confuse.

La checklist à utiliser avant un prototype

• Un seul rôle tient dans une phrase.
• Chaque source possède un propriétaire et une version.
• Répondre, proposer et agir utilisent des autorisations distinctes.
• Le relais humain possède des déclencheurs écrits.
• Chaque action importante laisse une trace.
• La bibliothèque de tests couvre les cas normaux et les échecs.
• L’équipe peut revenir à la version précédente.
• Une personne reste propriétaire du résultat métier.

Construisez la version ciblée avec Doved Studio

Presence montre à quoi ressemble un dispositif enterprise complet. La plupart des équipes ont d’abord besoin d’une version plus étroite : une application métier, un portail client, un outil interne ou un agent intégré à un flux existant.

Doved Studio réunit cadrage produit, UX et développement pour transformer ce rôle précis en application iOS, Android ou web. Nous commençons par le flux, les permissions, les données, le relais humain et les tests. Nous choisissons ensuite la couche IA qui sert réellement le besoin. Le code, les comptes et la propriété du produit restent au client.

Parlez-nous de votre application avec un seul cas d’usage concret. Nous vous aiderons à décider s’il mérite un agent, une automatisation classique ou une interface plus simple.

Questions fréquentes

OpenAI Presence est-il disponible en libre-service ?

Non au moment de l’annonce. OpenAI le propose à des entreprises éligibles dans un programme de disponibilité générale limitée, avec ses ingénieurs et certains intégrateurs.

Faut-il construire un agent vocal ?

Non. Choisissez le canal qui correspond au travail. Un formulaire guidé ou une interface web peut produire un meilleur résultat lorsqu’une tâche exige des pièces, une comparaison visuelle ou plusieurs validations.

Un agent peut-il agir sans validation humaine ?

Il peut uniquement agir dans le périmètre que votre système autorise. Commencez par des actions réversibles et à faible risque. Exigez une validation humaine dès que l’impact, l’incertitude ou l’irréversibilité l’impose.