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

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 — une API, un kit de développement, des outils appelables — sur laquelle une équipe assemble un système qui tournera sans personne devant l'écran. Cet article traite le second plan, qui n'est pas une voie marginale : plus de 2 millions de développeurs utilisent l'API (Chad Wyatt, 2026), qui représente 20 % des messages dans les workflows en entreprise (Chad Wyatt, 2026). Ces relevés figurent dans nos statistiques ChatGPT.

Deux repères évitent un aller-retour. Ce que le produit exécute seul, sans une ligne de code, relève du mode agent d'IA de ChatGPT. Et si l'écosystème n'est pas arrêté, comparer les familles d'outils et poser les exigences de la DSI et du RSSI relève du choix d'une plateforme d'agent IA. Ici, l'écosystème est supposé retenu : reste ce qu'on assemble, ce qu'on mesure, et à quelle condition on élargit.

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

La confusion coûte cher : un « agent dans ChatGPT » optimise la productivité individuelle, tandis qu'un agent construit via l'API doit gérer des permissions, des données, des quotas, de l'observabilité et des règles métier. Les deux se démontrent pourtant de la même façon, et c'est ce qui trompe : une démonstration ne montre jamais le comportement à la trentième exécution, sur des données incomplètes, quand une source a changé de format et que personne ne regarde.

La question qui tranche tient en une ligne : ai-je besoin d'un usage ponctuel, ou d'un système qui s'exécute en continu, avec des évaluations et une gouvernance ? Si la tâche revient une fois par trimestre et qu'un humain la déclenche, le produit suffit. Si elle revient chaque semaine, doit partir sans qu'on la lance et produit une sortie que d'autres systèmes consomment, vous construisez — et tout ce qui suit s'applique.

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

Le coût de la confusion n'est pas technique, il est organisationnel. Un usage produit ne demande personne : chacun l'adopte, l'abandonne, le reprend. Un agent construit sur l'API demande un propriétaire nommé, capable de répondre de ce que le système a fait un mardi à trois heures du matin. Il demande aussi trois compétences rarement réunies chez la même personne : quelqu'un qui écrit les règles métier, 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. Un agent n'est pas livré une fois : les modèles évoluent, les sources se déplacent, les règles métier changent, et chacun de ces mouvements peut faire régresser un comportement qui fonctionnait. Budgétez le rejeu des évaluations comme une astreinte : périodique, nommée, indépendante de celui qui a construit l'agent. Sinon l'agent redevient en quelques mois 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 est celle des démonstrations ; la seconde décide de votre planning. La maturité de l'ensemble n'est plus le sujet — 1,5 million de clients professionnels (Chad Wyatt, 2026) — mais un écosystème mûr fournit des briques, jamais votre système.

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

Quatre familles de briques se distinguent, toutes adossées à la même API, et il faut savoir laquelle vous utilisez : elles n'ont ni le même public ni le même coût de sortie. Aucune ne s'obtient avec un abonnement ChatGPT : l'usage produit et la couche de construction se facturent séparément, sur des comptes distincts.

• Un environnement de construction visuel : on assemble des étapes, on versionne, on pose des garde-fous sans écrire de code. Rapide à prototyper, et le bon support pour faire relire un enchaînement par le métier.
• Un kit de développement (SDK) pour agents : la même logique en code, appelant la même API, avec des types et des tests. C'est là que finissent les agents qu'on maintient.
• Des outils 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 qu'on oublie de compter parce qu'elle ne produit rien de visible : la couche d'évaluations, qui rejoue un jeu de cas et note les traces d'exécution, et qui est traitée plus bas. La distinction entre les deux premières familles n'est pas esthétique : 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 quatre postes ne se règle par un choix d'outil, et aucun ne disparaît si vous changez d'éditeur. C'est ce qui explique qu'un prototype convaincant en trois jours mette trois mois à atteindre la production : les trois jours consomment ce que l'écosystème fournit, les trois 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 trois choses : des instructions stables (règles, objectifs, style), 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, et noir sur blanc : ce que l'agent a le droit de faire, ce qu'il doit demander, ce qu'il doit refuser. Tant qu'ils ne sont pas écrits, vous n'avez pas un agent mais un prototype dont personne ne peut dire s'il s'est trompé.

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 exigées) : 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 documentaire ; une réponse plausible sans source est une dette qu'on ne découvre qu'en aval, souvent 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, et avec quel niveau de fraîcheur. En entreprise, privilégiez des connaissances maîtrisées — documents internes, référentiels produits, règles de marque — et faites du Web un complément pour l'actualité, les comparaisons et la vérification croisée.

