Une démo de Gen AI peut donner l’impression que les agents IA sont d’une simplicité trompeuse. On pose une question, on connecte quelques outils, on obtient une réponse intelligente, et l’architecture semble soudainement presque réglée. En réalité, la démo est souvent la partie la plus simple du parcours.

Les projets Gen AI les plus solides commencent lorsque les équipes techniques se demandent ce qui se passe après le prototype. Combien de contexte l’agent devrait-il conserver? Comment devrait-il gérer la mémoire au fil du temps? Le système devrait-il s’appuyer sur un seul agent ou sur plusieurs agents spécialisés? Que se passe-t-il lorsqu’un agent a accès aux données de l’entreprise, aux ressources AWS ou à des outils internes? Comment l’empêcher d’exécuter une action qu’il ne devrait jamais effectuer?

Ce sont les types de questions qui ont été soulevées lors d’un récent meetup Gen AI organisé par Unicorne. Elles se sont démarquées parce qu’elles étaient concrètes. Il ne s’agissait pas de courir après le cas d’utilisation le plus impressionnant. Il s’agissait de comprendre ce qu’il faut réellement pour concevoir un agent IA pouvant être déployé, surveillé, sécurisé et maintenu dans un environnement réel.

Pour les équipes qui construisent sur AWS, ce changement de perspective est important. Les agents IA dépassent de plus en plus le stade de l’expérimentation, mais la capacité à passer en production dépend de décisions faciles à sous-estimer au départ. La mémoire, l’orchestration, l’état partagé, les garde-fous et les permissions influencent tous la fiabilité du système une fois que de vrais utilisateurs et de vrais workflows entrent en jeu.

Définir tôt la stratégie de mémoire de l’agent

La mémoire est l’une des premières décisions de conception qui peuvent faire réussir ou échouer un agent IA. Dans un chatbot de base, la mémoire peut simplement consister à conserver assez de contexte pour suivre la conversation en cours. Dans un agent de production, la mémoire devient plus complexe, car le système peut devoir comprendre le rôle d’un utilisateur, retenir ses préférences, reconnaître des situations récurrentes, résumer des interactions précédentes et récupérer des détails importants plus tard sans transporter tout l’historique à chaque fois.

La mémoire à court terme aide l’agent à rester cohérent pendant l’échange en cours. Elle permet au système de suivre ce que l’utilisateur vient de demander, ce qui a déjà été répondu et ce qui reste à faire. La mémoire à long terme joue un rôle différent. Elle permet à l’agent de conserver des informations qui peuvent rester utiles d’une session à l’autre, comme des préférences utilisateur, des règles d’affaires, du contexte lié à un compte ou des workflows récurrents.

D’autres formes de mémoire peuvent aussi jouer un rôle important. La mémoire épisodique permet de capturer des moments clés d’une interaction, comme une correction de l’utilisateur, une exception, une décision ou une contrainte d’affaires précise. La mémoire de synthèse rend les historiques plus longs plus faciles à gérer en comprimant les échanges précédents dans un contexte utilisable. La mémoire sémantique extrait les détails importants et les stocke de manière à ce que le système puisse les récupérer au bon moment.

Ce n’est pas seulement une question d’expérience utilisateur. La mémoire a un impact sur les coûts, la performance, la confidentialité, la gouvernance et la qualité des décisions de l’agent. Trop peu de contexte peut rendre l’agent frustrant. Trop de contexte peut créer des risques et des coûts inutiles. Les équipes de production doivent déterminer quelles informations doivent être conservées, pendant combien de temps, comment elles doivent être récupérées et ce qui ne doit jamais être mémorisé.

Éviter de construire trop tôt un agent monolithique

Il peut être tentant de concevoir un grand agent capable de gérer toutes les demandes. Sur papier, cela semble efficace : une seule interface, un seul agent, un seul point d’entrée pour les utilisateurs. En pratique, un agent monolithique peut devenir difficile à tester, à contrôler et à améliorer dès que les cas d’utilisation se multiplient.

Une approche plus durable consiste à commencer avec des agents plus petits, chacun centré sur un problème d’affaires précis. Un agent peut récupérer de la documentation. Un autre peut analyser une infrastructure cloud. Un autre peut qualifier une demande. Un autre peut préparer une recommandation ou résumer des résultats. Chaque agent a un rôle plus étroit, ce qui facilite l’évaluation de sa performance.

