Modèles et routage
Claude sur Amazon Bedrock, avec un routage explicite : le modèle le plus capable là où la difficulté le justifie, un modèle plus rapide ailleurs. Les données restent dans la région choisie.
Agents IA sur AWS
Agents IA sur AWS : de la démo à la production
Un agent qui impressionne en démonstration et un agent qui tient en production ne sont pas le même objet. Le second suppose des accès maîtrisés, des outils cadrés, une évaluation avant mise en service et un coût mesuré. C'est ce socle que nous construisons, sur AWS.
01 Le constat
Pourquoi un agent qui marche en démo ne passe pas en production.
L'écart ne vient presque jamais du modèle. Il vient de tout ce qui l'entoure et qui n'existe pas encore le jour de la démonstration.
Des accès trop larges
En démonstration, l'agent tourne avec des droits d'administrateur. En production, il lui faut une identité propre, des permissions bornées et une trace de chaque action.
Des outils non cadrés
Brancher un agent sur de nombreux serveurs d'outils élargit la surface d'attaque. Il faut décider ce qui est en lecture seule, ce qui exige une validation, et ce qui reste interdit.
Aucune évaluation
Sans jeu de cas de référence ni critère de réussite explicite, personne ne peut dire si une nouvelle version de l'agent est meilleure ou moins bonne que la précédente.
Un coût non mesuré
Le coût d'un agent ne se lit pas sur une facture de modèle : il dépend du nombre d'appels, de la longueur du contexte et des relances. Sans mesure par cas d'usage, la note surprend à l'échelle.
02 Le socle
Ce que nous mettons en place sur AWS.
Six briques, assemblées selon votre contexte. Elles vivent dans vos comptes AWS : le socle vous reste, mission après mission.
Exécution et hébergement
Amazon Bedrock AgentCore pour exécuter les agents avec des sessions isolées, un déploiement reproductible et une intégration native au reste de votre compte AWS.
Identité et accès
Une identité IAM dédiée par agent, encadrée par une permissions boundary, et des accès cross-account explicites quand l'agent doit sortir de son compte d'origine.
Outils et connecteurs
Des connecteurs MCP vers vos systèmes existants (supervision, ITSM, CMDB, données métier), en lecture seule par défaut, avec séparation des domaines et permissions cadrées.
Évaluation
Un jeu de cas de référence et des critères de réussite définis avec vos équipes, rejoués à chaque version. Un agent ne passe en production que s'il les tient.
Observabilité et FinOps
Traçabilité de chaque action, registre des agents en service, suivi du coût réel par cas d'usage et de l'empreinte associée.
03 En production
Un cas réel : les agents du NOC d'Engie.
Une plateforme multi-agents sur Claude et Amazon Bedrock, adoptée par les équipes du centre de supervision réseau, avec une quinzaine de connecteurs vers l'écosystème existant.
- < 30 s
- pour trier une alerte, contre 10 à 15 minutes manuellement
- ≈ 50 %
- des incidents récurrents résolus de façon autonome
- ~ 2,5 ETP
- de charge récurrente absorbés, redéployés vers l'ingénierie
L'autonomie ne couvre que les cas déterministes et réversibles, validés par l'équipe. Sur les cas sensibles, l'humain reste dans la boucle.
Lire l'étude de cas complète 04 Publications
Ce que nous avons écrit sur le sujet.
Nos retours d'expérience techniques, en accès libre. Ils décrivent les décisions réelles prises sur des projets en production.
- 01 Amazon Bedrock AgentCore : faire passer vos agents IA en production Lire →
- 02 Déployer AgentCore sous une permissions boundary IAM Lire →
- 03 Accès cross-account à AgentCore : deux patterns Lire →
- 04 Architecture MCP en environnement régulé Lire →
- 05 Évaluer un agent IA avant la mise en production Lire →
- 06 FinOps pour l'IA agentique : mesurer le coût réel Lire →
- 07 Choisir entre plusieurs modèles Claude selon le cas d'usage Lire →
- 08 Construire un agent de triage NOC propulsé par Claude Lire →
05 Questions fréquentes
Ce qu'on nous demande sur les agents AWS.
Faut-il déjà être sur AWS pour travailler avec vous ?
C'est notre terrain principal et celui où nous allons le plus vite, parce que nous connaissons Bedrock, AgentCore et le modèle d'identité IAM en profondeur. Nous intervenons aussi dans des environnements hybrides ou multi-cloud, mais le socle que nous décrivons ici est celui que nous maîtrisons le mieux.
Quelle différence entre un agent et un simple chatbot ?
Un chatbot répond. Un agent agit : il interroge vos systèmes, corrèle des informations et exécute des actions. C'est précisément ce qui impose un cadre — identité dédiée, permissions bornées, traçabilité et réversibilité — qu'un chatbot ne réclame pas.
Comment garantissez-vous qu'un agent ne fera pas n'importe quoi ?
Par construction, pas par confiance. L'autonomie n'est accordée que sur des cas déterministes et réversibles, validés par vos équipes. Les outils sont en lecture seule par défaut. Chaque action est tracée. Et l'agent doit tenir un jeu de cas de référence avant d'être mis en service.
Combien coûte un agent en production ?
Cela dépend du volume d'appels, de la longueur du contexte et du modèle retenu, pas d'un forfait. Nous instrumentons le coût par cas d'usage dès le déploiement, précisément pour que la question ait une réponse chiffrée plutôt qu'une estimation.
Où sont hébergées les données ?
Dans la région AWS que vous choisissez, dans vos propres comptes. Sur le cas Engie, les données sont hébergées en Europe, avec accès privés, chiffrement et cloisonnement réseau conformes aux exigences du groupe.
Parlons-en
Vous voulez identifier les bons usages IA pour votre entreprise ?
En 30 minutes, nous qualifions vos priorités, identifions les premiers cas d'usage réalistes et définissons une trajectoire simple pour créer de la valeur mesurable. Décrivez votre contexte en quelques lignes.