Agent IA : concevoir une architecture prête pour la production

Pour concevoir l’architecture d’un agent IA, commencez par un seul agent capable d’examiner un dossier, de proposer une action et de s’arrêter pour demander une approbation. Appuyez-vous sur des offres existantes pour le modèle et l’infrastructure standard ; développez les règles métier, les limites d’autorisation et les preuves qui permettront de vérifier que le travail a été correctement réalisé.

Un agent de support devient utile lorsqu’il sait relier le message d’un client au bon compte, aux bonnes règles et à la bonne action. Il devient fiable lorsque l’application qui l’entoure peut expliquer ce qu’il a consulté, empêcher une modification non autorisée et reprendre le traitement après la défaillance d’un outil.

Imaginez un réseau de transport. Le modèle choisit l’itinéraire, les outils desservent les destinations, la mémoire conserve le parcours et l’orchestration gère la circulation. Les garde-fous et les points d’approbation contrôlent les accès ; l’évaluation et les journaux indiquent si les voyageurs sont arrivés au bon endroit.

Les descriptions des composants ci-dessous ont été vérifiées dans les ressources d’Anthropic, d’OpenAI et de Google Cloud, ainsi que dans la spécification du Model Context Protocol, le 25 octobre 2026. Le workflow de support est un exemple de conception, pas la description d’un système déployé chez un client.

Architecture d’un agent IA : ce qui relève de l’application

L’architecture définit ce que le modèle peut choisir et ce que l’application doit imposer. Cette frontière compte davantage que le nom du framework.

Le LLM augmenté d’Anthropic, un modèle de langage relié à des mécanismes de recherche d’information, à des outils et à une mémoire, constitue un point de départ utile. Anthropic distingue le workflow, dont le parcours est défini dans le code, de l’agent, qui choisit ses prochaines actions de façon dynamique. Sa recommandation : n’ajouter de la complexité que lorsque la tâche l’exige. Les recommandations d’Anthropic sur les agents

Pour qualifier une demande de support, le modèle peut décider de consulter un guide de dépannage ou d’examiner une commande. Le code de l’application doit néanmoins déterminer les données de quel client il peut lire, si le remboursement proposé est autorisé et ce qui se passe si l’exécution s’interrompt en cours de route.

Gardez un traitement déterministe pour les opérations prévisibles. Authentifier un compte, vérifier des droits d’accès ou enregistrer une action terminée ne nécessite pas qu’un agent improvise. Confiez au modèle la partie incertaine : comprendre le message, sélectionner les éléments pertinents et proposer une prochaine étape utile.

Schéma d’architecture d’un agent IA : les couches et leurs connexions

Un agent a besoin d’une boucle contrôlée, entourée d’un état persistant et de vérifications. Les couches ci-dessous correspondent à des responsabilités ; chacune n’exige pas un service ou un abonnement distinct.

Lisez ces connexions comme une boucle : l’application assemble le contexte, le modèle demande une action, l’environnement d’exécution la vérifie puis l’exécute, et le résultat rejoint le contexte de la décision suivante. Le guide de la boucle d’agent détaille ce cycle et ses conditions d’arrêt.

Modèle : comprendre le dossier et proposer la prochaine action

OpenAI Agents SDK, la bibliothèque d’OpenAI pour créer des workflows d’agents, regroupe un modèle, des instructions et des outils dans un Agent ; le modèle interprète le ticket et propose la suite à donner. Dans cet exemple, il reçoit un problème d’accès au compte et demande les droits d’accès correspondants avant de rédiger une réponse. Choisissez le modèle en l’évaluant sur des cas de support représentatifs : une formulation élégante ne prouve ni que l’outil choisi est le bon, ni que l’agent est autorisé à agir. Définir un agent avec OpenAI

Outils et MCP : accéder aux systèmes métier

Model Context Protocol (MCP), une interface standard entre les applications d’IA et des capacités externes, définit des outils nommés avec un inputSchema, leur découverte par tools/list et leur appel par tools/call. La consultation d’un compte peut passer par MCP ou par une fonction classique qui appelle une API métier ; dans les deux cas, le service sous-jacent doit valider les arguments et limiter l’accès au bon compte. MCP standardise la connexion ; le guide pour comprendre MCP présente le protocole et ses frontières de confiance. Spécification des outils MCP