Cette approche se rapproche de la logique des microservices. Plutôt que de regrouper toutes les responsabilités dans un seul grand système, les équipes définissent de plus petits composants avec des rôles plus clairs. Chaque agent peut être pris en charge, testé, mis à jour et surveillé plus facilement. Si une partie du système doit être améliorée, toute l’architecture n’a pas besoin d’être repensée.

À mesure que le cas d’utilisation mûrit, ces agents spécialisés peuvent être connectés par un orchestrateur ou intégrés dans une architecture multi-agents plus large. Cela donne aux équipes plus de flexibilité sans perdre le contrôle. Pour les organisations qui passent de l’expérimentation à la production, c’est souvent l’approche la plus pratique : commencer par un agent ciblé qui règle un problème d’affaires clair, puis élargir le système lorsque les bases sont fiables.

Décider comment l’état sera partagé entre les agents

Dans un système multi-agents, la gestion de l’état devient rapidement une décision architecturale centrale. Si plusieurs agents participent à l’exécution d’une tâche, le système doit suivre ce qui a déjà été fait, quelles informations ont été recueillies, quels outils ont été appelés et ce qui reste à accomplir.

Certaines architectures permettent de partager l’état entre les agents. Les modèles de type swarm, graph ou workflow peuvent rendre la collaboration plus fluide, car les agents travaillent à partir d’un contexte commun. Cela peut être utile pour les tâches complexes où différents agents doivent accéder aux mêmes informations pour accomplir leur partie du processus.

Cependant, l’état partagé augmente aussi le besoin de contrôle. Tous les agents n’ont pas besoin d’accéder à tout le contexte. Tous les sous-agents ne devraient pas avoir les mêmes permissions. Partager l’état trop largement peut créer une exposition inutile, surtout lorsque le système touche à des données sensibles, à des informations de compte ou à des outils opérationnels.

Un modèle avec orchestrateur offre une structure différente. Dans cette approche, l’orchestrateur maintient la vue globale et contrôle ce que chaque agent reçoit. Les sous-agents ne partagent pas nécessairement tout l’état entre eux. Ils reçoivent le contexte requis pour accomplir leur tâche, retournent leur résultat, puis laissent l’orchestrateur décider de la suite.

Les deux modèles peuvent fonctionner, mais ils répondent à des priorités différentes. Les architectures à état partagé peuvent être utiles lorsque la collaboration et la flexibilité sont prioritaires. Les architectures orchestrées peuvent mieux convenir aux environnements où la gouvernance, la traçabilité et les permissions doivent être gérées de façon plus stricte. L’important est de faire ce choix volontairement, plutôt que de laisser la topologie se construire par accident.

Traiter les garde-fous comme une partie intégrante de l’architecture

Les garde-fous sont souvent abordés tard dans le processus, une fois que l’agent fonctionne déjà. Cela crée des problèmes. Si un agent peut récupérer des données, appeler des outils, déclencher des workflows ou générer des recommandations, les limites entourant ce comportement doivent être conçues dès le départ.

Avec des frameworks comme Strands, les garde-fous peuvent être intégrés par l’intermédiaire d’un système de plugins. Cela permet aux équipes de connecter des outils comme LLM Guard ou NeMo Guardrails au cycle de vie du modèle sans intégrer tous les contrôles directement dans la logique d’affaires. Les garde-fous peuvent également être configurés avec AWS Bedrock Guardrails lorsqu’un modèle AWS Bedrock est utilisé. Cette séparation est utile, car elle garde la fonction principale de l’agent plus propre tout en permettant aux contrôles de sécurité et de validation d’évoluer avec le temps.

Les garde-fous peuvent être appliqués avant l’appel au modèle. À cette étape, le système peut inspecter la demande de l’utilisateur, détecter les tentatives de contournement des instructions, filtrer le contenu non sécuritaire ou bloquer les demandes qui dépassent le périmètre approuvé de l’agent. Les garde-fous peuvent aussi être appliqués après la réponse du modèle, ce qui permet au système de valider le résultat avant qu’il ne soit transmis à l’utilisateur ou qu’il ne déclenche une autre action.

