Guide pratique d’OpenAI pour concevoir des agents

• Avec l’amélioration des capacités de raisonnement, de multimodalité et d’usage des outils des LLM, une nouvelle catégorie de systèmes est apparue : les agents, capables d’exécuter des workflows de manière autonome pour le compte des utilisateurs
• Un agent repose sur trois composants essentiels : le modèle (LLM), les outils (API/fonctions externes) et les instructions (guidelines), avec une orchestration possible sous forme d’agent unique ou de système multi-agents
• L’adoption d’agents est adaptée aux workflows qui nécessitent des prises de décision complexes, des systèmes de règles difficiles à maintenir et le traitement de données non structurées
• Les garde-fous sont des mécanismes de défense multicouches indispensables au déploiement d’agents, afin de protéger la confidentialité des données, la sécurité du contenu et la cohérence de marque
• La clé d’un déploiement réussi réside dans une approche itérative : commencer avec un seul agent, puis étendre progressivement après validation auprès de vrais utilisateurs

---

Définition des agents

• Un agent est un système qui accomplit des tâches de manière autonome pour le compte de l’utilisateur, en prenant en charge des workflows comme la résolution de problèmes de service client, la réservation de restaurants, le commit de modifications de code ou la génération de rapports
• Les applications qui intègrent un LLM sans lui confier le contrôle de l’exécution du workflow (chatbots simples, LLM en un seul tour, classificateurs de sentiment, etc.) ne sont pas des agents
• Caractéristiques clés d’un agent :
  • il exploite un LLM pour piloter l’exécution du workflow, prendre des décisions, reconnaître quand le workflow est terminé et ajuster proactivement son comportement si nécessaire
  • il interrompt l’exécution en cas d’échec et rend le contrôle à l’utilisateur
  • il peut accéder à divers outils pour interagir avec des systèmes externes, en sélectionnant dynamiquement l’outil approprié selon l’état du workflow, tout en opérant dans des garde-fous clairement définis

Quand faut-il concevoir des agents ?

• Contrairement à l’automatisation classique, les agents sont adaptés aux workflows où les approches déterministes et fondées sur des règles atteignent leurs limites
• Exemple d’analyse de fraude au paiement : un moteur de règles traditionnel applique une logique de checklist en signalant les transactions selon des critères prédéfinis, tandis qu’un agent LLM agit comme un enquêteur expérimenté capable d’évaluer le contexte, de tenir compte de motifs subtils et d’identifier des activités suspectes même sans violation explicite d’une règle
• Trois types de cas où les agents apportent de la valeur :
  • prise de décision complexe : workflows qui exigent des jugements fins, des exceptions et des décisions sensibles au contexte (ex. : approbation de remboursements en service client)
  • règles difficiles à maintenir : systèmes reposant sur des ensembles de règles vastes et complexes, coûteux à mettre à jour ou sujets aux erreurs (ex. : revues de sécurité fournisseurs)
  • scénarios fortement dépendants de données non structurées : interprétation du langage naturel, extraction de sens à partir de documents et interactions conversationnelles avec l’utilisateur (ex. : traitement de sinistres en assurance habitation)
• Si ces critères ne sont pas clairement remplis, une solution déterministe peut suffire

Fondamentaux de la conception d’agents

• Trois composants essentiels

  • Modèle (Model) : le LLM qui alimente le raisonnement et la prise de décision de l’agent
  • Outils (Tools) : fonctions externes ou API que l’agent utilise pour agir
  • Instructions (Instructions) : guidelines explicites et garde-fous qui définissent la manière dont l’agent doit se comporter