Mémoire : conserver le contexte pertinent

Agent Development Kit (ADK), le framework de Google pour créer des agents, utilise Session et state pour les informations propres à une interaction. Il prend aussi en charge une mémoire entre sessions grâce à des composants comme Memory Bank. Pour le support, conservez le dossier en cours et l’approbation en attente dans le stockage de l’application, récupérez les données actuelles du compte à leur source et ne retenez les préférences du client que lorsque cela se justifie. Ce sont des fonctions distinctes ; le guide de la mémoire des agents explique le contexte, le stockage de session et la mémoire à plus long terme. Recommandations d’architecture de Google Cloud

Orchestration : gérer l’avancement, les pauses et la reprise

Le guide de création d’agents d’OpenAI présente Agents SDK comme un moyen de gérer la boucle d’appels d’outils, les transferts entre agents et les garde-fous. Votre application dispose ainsi d’un moteur d’exécution pour les tâches pilotées par le modèle. Autour de ce moteur, enregistrez durablement l’état du ticket — investigation, attente de validation, exécution ou traitement terminé — afin qu’un processus redémarré puisse reprendre le dossier. Le guide de l’orchestration explique comment les exécutions d’agents s’inscrivent dans un processus métier plus long. Guide des agents d’OpenAI

Garde-fous et approbation humaine : maîtriser les conséquences

OpenAI Agents SDK distingue les garde-fous automatiques des interruptions pour approbation, qui suspendent un appel d’outil et renvoient un état permettant la reprise. Pour l’agent de support, validez automatiquement l’accès au compte et les arguments proposés, puis exigez qu’une personne habilitée approuve toute modification sensible avant son exécution. Placez le contrôle au niveau de l’outil qui réalise l’action ; le guide des garde-fous détaille ces vérifications. Garde-fous et validation humaine avec OpenAI

Évaluation et observabilité : reconstituer les faits et juger le résultat

Le traçage d’OpenAI Agents SDK enregistre les appels au modèle, les appels d’outils, les transferts entre agents et l’activité des garde-fous. Les recommandations d’OpenAI sur la notation des traces expliquent comment évaluer le comportement d’un workflow selon des critères explicites. L’observabilité montre le déroulement du traitement d’un ticket ; l’évaluation vérifie si l’agent a sélectionné le bon compte, respecté les règles et produit une réponse étayée. Définissez ce que vous collectez et combien de temps vous le conservez avant de comparer les outils d’observabilité des LLM. Traçage du SDK, évaluation des agents

L’architecture de référence de Google Cloud assemble ADK, Cloud Run, l’accès aux modèles, les connexions MCP, Model Armor et l’observabilité dans un déploiement concret. L’exemple documenté exclut explicitement la mémoire et le stockage des sessions du schéma : la persistance de l’état des dossiers reste donc un choix de conception, pas une fonction à considérer comme incluse. Architecture de référence

Du ticket reçu à la réponse qui résout le problème

Confiez à l’agent un dossier au périmètre défini, dont la résolution peut être constatée. Dans cet exemple, un client indique avoir payé son accès sans pouvoir utiliser le service. L’agent peut examiner la situation et préparer une correction ; lors du déploiement initial, un responsable du support approuve les modifications du compte et la réponse à envoyer.

Les noms d’outils ci-dessous désignent des fonctions de l’application que vous auriez à développer, pas une intégration de support prête à l’emploi fournie par un éditeur.

1. 1

   Recevoir et identifier le dossier

   Le webhook du ticket, un événement envoyé par le système de support, crée ou reprend un dossier à partir de l’identifiant externe du ticket. Authentifiez le client par le parcours de connexion existant ; une adresse e-mail saisie dans le message ne doit pas suffire à donner accès à un compte. Enregistrez le message reçu comme un contenu client non fiable.

2. 2

   Recueillir les éléments utiles avec des outils au périmètre restreint

   Donnez à l’agent des capacités telles que get_account_entitlement et search_support_policy. Dans le code de l’application, liez l’accès au compte à l’identité authentifiée et renvoyez les données pertinentes ainsi que la référence aux règles applicables. Le modèle peut choisir les éléments à demander sans disposer d’un accès illimité à la base de données.