Cette approche en deux temps est importante en production, car les risques liés aux entrées et aux sorties ne sont pas les mêmes. Un utilisateur peut soumettre une demande problématique, mais un modèle peut aussi produire une réponse problématique même lorsque l’entrée semble inoffensive. En plaçant des contrôles à différents points du cycle de vie du modèle, les équipes réduisent la probabilité de comportements non sécuritaires, non autorisés ou non conformes.

L’avantage d’une approche fondée sur les plugins est que les garde-fous restent découplés de la logique d’affaires. Les équipes peuvent renforcer les contrôles, adapter les politiques et ajouter des couches de validation sans reconstruire tout l’agent. Pour les entreprises dont les cas d’utilisation IA sont appelés à évoluer, cette flexibilité devient rapidement importante.

Construire la sécurité en couches

La sécurité des agents IA ne peut pas dépendre d’un seul mécanisme. Un système prêt pour la production a besoin de plusieurs couches de contrôle, chacune couvrant des risques que les autres ne peuvent pas entièrement gérer.

La première couche est le modèle lui-même. Les LLM modernes comprennent des mécanismes de protection intégrés qui aident à réduire les comportements nuisibles et à produire des réponses plus sécuritaires. Ces protections sont utiles, mais elles ne devraient jamais être considérées comme la seule ligne de défense.

Le prompt système ajoute une autre couche en définissant le rôle, les limites et les règles de fonctionnement de l’agent. Par exemple, un agent peut recevoir l’instruction de ne pas modifier des comptes AWS par l’intermédiaire du CLI ou de ne pas exécuter d’actions destructrices dans un environnement de production. Cela aide à guider le comportement, mais cela demeure une instruction. Le modèle se fait dire ce qu’il ne doit pas faire; le système ne l’empêche pas encore de le faire.

Les garde-fous ajoutent un contrôle plus solide en filtrant et en validant les entrées et les sorties. Des outils comme Amazon Bedrock Guardrails, LLM Guard ou NeMo Guardrails peuvent aider à appliquer des politiques au niveau de l’application et à réduire les comportements indésirables. Lorsqu’un modèle AWS Bedrock est utilisé, les garde-fous peuvent également être configurés avec Amazon Bedrock Guardrails. Ces contrôles sont importants parce qu’ils créent des frontières supplémentaires autour du comportement du modèle, mais ils ne remplacent pas les contrôles de sécurité stricts.

Les systèmes de production ont aussi besoin d’une sécurité déterministe. Cela signifie utiliser des contrôles au niveau du code qui ne dépendent pas du jugement du modèle. Le système peut valider un JWT, vérifier les permissions de l’utilisateur, restreindre les appels d’outils, bloquer certaines actions selon le contexte ou exiger une approbation avant l’exécution. Ces contrôles de politiques peuvent aussi être mis en œuvre par des plugins ou des hooks, ce qui peut rendre l’architecture plus composable et plus facile à maintenir.

L’approbation humaine constitue une autre couche importante lorsqu’un agent peut modifier un système. Toute mutation devrait être traitée différemment d’une action en lecture seule. Si un agent s’apprête à modifier une infrastructure, mettre à jour une configuration, modifier un compte, supprimer une ressource, déclencher un déploiement ou exécuter une autre action opérationnelle, le système peut exiger une approbation humaine avant que le changement soit appliqué. Cela crée une séparation claire entre la recommandation et l’exécution. L’agent peut proposer l’action, mais une personne approuve la mutation.

Le principe du moindre privilège devrait aussi être appliqué aux rôles AWS IAM. Le rôle IAM de l’agent IA devrait inclure uniquement les permissions nécessaires à l’exécution de ses tâches. Dans de nombreux cas, l’accès en lecture seule est le point de départ le plus sécuritaire. Si un agent n’a pas besoin de supprimer une base de données, de modifier un compte ou de changer une infrastructure, ces permissions ne devraient pas exister.

C’est l’une des différences les plus claires entre une démo et un système de production. Un prompt peut dire à un agent de ne pas faire quelque chose. Les garde-fous peuvent aider à contrôler ce qui entre et sort du modèle. Les contrôles déterministes, les permissions IAM et les workflows d’approbation humaine peuvent empêcher l’action de se produire dès le départ.