• Choix du modèle

  • Le modèle le plus puissant n’est pas nécessaire pour toutes les tâches : une recherche simple ou une classification d’intention peut être gérée par un petit modèle rapide, alors que des décisions plus difficiles, comme l’approbation d’un remboursement, bénéficient d’un modèle plus puissant
  • En phase de prototypage, il est efficace de définir une ligne de base de performance avec le modèle le plus puissant, puis de le remplacer progressivement par des modèles plus petits pour vérifier si les résultats restent acceptables
  • Principes de sélection du modèle :
    • mettre en place des évaluations (evals) pour établir une référence de performance
    • viser d’abord l’objectif de précision avec le meilleur modèle
    • remplacer ensuite par des modèles plus petits là où c’est possible afin d’optimiser les coûts et la latence

• Définition des outils

  • Les outils étendent les capacités de l’agent en exploitant les API de l’application ou du système sous-jacent
  • Dans les systèmes legacy dépourvus d’API, il est possible d’interagir directement via des interfaces web et applicatives en utilisant un computer-use model
  • Chaque outil doit avoir une définition standardisée, afin de prendre en charge une relation flexible de plusieurs-à-plusieurs entre outils et agents
  • Des outils réutilisables, bien documentés et rigoureusement testés améliorent la découvrabilité, simplifient la gestion des versions et évitent les définitions redondantes
  • Trois types d’outils sont nécessaires pour un agent :
    • Données (Data) : récupérer le contexte et les informations nécessaires à l’exécution du workflow (ex. : requêtes sur une base de transactions, système CRM, lecture de PDF, recherche web)
    • Action (Action) : interagir avec des systèmes pour ajouter des informations dans une base, mettre à jour des enregistrements ou envoyer des messages (ex. : envoi d’e-mails/SMS, mise à jour d’un enregistrement CRM, transfert d’un ticket de support à un humain)
    • Orchestration (Orchestration) : l’agent lui-même agit comme outil d’un autre agent (ex. : agent de remboursement, agent de recherche, agent de rédaction)

• Structuration des instructions

  • Des instructions de haute qualité sont essentielles dans toute application basée sur un LLM, mais elles sont particulièrement importantes pour les agents
  • Des instructions claires réduisent l’ambiguïté et améliorent la prise de décision de l’agent, ce qui favorise une exécution plus fluide des workflows et moins d’erreurs
  • Bonnes pratiques pour les instructions d’agents :
    • réutiliser la documentation existante : s’appuyer sur les procédures opérationnelles, scripts de support et documents de politique déjà en place pour créer des routines compatibles avec les LLM (dans le service client, une routine correspond généralement à peu près à un document individuel de la base de connaissances)
    • prompts de décomposition de tâches : fournir des étapes plus petites et plus claires à partir de ressources denses afin de minimiser l’ambiguïté
    • définition claire des actions : spécifier que chaque étape de la routine correspond à une action ou une sortie précise (ex. : demander un numéro de commande, récupérer les détails du compte via un appel API)
    • prise en compte des cas limites : anticiper les variations courantes, comme un utilisateur qui fournit des informations incomplètes ou pose une question inattendue, et inclure des étapes conditionnelles ou des branches pour expliquer comment traiter ces situations
  • Il est aussi possible d’utiliser des modèles avancés comme o1 ou o3‑mini pour générer automatiquement des instructions à partir de documents existants

Orchestration

• Système à agent unique

  • Un agent unique peut prendre en charge de nombreuses tâches en ajoutant progressivement des outils, ce qui simplifie la gestion de la complexité ainsi que l’évaluation et la maintenance
  • Toute approche d’orchestration a besoin de la notion de run, généralement implémentée comme une boucle dans laquelle l’agent fonctionne jusqu’à atteindre une condition d’arrêt
  • Conditions d’arrêt courantes : appel d’outil, sortie structurée spécifique, erreur, nombre maximal de tours atteint
  • Dans l’Agents SDK, l’agent est lancé via la méthode Agents.run() et la boucle s’arrête en cas d’appel d’outil de sortie finale ou de réponse du modèle sans appel d’outil
  • Stratégie de template de prompt : au lieu de nombreux prompts distincts, utiliser un prompt de base unique et flexible qui reçoit des variables de politique, afin de s’adapter à différents contextes et de simplifier fortement la maintenance et l’évaluation