Écrivez cette règle comme une priorité et non comme une préférence : le socle interne fait foi, le Web sert à compléter et, le cas échéant, à contredire. Un agent qui interroge le Web en premier vous rendra des réponses justes sur le marché et fausses sur vous, avec la même assurance. La construction de ce socle — découpage, indexation, fraîcheur — est un chantier à part entière, et elle pèse plus sur la qualité finale que le choix du modèle.

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

C'est ici que l'approche par briques se distingue d'un usage produit : le dispositif de mesure fait partie de ce qu'on construit, au même titre que les instructions. 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 tient 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.

Deux instruments l'outillent. 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 valeur attendue, la présence d'une citation, celle d'un motif de refus. Ils constatent, ils n'apprécient pas le sens : une réponse peut satisfaire tous les critères et rester fausse, et un grader qui délègue le jugement à un modèle hérite des erreurs de ce modèle. Les critères sémantiques — la réponse dit-elle vraiment la bonne chose — restent donc arbitrés par un humain, sur échantillon. La notation des traces s'applique après coup aux exécutions réelles, repassées au crible des mêmes critères. Le premier dit si l'agent tient ce que vous aviez imaginé ; le second, 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, à condition que la répartition soit juste — une moitié de cas nominaux, une moitié de cas qui doivent échouer proprement : donnée manquante, sources contradictoires, demande hors périmètre, tentative d'obtenir une action non autorisée. Un jeu uniquement nominal valide un agent qui n'a jamais rencontré la réalité.

Il s'écrit par le métier, pas par l'équipe technique : c'est le métier qui sait qu'une réponse omettant une contrainte contractuelle est fausse, même bien tournée. L'équipe technique la transforme ensuite en cas exécutable et en grader. Et ce jeu vit : chaque incident en production y ajoute un cas, qui n'en sort plus jamais. 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 donc, avant de mesurer, ce que chaque axe autorise et ce qu'il retire : sans cela, vous aurez un tableau de bord que personne ne lit et une autonomie qui s'élargit par lassitude. La grille se pose une fois et se relit à chaque élargissement.

La colonne de droite est la plus importante, et c'est celle qu'on oublie d'écrire : un dispositif qui ne sait qu'élargir n'est pas un contrôle, c'est un cliquet. Nommez qui a le droit de faire redescendre l'agent d'un cran, sans réunion : ce retour en arrière doit coûter moins cher qu'un incident.

Les garde-fous propres à un agent qui navigue

Dès qu'un agent lit le Web ouvert et accède en même temps à vos données, la surface de 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 dans sa sortie.

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 reçu. L'agent ne distingue pas structurellement ce qu'on lui demande de ce qu'il lit ; un texte bien placé peut donc lui faire divulguer un contenu, contourner une règle ou déclencher une action. Ce risque est propre aux agents qui cherchent de l'information à l'extérieur, et il ne se corrige pas en écrivant des instructions plus fermes.

Trois contre-mesures tiennent : des confirmations explicites avant toute action conséquente, la désactivation des connecteurs inutiles à la tâche en cours, et des permissions minimales sur ceux qui restent. La logique est constante : on ne cherche pas à empêcher l'agent de lire un contenu hostile, on fait en sorte qu'obéir à ce contenu ne serve à rien. Restreindre les droits d'écriture réduit la surface de risque, elle ne la supprime pas : un agent qui ne fait que lire reste exposé à l'injection, à la divulgation d'un contenu interne dans sa réponse et à l'exfiltration d'une donnée glissée dans une requête d'outil ou dans un lien qu'il suit. L'écriture y ajoute l'action non voulue, exécutée en votre nom.

Permissions minimales, validation humaine, traçabilité

Trois garde-fous 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 à tout moment, une validation s'ajoute, mais une trace non écrite au moment de 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 qui suit tout incident : quelle source l'agent a-t-il consultée, 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. Trois règles de branchement couvrent presque tous les cas :

• 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 qui vaille d'être mémorisé : 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. Le découpage en opérations atomiques rend chaque action annulable séparément, et c'est ce qui rend le premier droit d'écriture acceptable.

Trois règles encadrent ensuite la montée en charge :

• 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.