3. 3

   Préparer une proposition étayée

   Le modèle confronte le problème décrit par le client aux données du compte et aux règles applicables. Si les éléments recueillis justifient une correction des droits d’accès, il rédige la modification proposée et la réponse ; si ces éléments manquent ou se contredisent, il demande des précisions ou transmet le dossier à un niveau de prise en charge supérieur. Conservez leurs références avec la proposition pour que la personne chargée de la validation puisse en examiner le fondement.

4. 4

   Suspendre le traitement avant l’action métier

   Vérifiez que l’opération proposée respecte les règles, puis enregistrez l’action en attente et l’état de son approbation. Présentez au responsable du support le compte concerné, la modification exacte, les éléments qui la justifient et la réponse destinée au client. Un refus maintient le blocage de l’écriture et renvoie le dossier pour révision ou traitement manuel.

5. 5

   Exécuter l’action et vérifier le résultat

   Après approbation, vérifiez à nouveau que le compte et la proposition correspondent toujours à ce qui a été examiné, puis appelez l’outil de correction. Utilisez une clé d’idempotence, un identifiant qui empêche d’appliquer à nouveau la même opération lors d’une nouvelle tentative, lorsque le service sous-jacent le permet. Confirmez les droits d’accès obtenus avant d’envoyer une réponse annonçant leur rétablissement ; enregistrez le résultat de l’envoi avant de marquer le dossier comme terminé.

6. 6

   Alimenter l’évaluation avec le résultat du dossier

   Reliez à la trace le résultat de l’exécution, la réponse approuvée et l’état final du dossier. Transmettez les résultats incertains à une personne plutôt que d’interpréter un dépassement de délai comme un succès ou un échec. Lorsqu’une vérification révèle une erreur, conservez un exemple dont les données sensibles ont été masquées de façon appropriée dans le jeu d’évaluation.

Le risque majeur est une écriture dont le résultat reste incertain : le service de gestion des comptes peut avoir appliqué la modification sans que votre application ait reçu sa réponse. Vérifiez l’état dans le système source avant de réessayer. Une transcription indiquant « Je vais rétablir l’accès » prouve une intention, pas que les droits ont changé.

Architectures d’agents IA : quand ajouter un spécialiste ?

Conservez un seul agent tant que la tâche relève d’un ensemble cohérent de règles, d’outils et d’un même responsable. Ajoutez un spécialiste lorsqu’il répond à un besoin de séparation démontrable, puis vérifiez que le gain résiste au surcroît de coordination.

OpenAI distingue les transferts de prise en charge, où un spécialiste reprend la conversation, des agents utilisés comme outils, où l’agent principal appelle un spécialiste tout en restant responsable de la réponse. Ses recommandations préconisent de séparer les agents lorsque leurs instructions, leurs capacités ou leurs règles diffèrent sensiblement. Orchestration et transferts entre agents

Dans notre cas de support, rechercher un article d’aide et rédiger une réponse ne justifie pas automatiquement des agents distincts. Un litige de facturation peut le justifier : il peut relever d’autres règles, d’outils financiers à accès restreint et d’une autre personne chargée de la validation. Vous pouvez appeler ce spécialiste pour une analyse circonscrite tout en laissant le dossier sous la responsabilité de l’agent de support, ou lui transférer explicitement cette responsabilité lorsque le workflow de facturation doit prendre le relais.

Schéma d’un système multi-agents : séparer les responsabilités

Des règles différentes constituent un motif utile de séparation, pas une condition universelle. Des tâches distinctes de collecte d’informations peuvent aussi justifier des agents travaillant en parallèle, mais seulement si le responsable final peut résoudre les contradictions entre leurs résultats et si le bénéfice observé justifie le travail supplémentaire du modèle.

Avant d’ajouter un spécialiste, décrivez l’échec qu’il doit corriger : mauvais choix d’outil, instructions contradictoires, contexte trop volumineux ou expertise manquante. Comparez la nouvelle architecture sur les mêmes cas, y compris les cas d’échec. Ne la conservez que si le résultat s’améliore suffisamment pour justifier le surcroît de latence, de consommation, de débogage et de vérification ; c’est une règle de décision, pas une promesse de performance.