• Quand passer à un système multi-agents

  • La recommandation générale est de maximiser d’abord les capacités d’un agent unique
  • Davantage d’agents offrent une séparation conceptuelle intuitive, mais introduisent aussi de la complexité et du surcoût ; dans bien des cas, un agent unique muni d’outils suffit
  • Recommandations pratiques pour scinder un agent :
    • logique complexe : si le prompt contient de nombreuses conditions (branches if-then-else) et que le template de prompt devient difficile à faire évoluer, séparer chaque segment logique dans un agent distinct
    • surcharge d’outils : le problème ne vient pas du nombre d’outils, mais de leur similarité ou de leur redondance — certaines implémentations gèrent avec succès plus de 15 outils clairement différenciés, tandis que d’autres rencontrent déjà des difficultés avec moins de 10 outils redondants

• Pattern manager (utiliser des agents comme outils)

  • Un LLM central, le « manager », orchestre un réseau d’agents spécialisés via des appels d’outils
  • Le manager délègue les tâches au bon agent au bon moment sans perdre le contexte ni le contrôle, puis synthétise les résultats en une interaction unifiée
  • Ce pattern convient aux workflows dans lesquels un seul agent doit contrôler l’exécution du workflow et accéder à l’utilisateur
  • Exemple : un agent de traduction appelle comme outils des agents espagnol, français et italien

• Pattern décentralisé (handoff entre agents)

  • Un agent transfère l’exécution du workflow à un autre agent via une transition unidirectionnelle de type handoff
  • Dans l’Agents SDK, un handoff est un type d’outil ou de fonction ; lorsqu’une fonction de handoff est appelée, l’état de conversation le plus récent est transmis et le nouvel agent commence immédiatement son exécution
  • Ce pattern est optimal lorsqu’il n’est pas nécessaire qu’un agent unique conserve le contrôle central ou fasse la synthèse, et que chaque agent peut reprendre l’exécution puis interagir directement avec l’utilisateur
  • Exemple : un agent de triage évalue la requête utilisateur et la route vers un agent de support technique, de vente ou de gestion des commandes

• Graphes déclaratifs vs non déclaratifs

  • Certains frameworks exigent, de manière déclarative (declarative), de prédéfinir toutes les branches, boucles et conditions sous forme de graphe composé de nœuds (agents) et d’arêtes (handoffs) — cela offre de la clarté visuelle, mais devient fastidieux lorsque le workflow est dynamique et complexe, et demande d’apprendre un langage spécifique au domaine
  • L’Agents SDK adopte une approche code-first, qui permet d’exprimer directement la logique du workflow à l’aide de structures de programmation familières, et rend possible une orchestration d’agents plus dynamique et adaptable sans définir tout le graphe à l’avance

Garde-fous

• Rôle des garde-fous

  • Ils aident à gérer les risques liés à la confidentialité des données (ex. : empêcher la fuite du prompt système) et les risques réputationnels (ex. : imposer un comportement du modèle conforme à la marque)
  • Un seul garde-fou ne suffit généralement pas à assurer une protection adéquate ; il faut combiner plusieurs garde-fous spécialisés pour construire des agents plus résilients
  • Les garde-fous sont un composant important, mais doivent être combinés à des protocoles d’authentification et d’autorisation robustes, à des contrôles d’accès stricts et à des mesures de sécurité logicielle standard