Reste le coût, et il 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. La tarification de cette couche doit être pensée comme un mix : volume de requêtes, taille des sorties, appels d'outils — web, fichiers, code — et supervision humaine. C'est le poste le plus souvent absent des estimations, et le seul qui ne baisse pas tout seul. Les montants et les paliers bougent trop vite pour être recopiés ici : relevez-les sur la page de tarification officielle de l'éditeur, pour la couche de construction et pour le produit séparément. L'usage est par ailleurs borné par des limites de débit et des quotas : vérifiez ce qui se passe quand un quota tombe en pleine exécution, car la réponse dit si l'agent s'arrête proprement ou laisse un traitement à moitié fait. Dimensionnez enfin en sachant que ce qui franchit l'étape du déploiement s'installe : le taux de rétention à douze mois de l'offre entreprise atteint 88 % (First Page Sage, 2026). Votre agent sera encore là dans un an, avec sa dette.

FAQ sur les agents d'IA d'OpenAI

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

Vous combinez un modèle, des instructions et des outils appelables, le tout orchestré par un enchaînement que vous versionnez. La démarche robuste tient en quatre temps : cadrer le cas d'usage et les limites d'action, brancher les sources (fichiers internes, Web, connecteurs), définir des formats de sortie contraints, puis mettre en place les évaluations avant d'augmenter l'autonomie. L'ordre compte : un agent évalué après coup ne se corrige plus, il se reconstruit.

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

C'est l'ensemble des briques de construction proposées autour de l'API : un environnement visuel pour assembler et versionner un enchaînement, un kit de développement pour faire la même chose en code, des outils intégrés (recherche web sourcée, fichiers, exécution de code, pilotage d'un navigateur) et des connecteurs vers des applications tierces. S'y ajoute une couche d'évaluation et d'optimisation : graders personnalisés et notation des traces d'exécution.

Quelle est la tarification ?

Il y en a deux, et les confondre fausse tout budget. Celle de ChatGPT est un abonnement par utilisateur, avec des volumes inclus et un mécanisme de dépassement ; elle n'ouvre aucun droit sur la couche de construction. Celle de la couche de construction — API, kit de développement, outils appelés, évaluations — suit l'usage : nombre de requêtes, longueur des sorties, appels d'outils. Les montants ne se citent pas de mémoire : ils se vérifient sur la page de tarification officielle, qui distingue elle-même les deux. À ces postes s'ajoute le coût de supervision humaine, qui reste le plus stable et le plus souvent oublié dans les estimations initiales.

Quelles sont les capacités des agents OpenAI ?

Un agent construit sur cette couche peut raisonner puis agir via des outils : chercher sur le Web avec des réponses sourcées, lire des fichiers, exécuter du code, piloter un navigateur, et appeler des applications métier par connecteur. Il conserve un contexte de tâche entre les étapes, ce qui lui permet d'enchaîner sans repartir de zéro. Ces capacités décrivent ce qu'il peut faire ; ce qu'il a le droit de faire dépend entièrement des permissions que vous accordez.

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

Un assistant conversationnel répond à des requêtes, mais ne garantit ni l'exécution ni la traçabilité. Un workflow outillé enchaîne des étapes prédéfinies, mais reste rigide dès que le cas s'écarte du chemin prévu. Un agent choisit et orchestre des outils selon le contexte, itère, et demande une validation avant les actions importantes. La différence pratique n'est pas l'intelligence : c'est le droit d'agir, et ce qui en est journalisé.

Quand passer d'un agent unique à une orchestration multi-agents ?

Quand un seul run doit porter des responsabilités incompatibles : rechercher et citer, exécuter, contrôler la qualité, vérifier la conformité. Le signal est simple : si vous ajoutez des garde-fous et des validations au point de rendre l'agent « lourd », découpez-le en sous-agents aux entrées et sorties structurées, donc évaluables séparément. Tant que ce n'est pas le cas, le multi-agents ajoute de la coordination sans ajouter de qualité.

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

Trois suffisent pour démarrer, et ils ne se négocient pas : une validation explicite avant toute action irréversible (achat, e-mail, publication), des permissions minimales assorties des seuls connecteurs strictement nécessaires, et une trace conservée des outils appelés, des sources consultées, des décisions et des sorties. Le risque d'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 ?

Construisez un jeu de cas à partir de données réelles, en y incluant les cas limites, puis attachez à chacun ce qu'un grader doit constater dans la sortie. Mesurez cinq axes : exactitude, respect des règles, qualité des sources, coût, latence. Rejouez après chaque modification, et complétez par la notation des traces d'exécution réelles. N'élargissez les droits qu'après plusieurs rejeux stables, jamais après un seul bon résultat.

Continuez votre lecture

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