Baptiser les agents « chercheur », « critique » et « responsable » ne leur confère pas un jugement indépendant. S’ils s’appuient sur les mêmes éléments erronés, leur accord peut simplement reproduire l’erreur. Pour une classification plus large, consultez le panorama des types d’agents IA.

Système d’agent IA : quels composants acheter, quelles responsabilités garder ?

Achetez les composants interchangeables et gardez la maîtrise des engagements métier. Pour un premier agent en production, la meilleure raison de développer un composant vous-même est que votre workflow exige un comportement que les solutions disponibles ne permettent ni d’exprimer ni d’observer.

Pour les fondateurs : choisissez un produit d’agent managé s’il prend en charge votre workflow réel, vos points d’approbation et l’export des éléments de preuve. Construisez votre solution autour de composants standard lorsque les règles propres à chaque compte ou le comportement des intégrations font votre différence. Une démonstration convaincante ne suffit pas si vous ne pouvez ni reprendre un dossier suspendu ni examiner une action échouée.

Pour les CTO et les équipes de développement : donnez aux outils métier un périmètre restreint et rendez-les testables indépendamment du modèle. Un environnement d’exécution managé peut héberger l’application ; il ne peut pas déduire la différence entre un client qui demande un remboursement et un salarié autorisé à l’accorder. Définissez cette distinction dans le service qui réalise l’opération.

Pour les responsables des opérations : prenez en charge la file des exceptions et la définition d’un dossier résolu. Précisez qui reprend un dossier non résolu, quels éléments lui sont transmis et à quel moment le ticket peut être fermé. Une file de demandes d’approbation que personne ne consulte laisse le workflow inachevé.

L’exécution de code est facultative pour cet agent de support. Si une tâche ultérieure nécessite d’exécuter du code généré, traitez son isolation comme une décision distincte et consultez le guide des environnements isolés pour le code des agents ; n’introduisez pas un shell généraliste simplement pour consulter un compte.

Où placer l’approbation humaine et que journaliser dès le départ ?

Placez l’approbation juste avant l’action qui nécessite une délégation d’autorité. Relire le texte de l’agent après la modification d’un compte ne peut pas empêcher cette modification.

Le mécanisme d’approbation d’OpenAI renvoie une exécution suspendue et un état permettant de la reprendre ; votre application tranche la décision en attente, puis relance l’exécution. La même documentation précise que les contrôles d’entrée et de sortie au niveau de l’agent n’encadrent pas chaque appel d’outil intermédiaire. Le point où l’action est exécutée doit donc disposer de sa propre validation. Cycle d’approbation et limites des contrôles du workflow

Dans cet exemple de déploiement, la personne chargée de la validation voit ensemble la modification exacte du compte et la réponse. Si l’action, le destinataire ou les éléments qui la justifient changent après cet examen, exigez une nouvelle décision. Conservez qui a approuvé quoi, quelles règles s’appliquaient et si l’exécution correspondait à l’approbation.

Le schéma de journalisation suivant constitue un point de départ. Une trace relie les événements d’un même dossier ; un span enregistre une opération individuelle au sein de cette trace.

• Identité du dossier : identifiant du dossier, identifiant de trace, événement d’origine et référence du compte authentifié. Utilisez des références plutôt que de dupliquer partout les informations du client.
• Configuration : identifiant du modèle renvoyé par le fournisseur, version des instructions, version du schéma des outils et version des règles. Ces informations permettent de comprendre quel comportement était en vigueur.
• Éléments de preuve : identifiants des documents récupérés, révisions pertinentes et périmètre d’accès. Enregistrez ce qui a fondé la décision sans recopier indistinctement des données privées.
• Actions : nom de l’outil, arguments dont les données sensibles ont été masquées, horodatages, durée, état du résultat et identifiant de tentative ou d’idempotence. Conservez assez d’informations pour distinguer une action proposée d’une action réalisée.
• Décisions : résultats des validations, motif d’escalade, état de l’approbation, référence de la personne chargée de la validation et proposition approuvée.
• Résultat et consommation : état final du ticket, effets confirmés sur les systèmes, résultat de l’envoi, consommation déclarée par le fournisseur et étiquettes d’évaluation. Suivez les corrections apportées par les clients ou les dossiers rouverts lorsque le système de support expose ces informations.

