KTern.AI a expliqué comment elle a reconstruit son logiciel de transformation SAP autour d’agents d’IA à long terme sur Amazon Bedrock AgentCore, offrant l’un des cas clients les plus clairs à ce jour sur la manière dont AWS souhaite que les entreprises déploient des systèmes d’agents en production plutôt que des fonctions de chat isolées.

Selon un billet du blog AWS Machine Learning coécrit avec l’entreprise, KTern.AI a utilisé Amazon Bedrock AgentCore et le SDK Strands Agents pour exécuter des agents spécialisés dans des tâches telles que le reverse engineering, le travail fit-to-standard, l’analyse de code et l’extraction d’exceptions dans les processus financiers et commerciaux. Le message est simple : au lieu de construire une infrastructure personnalisée pour l’orchestration, la mémoire, l’identité, l’accès aux outils et l’observabilité, KTern.AI affirme avoir déplacé ces fonctions vers des services gérés par AWS afin que ses propres équipes d’ingénierie puissent se concentrer sur des workflows spécifiques à SAP.

C’est important, car les projets de transformation SAP constituent un cas de test à forte valeur pour les systèmes agentiques. Ce sont des programmes de longue durée, lourds en documentation, sensibles aux processus, avec des exigences de sécurité strictes et beaucoup de travail de conseil humain coûteux. Si des agents IA peuvent y fonctionner de manière fiable, les fournisseurs cloud auront un argument plus solide pour dire que les agents d’entreprise dépassent le stade de la démonstration pour entrer dans le logiciel opérationnel.

Pourquoi KTern.AI a choisi AgentCore pour ses workflows SAP

Dans la version d’AWS, KTern.AI avait déjà développé une plateforme logicielle pour les migrations SAP S/4HANA, les conversions et les travaux plus larges de transformation numérique. La question n’était pas de savoir si l’IA générative pouvait aider sur quelques tâches, mais si l’entreprise pouvait prendre en charge de nombreux agents spécialisés sur des projets pouvant durer des mois, voire des années.

AWS et KTern.AI décrivent plusieurs exigences qui ont poussé l’entreprise à s’éloigner d’une pile autogérée : un contexte persistant au fil d’interactions répétées, un accès audit-able aux API SAP et aux systèmes clients, l’isolation des locataires, une mise à l’échelle élastique, et suffisamment de journalisation et de tracing pour déboguer le comportement multi-agents dans les environnements d’entreprise. Ce sont des points de friction courants pour les équipes qui tentent de passer de copilotes de preuve de concept à des agents IA de niveau production.

L’architecture publiée utilise Amazon Bedrock AgentCore Runtime pour héberger les agents, AgentCore memory pour conserver le contexte du projet dans le temps, AgentCore identity pour l’authentification et l’accès au moindre privilège, et AgentCore observability pour alimenter Amazon CloudWatch en logs, métriques et traces. Pour l’accès aux systèmes externes, les agents appellent des outils via la couche Model Context Protocol de la passerelle AgentCore. AWS indique que le trafic vers Amazon Bedrock et AgentCore peut rester hors d’Internet public grâce à AWS PrivateLink et aux points de terminaison d’interface VPC.

Selon le billet AWS, l’implémentation de KTern.AI repose également sur la configuration plutôt que sur du code d’orchestration personnalisé. Chaque agent est défini par des prompts, des liaisons d’outils et des modèles d’orchestration, l’entreprise utilisant des patterns du SDK Strands Agents tels que swarm, workflow et graph selon la charge de travail. C’est un détail architectural important : AWS ne propose pas seulement des modèles ici, mais aussi une couche gérée d’exécution et d’exploitation pour les systèmes d’agents.

AWS construit une histoire AgentCore plus large

Le cas KTern.AI n’apparaît pas de manière isolée. D’autres billets récents du blog AWS Machine Learning montrent un effort plus large pour positionner Amazon Bedrock AgentCore comme le plan de contrôle de production pour les agents d’entreprise.

Un billet explique comment construire une couche sémantique pour l’analytique agentique avec Stardog et Amazon Bedrock AgentCore. Dans cet exemple, AWS soutient que le défi central pour les agents d’entreprise n’est pas simplement de générer du SQL ou d’appeler un modèle, mais de raisonner de manière cohérente sur des données métier fragmentées. La réponse proposée est une couche de sens construite avec Stardog au-dessus de sources comme Amazon Aurora et Amazon Redshift, afin que les agents puissent interroger des concepts métier gouvernés plutôt que des systèmes bruts directement.