• Types de garde-fous

  • classificateur de pertinence (Relevance classifier) : vérifie que la réponse de l’agent reste dans le périmètre prévu et signale les requêtes hors sujet (ex. : « Quelle est la hauteur de l’Empire State Building ? » serait marquée comme hors sujet)
  • classificateur de sécurité (Safety classifier) : détecte les entrées dangereuses comme les jailbreaks ou prompt injections cherchant à exploiter des vulnérabilités du système
  • filtre PII : évite l’exposition inutile d’informations personnellement identifiables (PII) dans les sorties du modèle
  • modération (Moderation) : signale les entrées nuisibles ou inappropriées, comme les discours haineux, le harcèlement ou la violence
  • protections des outils (Tool safeguards) : attribuent à chaque outil un niveau de risque faible/moyen/élevé selon des critères comme accès en lecture seule vs écriture, réversibilité, permissions de compte requises et impact financier, puis déclenchent des actions automatisées telles qu’une pause pour vérification des garde-fous ou une escalade vers un humain avant l’exécution de fonctions à haut risque
  • protections fondées sur des règles (Rules-based protections) : mesures déterministes simples comme listes de blocage, limites de longueur d’entrée et filtres regex pour prévenir des menaces connues comme des termes interdits ou l’injection SQL
  • validation des sorties (Output validation) : vérifie, via prompt engineering et inspection du contenu, que les réponses sont conformes aux valeurs de la marque

• Approche de construction des garde-fous

  • Commencer par les garde-fous qui répondent aux risques déjà identifiés, puis ajouter des couches supplémentaires à mesure que de nouvelles vulnérabilités sont découvertes
  • Heuristiques efficaces :
    • se concentrer sur la confidentialité des données et la sécurité du contenu
    • ajouter de nouveaux garde-fous à partir de cas limites réels et d’exemples d’échec
    • ajuster les garde-fous à mesure que l’agent évolue, en optimisant à la fois la sécurité et l’expérience utilisateur
  • Dans l’Agents SDK, les garde-fous sont traités comme un concept de premier plan (first-class concept) et utilisent par défaut une exécution optimiste (optimistic execution) — l’agent de base produit proactivement une sortie pendant que les garde-fous s’exécutent en parallèle, puis une exception est déclenchée en cas de violation des contraintes

• Planifier l’intervention humaine

  • L’intervention humaine est une protection essentielle qui peut améliorer les performances réelles de l’agent sans dégrader l’expérience utilisateur
  • Elle est particulièrement importante au début du déploiement, car elle aide à identifier les échecs, découvrir les cas limites et établir un cycle d’évaluation robuste
  • Deux principaux déclencheurs justifient une intervention humaine :
    • dépassement d’un seuil d’échec : fixer des limites sur les nouvelles tentatives ou les actions de l’agent, puis escalader vers un humain en cas de dépassement (ex. : incapacité à comprendre l’intention du client après plusieurs essais)
    • actions à haut risque : les actions sensibles, irréversibles ou à fort enjeu (ex. : annuler la commande d’un utilisateur, approuver un remboursement important, traiter un paiement) nécessitent une supervision humaine tant que le niveau de confiance dans l’agent n’est pas suffisamment élevé

Conclusion

• Les agents ouvrent une nouvelle ère de l’automatisation des workflows : ils raisonnent face à l’ambiguïté, agissent via des outils et prennent en charge des tâches en plusieurs étapes avec une grande autonomie
• Contrairement aux applications LLM simples, les agents exécutent des workflows de bout en bout, ce qui les rend adaptés à la prise de décision complexe, aux données non structurées et aux systèmes à règles fragiles
• Pour construire des agents fiables, il faut combiner un modèle performant, des outils bien définis et des instructions claires et structurées, en utilisant un pattern d’orchestration adapté au niveau de complexité, tout en commençant par un agent unique et en n’évoluant vers le multi-agent qu’en cas de besoin
• Les garde-fous sont importants à chaque étape, du filtrage des entrées à l’usage des outils et à l’intervention humaine, afin de garantir que les agents fonctionnent en production de manière sûre et prévisible
• Un déploiement réussi n’est pas une démarche tout ou rien : il repose sur une approche itérative consistant à démarrer petit, valider avec de vrais utilisateurs et faire croître les capacités au fil du temps

• Également disponible en PDF