Agent d’IA OpenAI : ce qu’on assemble, ce qu’on évalue, ce qu’on autorise

Cette page s'adresse aux directeurs marketing, opérations ou SI dont l'équipe a retenu OpenAI et doit maintenant construire un agent d'IA OpenAI qui tournera sans personne devant l'écran. Elle permet de décider trois choses : quelles briques on assemble et lesquelles restent à votre charge, comment on mesure l'agent avant de l'élargir, et à quelle condition on lui accorde un droit d'écriture.

Elle s'appuie sur les quatre niveaux de droits et les sept familles d'agents de notre panorama des agents d'IA, qu'elle ne redéfinit pas.

Deux plans à ne pas confondre : le produit et la couche de construction

Chez OpenAI, le mot « agent » recouvre deux objets qui n'ont ni le même acheteur, ni le même coût, ni la même durée de vie. D'un côté une expérience produit : on décrit une tâche dans une interface et on la regarde s'exécuter. De l'autre une couche de construction (à la date de rédaction, la Responses API, l'Agents SDK et des outils appelables) sur laquelle une équipe assemble un système autonome.

Ce second plan n'est pas marginal : plus de 2 millions de développeurs utilisent l'API (Chad Wyatt, 2026), chiffre relevé dans nos statistiques ChatGPT. Le tableau suivant résume ce qui sépare les deux plans.

Si l'écosystème n'est pas arrêté, comparer les familles d'outils relève du choix d'une plateforme d'agent IA. Ici, il est supposé retenu.

Usage ponctuel ou système qui s'exécute en continu

Les deux plans se démontrent de la même façon, et c'est ce qui trompe : une démonstration ne montre jamais la trentième exécution sur des données incomplètes. Si la tâche revient une fois par trimestre, déclenchée par un humain, le produit suffit ; son périmètre est décrit sur le mode agent d'IA de ChatGPT. Si elle revient chaque semaine, part seule et alimente d'autres systèmes, vous construisez.

Ce que la confusion coûte, côté organisation

Le coût de la confusion est organisationnel. Un usage produit ne demande personne. Un agent construit sur l'API demande un propriétaire nommé, qui réponde de ce que le système a fait un mardi à trois heures du matin, et des compétences rarement réunies chez la même personne.

• Quelqu'un qui écrit les règles métier : ce que l'agent refuse, escalade, ne négocie jamais.
• Quelqu'un qui tient l'intégration et les droits d'accès.
• Quelqu'un qui maintient le jeu de cas d'évaluation.

Le maintien est justement le poste qu'on oublie au cadrage. Les modèles évoluent, les sources se déplacent, les règles changent, et chaque mouvement peut faire régresser l'agent. Budgétez le rejeu des évaluations comme une astreinte : périodique, nommée, indépendante du constructeur. Sinon l'agent redevient un script que plus personne n'ose modifier.

Ce qu'OpenAI fournit pour construire, et ce qui reste à votre charge

Un écosystème d'éditeur se juge sur deux listes : ce qu'il vous évite d'assembler, et ce qu'il vous laisse quand même. La première fait les démonstrations ; la seconde décide de votre planning.

Les briques fournies : construction visuelle, kit de développement, outils

Les briques se répartissent en quatre familles, toutes adossées à la même API, qui n'ont ni le même public ni le même coût de sortie. Aucune ne s'obtient avec un abonnement ChatGPT. À la date de rédaction, elles portent les noms suivants.

• Un constructeur visuel (Agent Builder) : on assemble des étapes, on versionne, on pose des règles sans écrire de code. Rapide à prototyper, bon support de relecture par le métier.
• Un kit de développement (Agents SDK) : la même logique en code, appelant la Responses API, avec des types et des tests. C'est là que finissent les agents qu'on maintient.
• Des outils intégrés, appelables par le modèle : recherche web sourcée, recherche dans des fichiers, exécution de code, pilotage d'un navigateur. Ce sont des capacités, pas des intégrations : elles élargissent ce que l'agent peut faire, pas ce qu'il a le droit de faire.
• Des connecteurs vers des applications tierces, avec l'authentification, les portées d'accès et les quotas associés.

S'y ajoute une cinquième brique, invisible parce qu'elle ne produit rien : la couche d'évaluations (Evals), qui rejoue un jeu de cas et note les traces d'exécution, traitée plus bas. Un enchaînement visuel se relit vite mais s'exporte mal ; un enchaînement en code se compare et se restaure. Prototypez avec le premier, produisez avec le second, et placez la bascule là où l'agent obtient son premier droit d'écriture.

Ce que l'écosystème ne fournit pas, et qui reste chez vous

Le reste vous appartient, et c'est lui qui fait le projet.

• Les règles métier : ce que l'agent doit refuser, ce qu'il doit escalader, ce qui n'est jamais négociable.
• La qualité des données consultées : un socle à jour, avec des droits de lecture qui reflètent ceux de vos équipes.
• Le jeu de cas d'évaluation : personne ne peut l'écrire à votre place, parce qu'il encode ce que « correct » veut dire chez vous.
• Le raccordement à vos systèmes : reprise sur erreur, files d'attente, choix de ce qui se journalise.

Aucun de ces postes ne se règle par un choix d'outil ni ne disparaît en changeant d'éditeur. C'est pourquoi un prototype convaincant en trois jours met trois mois à atteindre la production : les jours consomment ce que l'écosystème fournit, les mois ce qu'il laisse.

Le noyau d'un agent : instructions, formats de sortie, critères d'arrêt

Un agent en production, ce n'est pas « un prompt plus long » : c'est une architecture qui relie modèle, outils, données, mémoire, évaluation, sécurité et supervision. Le noyau repose sur des instructions stables, des contraintes de sortie (schémas, formats) et des critères d'arrêt, le moment où l'agent cesse de décider et escalade à un humain.

Ces éléments s'écrivent avant la première ligne de code ; tant qu'ils ne le sont pas, vous avez un prototype dont personne ne peut dire s'il s'est trompé. Le tableau suivant liste ce qu'il faut avoir écrit.

De la réponse plausible à la réponse défendable

Un modèle produit toujours une réponse ; rien ne garantit qu'elle soit vérifiable. Trois décisions déplacent la sortie du plausible vers le défendable, et chacune se paie en contrainte.

• Format de sortie structuré (tableau, schéma, plan) : automatisation plus fiable (lecture machine, tickets, enchaînements), au prix d'une sortie moins lisible telle quelle.
• Règles de validation (seuils, escalade) : réduction des erreurs en production, au prix d'un taux d'escalade élevé les premières semaines.
• Critères de défendabilité (sources requises) : contrôle qualité objectivable, au prix de réponses parfois vides quand la source manque, ce qui est le comportement souhaité.

La troisième est celle qu'on retire en premier quand l'agent « ne répond pas assez ». C'est l'erreur : une réponse vide pointe un trou dans le socle ; une réponse plausible sans source est une dette découverte chez un client.

La stratégie de récupération décide plus que la mémoire

La performance d'un agent dépend moins d'une « mémoire magique » que d'une stratégie de récupération : quelles sources interroger, quand, avec quelle fraîcheur. En entreprise, la hiérarchie s'écrit en trois lignes.

• Le socle interne fait foi : documents internes, référentiels produits, règles de marque.
• Le Web sert à compléter : actualité, comparaisons, vérification croisée.
• Le Web peut contredire le socle : la contradiction se signale, elle ne se tranche pas en silence.

Écrivez cette règle comme une priorité : un agent qui interroge le Web en premier rendra des réponses justes sur le marché et fausses sur vous, avec la même assurance. La construction du socle pèse plus sur la qualité finale que le choix du modèle.

Évaluer avant d'élargir : jeux de cas, graders, notation des traces

Le dispositif de mesure fait partie de ce qu'on construit. On n'élargit pas l'autonomie d'un agent parce qu'il « a l'air bon », mais parce qu'un jeu de cas rejoué donne un résultat stable. La boucle se déroule en trois temps.

• Définissez un jeu de cas réalistes (tâches simples, puis cas limites).
• Mesurez la qualité (exactitude, complétude, citations, respect des règles, coût).
• Optimisez (prompts, outils, stratégie de récupération), puis répétez.

Les graders sont des vérificateurs automatiques : à chaque cas on attache ce qui se constate mécaniquement dans la sortie (un champ présent, un format respecté, une citation, un motif de refus). Ils constatent sans apprécier le sens : une réponse peut satisfaire tous les critères et rester fausse. Les critères sémantiques restent donc arbitrés par un humain, sur échantillon.

La notation des traces s'applique après coup aux exécutions réelles, au crible des mêmes critères. Les graders disent si l'agent tient ce que vous aviez imaginé ; les traces, ce que vous n'aviez pas imaginé.

Écrire un jeu de cas utilisable : combien, quelle variété, qui l'écrit

Un jeu de cas n'est pas un échantillon statistique : c'est une liste de situations dont vous connaissez déjà la bonne réponse. Quelques dizaines suffisent à démarrer, pour moitié des cas nominaux, pour moitié des cas qui doivent échouer proprement. Les échecs attendus couvrent au moins quatre situations.

• Une donnée manquante.
• Des sources contradictoires.
• Une demande hors périmètre.
• Une tentative d'obtenir une action non autorisée.

Il s'écrit par le métier, qui sait qu'une réponse omettant une contrainte contractuelle est fausse, même bien tournée ; l'équipe technique le transforme en cas exécutables et en graders. Et ce jeu vit : chaque incident en production y ajoute un cas, qui n'en sort plus. C'est la seule non-régression dont on dispose sur un système probabiliste.

Ce que le résultat autorise, et ce qui fait redescendre

Un score ne sert à rien s'il n'est pas attaché à une décision. Fixez, avant de mesurer, ce que chaque axe autorise et ce qu'il retire ; sinon l'autonomie s'élargit par lassitude.

Un dispositif qui ne sait qu'élargir n'est pas un contrôle, c'est un cliquet. Nommez qui peut faire redescendre l'agent d'un cran, sans réunion : ce retour doit coûter moins cher qu'un incident. Le « premier droit d'écriture » correspond au niveau 2, écriture contrôlée, des quatre niveaux du panorama.

Les garde-fous propres à un agent qui navigue

Dès qu'un agent lit le Web ouvert et accède à vos données, le risque change de nature : le danger n'est plus seulement qu'il se trompe, c'est qu'il obéisse à quelqu'un d'autre que vous, sans que rien ne le signale.

L'injection de prompts : ce que c'est, et pourquoi un meilleur prompt n'y suffit pas

Une injection de prompts est une instruction malveillante cachée dans un contenu que l'agent consulte : une page, un document, un message. L'agent ne distingue pas structurellement ce qu'on lui demande de ce qu'il lit ; un texte bien placé peut lui faire divulguer un contenu, contourner une règle ou déclencher une action. Des instructions plus fermes n'y changent rien. Trois contre-mesures tiennent.

• Des confirmations explicites avant toute action conséquente.
• La désactivation des connecteurs inutiles à la tâche en cours.
• Des permissions minimales sur ceux qui restent.

La logique est constante : on n'empêche pas l'agent de lire un contenu hostile, on fait en sorte qu'y obéir ne serve à rien. Restreindre l'écriture réduit la surface sans la supprimer : un agent en lecture seule reste exposé à la divulgation et à l'exfiltration d'une donnée glissée dans une requête d'outil ou un lien. L'écriture y ajoute l'action non voulue, exécutée en votre nom.

Permissions minimales, validation humaine, traçabilité

Trois protections se posent au cadrage, pas après le premier incident.

• Permissions minimales : accès en lecture par défaut, écriture seulement sur des périmètres à faible risque.
• Validation humaine : obligatoire pour les e-mails, les achats, les changements irréversibles et les contenus sensibles.
• Traçabilité : journaliser les outils appelés, les sources consultées, les décisions et les résultats.

La traçabilité est la seule des trois qui ne se rattrape pas : une permission se restreint, une validation s'ajoute, mais une trace non écrite à l'exécution n'existera jamais. Décidez de ce qui se journalise avant la mise en service, et vérifiez sur un cas réel que vous savez répondre à la question de tout incident : quelle source, et pourquoi cette action ?

Mettre en production : brancher, superviser, tenir les coûts

Un bon déploiement privilégie la répétabilité et la supervision : on commence petit, on mesure, puis on élargit. Les règles de branchement qui couvrent presque tous les cas sont au nombre de trois.

• Exposez vos données en lecture avec des permissions minimales.
• Découpez les actions en opérations atomiques : créer un ticket, exporter un rapport, proposer un brouillon.
• Ajoutez des webhooks et des validations dès que l'agent sort du « conseil » pour entrer dans « l'exécution ».

La troisième règle porte le seul seuil de risque à mémoriser : tant que l'agent conseille, le pire résultat est une perte de temps ; dès qu'il exécute, c'est un état de système à défaire. Les opérations atomiques rendent chaque action annulable séparément. La montée en charge obéit ensuite à ses propres règles.

• Supervision : tableaux de bord et alertes sur les dérives de consommation, les sources faibles, les erreurs répétées.
• Découpage : évitez les agents « monolithiques » qui font tout en une fois, impossibles à diagnostiquer.
• Autonomie : augmentez-la seulement après des évaluations stables, jamais après une bonne semaine.

Le coût, enfin, n'est pas celui de ChatGPT : un abonnement au produit ne couvre ni l'API, ni le kit de développement, ni les outils appelés, ni les évaluations. Les montants bougent trop vite pour être recopiés ici : relevez-les sur la page de tarification officielle. Le tableau suivant donne les postes à budgéter.

La question des quotas dit si l'agent s'arrête proprement ou laisse un traitement à moitié fait. Et ce qui franchit le déploiement s'installe : votre agent sera encore là dans un an, avec sa dette.

Continuez votre lecture

Selon votre point de blocage, un autre article prend le relais.

• Vous voulez la méthode avant l'outil : cadrer, écrire les règles, tester et gouverner est déroulé dans le guide pour créer un agent d'IA.
• Votre point dur est le socle documentaire : découpage, index et fraîcheur sont traités sur l'agent d'IA avec RAG.
• Votre agent unique est devenu trop lourd : coordination, arbitrage des conflits et rejeu relèvent de l'orchestration d'agents d'IA.
• Il reste à relier les briques à vos systèmes : connecteurs, webhooks et reprise sur erreur sont le sujet de l'intégration d'un agent d'IA.

Et si ce qui vous manque est le socle interne où l'agent doit s'ancrer, des contenus validés et à jour, c'est la tâche qu'encadre la génération de contenus par une IA personnalisée.

FAQ sur les agents d'IA d'OpenAI

Comment utiliser l'API OpenAI pour créer un agent ?

Un agent se crée en combinant un modèle, des instructions et des outils appelables, orchestrés par un enchaînement versionné. La démarche suit quatre temps : cadrer le cas d'usage et les limites d'action, brancher les sources, contraindre les formats de sortie, puis poser les évaluations avant d'augmenter l'autonomie.

Qu'est-ce que la plateforme d'agents d'OpenAI ?

La plateforme d'agents d'OpenAI est l'ensemble des briques de construction proposées autour de l'API. À la date de rédaction, elle réunit un constructeur visuel (Agent Builder), un kit de développement (Agents SDK) sur la Responses API, des outils intégrés, des connecteurs tiers et une couche d'évaluation (Evals).

Quelle est la tarification ?

Il existe deux tarifications distinctes, et les confondre fausse tout budget. ChatGPT se facture par abonnement utilisateur et n'ouvre aucun droit sur la couche de construction, qui suit l'usage : requêtes, longueur des sorties, appels d'outils. Les montants se vérifient sur la page de tarification officielle ; la supervision humaine s'y ajoute.

Quelles sont les capacités des agents OpenAI ?

Un agent construit sur cette couche raisonne puis agit via des outils : recherche web sourcée, lecture de fichiers, exécution de code, pilotage d'un navigateur et connecteurs vers des applications métier, en conservant un contexte entre les étapes. Ces capacités décrivent ce qu'il peut faire ; ce qu'il a le droit de faire dépend des permissions accordées.

Quelle différence entre un agent OpenAI, un assistant conversationnel et un workflow outillé ?

La différence est le droit d'agir et ce qui en est journalisé. Un assistant conversationnel répond sans garantir l'exécution ni la traçabilité. Un workflow outillé enchaîne des étapes prédéfinies et se rigidifie hors du chemin prévu. Un agent choisit ses outils selon le contexte, itère et demande une validation avant les actions importantes.

Quels garde-fous minimaux pour limiter les erreurs, les actions à risque et l'exfiltration de données ?

Trois protections suffisent pour démarrer : une validation explicite avant toute action irréversible, des permissions minimales avec les seuls connecteurs nécessaires, et une trace des outils, sources, décisions et sorties. L'injection de prompts rend le deuxième point décisif : moins l'agent a de droits, moins une instruction hostile peut en tirer parti.

Comment évaluer un agent avant un déploiement à l'échelle ?

Un agent s'évalue sur un jeu de cas issu de données réelles, cas limites compris, où chaque cas précise ce qu'un grader doit constater. On mesure cinq axes : exactitude, respect des règles, qualité des sources, coût, latence. On rejoue après chaque modification et on n'élargit les droits qu'après plusieurs rejeux stables.