Cela importe pour l’histoire KTern.AI, car le travail de transformation SAP présente le même problème structurel. Les agents de longue durée ont besoin d’un contexte durable, d’un accès sécurisé aux systèmes et d’une compréhension métier partagée des processus, du code et des exceptions. Le message d’AWS dans les deux billets est cohérent : les modèles ne suffisent pas à eux seuls ; les agents en production ont besoin d’une infrastructure pour la mémoire, les outils, l’identité, la gouvernance et l’accès aux données.

Un autre billet AWS sur la sécurisation d’Amazon Bedrock AgentCore Runtime avec AWS WAF ajoute un indice sur les obstacles d’adoption perçus par AWS. Il se concentre sur le placement d’un Application Load Balancer exposé à Internet devant les endpoints AgentCore, le routage privé du trafic via un point de terminaison VPC, et la gestion des complications de health checks créées par l’authentification SigV4 et OAuth intégrée à AgentCore. Le fait qu’AWS publie des modèles détaillés pour l’intégration d’AWS WAF, Amazon Cognito et ALB suggère qu’il tente de lever les objections de sécurité des entreprises qui bloquent souvent le déploiement après le succès d’un pilote.

Ce que KTern.AI dit avoir obtenu

Les chiffres les plus marquants de ce dossier proviennent du billet de blog AWS de KTern.AI, et doivent être considérés comme des mesures de production rapportées par le fournisseur plutôt que comme des benchmarks vérifiés indépendamment.

Selon KTern.AI, ses agents ont réduit de 45 % les délais globaux des projets SAP, diminué de 60 à 70 % les travaux de découverte et d’évaluation, identifié de manière autonome 90 % des exceptions opérationnelles en finance et en ventes, et récupéré 480 heures d’ingénierie par mois sur les engagements de production. Le billet indique également que le premier agent de production pouvait être déployé en 4 à 6 heures sans aucun code d’orchestration personnalisé, contre 2 à 3 semaines par agent dans une configuration autogérée auparavant. AWS et KTern.AI rapportent en outre une réduction de 95 % du temps de mise en place de l’infrastructure et un taux de disponibilité soutenu des agents de 99,8 % sur les déploiements de production.

Ces chiffres peuvent être significatifs pour des acheteurs évaluant les agents IA dans le cadre de la transformation d’entreprise, mais les preuves fournies sont limitées. Le billet ne divulgue ni le nombre de clients, ni la méthodologie, ni les définitions de base, ni la répartition des projets, ni si les mesures proviennent d’un petit nombre d’engagements ou d’un large parc installé. Il ne sépare pas non plus les gains dus aux workflows des agents eux-mêmes de ceux dus au passage à une infrastructure AWS gérée.

Malgré ces réserves, les affirmations mettent en lumière le cas d’usage économique qu’AWS souhaite voir considérer par ses clients. Si le délai de livraison des agents passe de semaines à des heures, la proposition de valeur évolue de projets d’automatisation isolés vers des portefeuilles internes d’agents réutilisables.

Preuves, architecture et limites des affirmations

Les informations rapportées ici proviennent presque entièrement de sources contrôlées par AWS, notamment plusieurs billets du blog AWS Machine Learning et un article AWS Wire. Cela signifie que les détails architecturaux du produit sont utiles, mais que les résultats opérationnels doivent être abordés avec prudence.

Ce qui semble bien étayé par les sources, c’est la forme technique du système : KTern.AI a utilisé Amazon Bedrock AgentCore, le SDK Strands Agents, Amazon CloudWatch, AWS Lambda, Amazon S3, IAM et la connectivité privée via AWS PrivateLink. AWS décrit également clairement les modèles de déploiement associés pour AWS WAF, ALB et Amazon Cognito lorsque les équipes veulent placer des contrôles de pare-feu applicatif web devant AgentCore Runtime.

Ce qui est moins solidement étayé, c’est l’histoire de performance. Les chiffres de vitesse, d’effort, de disponibilité et de détection des exceptions sont attribués par AWS aux mesures internes de KTern.AI. Il n’y a ni audit tiers, ni témoignage client, ni méthodologie de benchmark dans les documents sources. La même prudence s’applique à l’affirmation plus large de l’entreprise selon laquelle sa plateforme permet des transformations 7 fois plus rapides et une réduction de 24 % de l’effort global.

Pour les lecteurs qui évaluent Amazon Bedrock AgentCore, la principale leçon n’est pas que ces pourcentages exacts sont généralisables, mais qu’AWS dispose désormais d’au moins une architecture de référence d’entreprise publique montrant comment des applications multi-agents peuvent être intégrées à des systèmes opérationnels sensibles avec un contexte persistant et un accès contrôlé aux outils.