Il s’agit d’un schéma applicatif recommandé, pas d’une promesse qu’un SDK collecte automatiquement chaque champ. Restreignez l’accès, fixez la durée de conservation et masquez les secrets avant l’export. N’exigez pas la journalisation du raisonnement interne du modèle ; la piste d’audit doit reposer sur les entrées, les sorties, les actions et les éléments de preuve observables.

Les limites à prendre au sérieux, au-delà des promesses

La limite la plus importante concerne l’autorité que vous déléguez. Fixez des plafonds explicites pour la durée d’exécution, l’activité des outils et la consommation de ressources, ainsi qu’un parcours d’escalade clair. Choisissez ces valeurs en fonction de votre charge de travail et de vos exigences de service, au lieu de reprendre une limite arbitraire vue dans une démonstration.

La mémoire n’est pas une source de vérité. Si une conversation enregistrée indique que le client dispose d’un accès et que le système de gestion des comptes dit le contraire, examinez l’écart à partir des données actuelles qui font autorité. Mémoriser davantage de texte ne corrige pas des informations périmées.

MCP ne vaut pas autorisation. Sa spécification des outils exige toujours des contrôles d’accès et une validation des entrées. Un connecteur qui expose une opération au périmètre large doit faire l’objet du même examen des autorisations métier qu’une API sur mesure. Exigences de sécurité de MCP

Une exécution terminée ne signifie pas qu’un dossier est résolu. Vérifiez si le bon compte a été modifié, si les règles ont été respectées et si la réponse correspond au résultat. Les recommandations d’OpenAI en matière d’évaluation passent de l’examen des traces à des jeux de données réutilisables, afin de juger les changements selon des critères constants. Évaluer les workflows d’agents

Multiplier les agents ne supprime pas le besoin d’un responsable. Quelqu’un doit répondre du résultat final, des éléments partagés et des exceptions non résolues. Un spécialiste est utile parce que sa responsabilité est différente, pas parce qu’il rend le schéma d’architecture plus sophistiqué.

Questions fréquentes sur l’architecture des agents IA

Qu’est-ce que l’architecture d’un agent IA ?

L’architecture d’un agent IA organise les décisions du modèle, les outils, la mémoire, l’orchestration, les contrôles et l’évaluation qui permettent à une application de mener une tâche. Pour un agent métier, elle détermine aussi qui peut autoriser les actions et comment leur réalisation est vérifiée.

Qu’est-ce qu’un agent intelligent ?

Un agent intelligent fondé sur l’IA utilise un modèle pour choisir des actions en fonction d’un objectif, observe leurs résultats et décide de la suite. Son autonomie utile est délimitée par les outils, les permissions et les règles d’arrêt fournis par l’application.

Quels sont les différents types d’architectures d’agents ?

Une distinction pratique consiste à séparer les workflows prédéfinis, les agents uniques qui choisissent parmi plusieurs outils et les spécialistes qui collaborent. Le bon choix dépend de la prévisibilité de la tâche et de la nécessité de confier des responsabilités différentes à des outils, des règles ou des responsables distincts. Il s’agit de modèles d’implémentation, pas d’une classification universelle.

Première étape : dessiner le parcours du dossier avant de choisir la stack

Commencez dès maintenant si vous disposez de demandes de support récurrentes, de données sources accessibles et d’une personne responsable des exceptions. Choisissez un dossier représentatif et indiquez l’événement d’entrée, les lectures autorisées, les écritures proposées, le point d’approbation et les preuves nécessaires à sa clôture. Faites d’abord fonctionner le workflow en mode brouillon et validation, puis utilisez les échecs observés pour décider quelles permissions peuvent être élargies de manière responsable.

Attendez avant de passer à l’exécution autonome si l’identité du compte, la responsabilité des règles ou les preuves de résolution restent à clarifier. Vous pouvez continuer à améliorer la recherche d’information et la qualité des brouillons tout en réglant ces prérequis. Si le workflow suit déjà des règles déterministes fiables et n’a pas besoin du jugement d’un modèle, conservez cette automatisation.

Le premier livrable doit être un dossier dont vous pouvez expliquer tout le parcours, de la réception au résultat, y compris ce qui se passe lorsque l’approbation est refusée ou que le résultat d’un outil est inconnu.

Pour recevoir des guides pratiques sur la création et l’exploitation de systèmes d’IA, abonnez-vous à la newsletter.