Tester les agents avant leur arrivée en production

Les contrôles de sécurité ne sont qu’une partie de la préparation à la production. Les équipes ont aussi besoin d’une façon d’évaluer si un agent IA se comporte comme prévu avant de l’exposer à de vrais utilisateurs ou à des systèmes opérationnels.

Cela signifie intégrer le QA au cycle de vie de l’agent. Avec Strands, les équipes peuvent utiliser QA Evaluation pour créer des pipelines de tests pour leurs agents IA. Ces tests peuvent aider à valider la façon dont l’agent répond à des scénarios courants, à des cas limites, à des demandes sensibles sur le plan des politiques et à des prompts liés à des tâches précises avant le déploiement.

AgentCore Evaluations peut aussi soutenir l’évaluation continue une fois que l’agent est en fonction. En évaluant les réponses en temps réel, les équipes peuvent identifier où l’agent performe bien, où il doit être amélioré et où un ajustement futur pourrait être nécessaire.

C’est important parce que les agents ne sont pas des composants logiciels statiques. Leur comportement dépend des prompts, des outils, des permissions, du contexte, de la mémoire, des entrées utilisateur et des réponses du modèle. Un système prêt pour la production a besoin d’une façon répétable de tester ce comportement, pas seulement d’une révision ponctuelle avant le lancement.

Rendre les agents observables en production

Une fois qu’un agent est déployé, les équipes doivent aussi avoir de la visibilité sur ce qu’il fait.

L’observabilité permet de déboguer l’agent en production, de comprendre comment il utilise les outils, de suivre où les échecs surviennent et d’enquêter sur les comportements inattendus. Les logs, le monitoring et les traces donnent aux équipes l’information nécessaire pour voir comment les requêtes circulent dans le système et où un problème a pu commencer.

C’est particulièrement important pour les agents IA, car le chemin d’exécution n’est pas toujours linéaire. Un agent peut interpréter une demande, appeler un outil, récupérer du contexte, prendre une décision, appeler un autre service, puis générer une réponse. Sans observabilité, diagnostiquer ce flux peut vite devenir un exercice de devinettes.

OpenTelemetry peut aider à capturer les traces et à rendre le comportement de l’agent plus facile à inspecter entre les systèmes. Lorsqu’on utilise Strands avec AgentCore Observability, une grande partie de cette instrumentation est intégrée sans configuration supplémentaire, ce qui donne aux équipes une vue plus claire de l’activité de l’agent en production.

Pour les entreprises qui déploient des agents dans des environnements réels, l’observabilité n’est pas un extra. C’est ce qui permet aux équipes de surveiller la performance, de déboguer les problèmes et d’améliorer l’agent au fil du temps.

La préparation à la production commence par de meilleures décisions techniques

Les agents IA évoluent rapidement, mais les entreprises qui en tireront de la valeur ne seront pas celles qui passent du prototype au déploiement sans revoir les fondations. La démo prouve que l’interaction peut fonctionner. La production exige un système capable de gérer le contexte, les permissions, les erreurs, les cas limites et les règles d’affaires sans devenir imprévisible.

C’est là que l’architecture devient le véritable différenciateur. La mémoire ne peut pas être traitée comme une transcription infinie. Les systèmes multi-agents ont besoin d’une répartition claire des responsabilités et de l’état. Les garde-fous doivent être intégrés au cycle de vie du modèle, et non ajoutés après coup. La sécurité doit être appliquée par le code, les permissions et AWS IAM, pas seulement par des instructions dans un prompt.

Pour les équipes qui construisent sur AWS, les pièces sont là : Amazon Bedrock, Strands, les frameworks de garde-fous, les composants serverless et les permissions IAM fondées sur le moindre privilège peuvent tous soutenir des agents plus structurés, plus contrôlés et prêts pour la production. Mais les outils n’ont de valeur que s’ils sont assemblés avec rigueur.

La vraie valeur ne vient pas d’un agent qui répond bien une fois. Elle vient d’un système capable de le faire fonctionner de façon fiable, sécurisée et maîtrisée dans un contexte d’affaires réel.