Ce que cela signifie pour les développeurs et les acheteurs d’entreprise

Pour les développeurs IA, l’exemple KTern.AI renforce un schéma qui se précise dans l’IA d’entreprise : beaucoup des problèmes difficiles sont opérationnels, et non purement liés au modèle. La persistance des sessions, l’isolation des locataires, l’authentification des outils, le tracing et la connectivité gouvernée aux systèmes d’enregistrement déterminent souvent si les agents IA survivent au-delà d’une démo de laboratoire.

Pour les équipes produit, l’approche très axée configuration décrite avec Strands Agents SDK est notable. Si de nouveaux agents peuvent réellement être définis par des prompts, des liaisons d’outils et des modèles d’orchestration plutôt que par de nouvelles piles d’infrastructure, les équipes pourraient livrer des agents spécifiques à un domaine plus rapidement et avec moins de surcharge d’ingénierie de plateforme. C’est particulièrement pertinent dans les secteurs où les workflows sont répétables mais très contextuels, notamment la modernisation ERP, les opérations de conformité et l’analytique d’entreprise.

Pour les acheteurs d’entreprise, l’histoire est plus nuancée. D’un côté, Amazon Bedrock AgentCore ressemble de plus en plus à la réponse d’AWS à une question d’achat courante : qui gère les briques d’exécution banales mais essentielles pour les agents IA en production ? De l’autre, les acheteurs doivent encore vérifier si le confort managé compense le verrouillage fournisseur, si les contrôles AWS sont suffisants pour leur posture de sécurité, et si le comportement des agents est fiable dans des conditions réelles de programme plutôt que dans des exemples soigneusement sélectionnés.

Le contenu AWS autour de ce cas suggère également que le déploiement d’agents sur AWS entraînera souvent des services adjacents comme Amazon Aurora, Amazon Redshift, Stardog et Amazon Bedrock lui-même. En pratique, acheter un runtime d’agents peut signifier s’engager dans une architecture cloud plus large pour la mémoire, la gouvernance, la sécurité réseau et la médiation des données.

Ce qu’il faut surveiller ensuite

Le prochain signal à surveiller est de savoir si AWS publie davantage d’exemples clients tiers pour Amazon Bedrock AgentCore en dehors des billets de blog rédigés par les fournisseurs. Des études de cas indépendantes avec des bases de référence divulguées renforceraient l’idée que la plateforme gagne une vraie traction en production.

Un deuxième signal est de voir si AWS continue à étendre les contrôles d’entreprise autour d’AgentCore. Les récentes indications AWS WAF laissent entendre que la sécurité en frontal et l’inspection du trafic sont des préoccupations actives des clients. Davantage de modèles prêts à l’emploi pour l’auditabilité, l’application des politiques et les opérations multi-locataires rendraient Amazon Bedrock AgentCore plus crédible pour les charges de travail réglementées.

Troisièmement, il faut observer comment AWS relie AgentCore aux systèmes de données d’entreprise. L’exemple Stardog montre une voie via une couche sémantique au-dessus d’Amazon Aurora et d’Amazon Redshift. Si ce modèle se généralise, les plateformes d’agents pourraient être jugées moins sur le choix du modèle que sur la sécurité avec laquelle elles relient le sens métier aux systèmes en production.

Enfin, il vaut la peine de suivre si KTern.AI ou AWS fournit des preuves clients plus complètes. Des déploiements nommés, des méthodes plus claires et des signaux de rétention ou d’expansion diraient davantage au marché si cette architecture génère une valeur durable dans le travail de transformation SAP.

Perspective Creati.ai

Le cas d’étude KTern.AI soutenu par AWS est utile non pas parce qu’il prouve que l’IA agentique a résolu la transformation d’entreprise, mais parce qu’il montre où se déplace la vraie bataille des plateformes. Le différenciateur n’est plus seulement l’accès au modèle. C’est la couche gérée qui rend les agents IA opérationnels au sein de programmes métiers complexes et de longue durée.

Pour les fondateurs et les responsables produit, la leçon est pratique : si votre produit dépend d’agents IA interagissant avec des systèmes de production, votre architecture pour la mémoire, l’identité, l’accès aux outils, l’observabilité et le contrôle réseau comptera autant que la conception des prompts. Amazon Bedrock AgentCore est l’offre d’AWS pour maîtriser cette couche. L’acceptation par les clients dépendra de la preuve qu’elle réduit les frictions de déploiement sans créer une nouvelle catégorie de problèmes d’exécution et de gouvernance.