HPE Zerto construit un système de dépannage agentique sur site avec Amazon Bedrock

HPE Zerto a construit un système de dépannage agentique qui s’exécute dans l’environnement sur site d’un client tout en utilisant Amazon Bedrock pour alimenter sa couche de raisonnement. Le système relie une interface en langage naturel à des données de reprise après sinistre en direct, à la documentation produit et à des outils opérationnels, dans le but d’aider les équipes de résilience à enquêter sur les problèmes sans passer manuellement d’un tableau de bord à des supports d’assistance.

L’architecture, détaillée dans un article du AWS Machine Learning Blog, reflète une contrainte pratique pour l’IA d’entreprise : le service de modèle peut être basé dans le cloud, mais le contexte opérationnel sensible et l’exécution des outils doivent rester proches de l’infrastructure du client. HPE Zerto indique que son système est déployé sous forme de pod dans le produit Zerto et accessible via l’interface d’exploitation existante.

Pour les développeurs IA et les équipes technologiques d’entreprise, l’élément important est moins un nouveau chatbot que la frontière que HPE Zerto a tracée autour de celui-ci. Les agents peuvent raisonner sur l’état actuel de l’environnement et récupérer des connaissances pertinentes, mais leur accès est médié par des API locales, des systèmes de récupération et des contrôles de sécurité. Cette conception vise à rendre un assistant IA utile pendant les pannes et les problèmes de configuration, sans transformer un modèle à usage général en opérateur sans restriction.

Une couche multi-agents connectée à des données de reprise en direct

Selon le AWS Machine Learning Blog, le système utilise des agents construits avec Strands Agents. Ces agents s’exécutent sous forme de pod sur site et peuvent s’appuyer sur trois principales sources d’information : l’historique des conversations stocké localement, les outils internes et la récupération de connaissances externes.

Le chemin des outils internes est exposé via un serveur local Model Context Protocol. Ce serveur fournit un accès structuré aux API Zerto Manager, permettant à l’agent d’inspecter des informations en direct provenant de l’environnement client plutôt que de s’appuyer uniquement sur une documentation statique ou sur la description d’un incident par un utilisateur.

Le chemin externe utilise Amazon Bedrock Knowledge Bases pour récupérer de la documentation publique, des runbooks et d’autres éléments opérationnels. Cette combinaison est importante car le dépannage des systèmes de reprise après sinistre nécessite généralement à la fois l’état actuel et le contexte procédural. Une alerte peut montrer ce qui tombe en panne, tandis qu’un runbook ou un guide produit explique la séquence sûre pour l’examiner ou le corriger.

L’interface est intégrée à l’expérience utilisateur Zerto existante. HPE Zerto explique utiliser les Server-Sent Events pour diffuser la progression de l’enquête à l’utilisateur, en exposant l’activité intermédiaire au lieu d’attendre une seule réponse finale. Les cas d’usage annoncés incluent répondre aux questions de configuration, aider à atténuer les problèmes de santé, assister à la mise en place et à l’adoption des fonctionnalités, et résumer le risque, l’exposition aux accords de niveau de service ou l’état de préparation à la reprise.

Cela ne signifie pas que le modèle contrôle de manière autonome l’ensemble de l’environnement de reprise. La source décrit un système conçu pour raisonner, agir et répondre via les outils mis à sa disposition. La sécurité pratique du déploiement dépend donc des autorisations, de la logique de validation et des limites d’action implémentées autour de ces outils — des détails que l’article AWS aborde au niveau architectural mais ne quantifie pas entièrement comme rapport de performance en production.

Pourquoi le modèle de déploiement sur site est important

Les utilisateurs cibles de HPE Zerto gèrent la cyber-résilience, la protection continue des données et la reprise après sinistre dans des environnements hybrides ou multi-cloud. Dans ces contextes, les données opérationnelles peuvent inclure l’état des charges de travail protégées, l’état de réplication, les alertes, les événements, les relations entre sites et la préparation à la reprise. Le défi, selon l’entreprise, est que ces informations sont fragmentées entre interfaces et documentation, ce qui ralentit les décisions pendant les pannes ou les incidents cyber.

L’exécution de la couche agentique au sein de l’environnement client résout en partie ce problème. L’assistant peut être placé à côté des systèmes qu’il doit inspecter, tandis que l’historique des sessions est stocké localement et que le produit reste accessible via l’interface d’administration familière. Pour les entreprises, cela peut simplifier le déploiement et réduire le besoin de déplacer le contexte opérationnel vers une application externe distincte.

La couche modèle dépend toujours d’Amazon Bedrock. AWS indique que HPE Zerto a choisi le service pour son accès contrôlé aux fondations de modèles, sa capacité à évaluer différents modèles et son intégration avec des garde-fous, l’observabilité et des services de récupération. HPE Zerto utilise également Amazon Bedrock Guardrails pour appliquer des contrôles de politique, de conformité et de sécurité aux invites et aux sorties générées.

Cette configuration hybride illustre un schéma de déploiement de plus en plus pertinent pour l’IA d’entreprise : conserver l’accès aux données et l’exécution près du système d’enregistrement, tout en utilisant une plateforme de modèle gérée pour l’inférence et le choix du modèle. Cela peut offrir de la flexibilité, mais crée aussi des dépendances entre le produit local, le chemin réseau vers les services de modèle, la qualité de la récupération et les autorisations accordées à chaque agent.

Les preuves et les affirmations restent rapportées par le fournisseur

Les éléments disponibles sont une étude de cas du AWS Machine Learning Blog rédigée autour de l’architecture de HPE Zerto. Elle confirme les composants décrits et l’approche de déploiement, mais ne fournit pas de validation indépendante de la précision du dépannage, de la latence de réponse, de l’adoption par les clients, de la réduction du volume de tickets d’assistance ou d’améliorations mesurables du temps de reprise.

Les affirmations concernant des décisions de reprise plus rapides et mieux informées ainsi qu’une charge opérationnelle réduite doivent donc être lues comme des résultats attendus du système plutôt que comme des résultats vérifiés indépendamment. La source ne précise pas non plus quels modèles de fondation sont utilisés en production, comment le routage des modèles est géré, ni à quelle fréquence les agents sont autorisés à prendre des actions directes plutôt qu’à renvoyer des recommandations à un opérateur.

Un second article du AWS Machine Learning Blog sur l’Intuit EWOK Agent d’Intuit offre un point de référence connexe, mais pas de preuve supplémentaire concernant HPE Zerto. Intuit décrit un agent qui traduit des demandes de basculement en langage courant en flux de travail validés, tandis qu’un système d’exécution déterministe effectue les changements d’infrastructure. Intuit affirme que les équipes ont utilisé ce système pendant huit mois et rapporte que les flux de reprise pris en charge peuvent être terminés en environ 20 minutes, mais il s’agit des propres affirmations d’Intuit concernant sa plateforme distincte.

Les deux cas partagent un principe de conception plus large : laisser un modèle d’IA interpréter l’intention et choisir parmi des capacités bornées, tandis que des systèmes déterministes appliquent les politiques et exécutent des opérations à fort impact. Ce schéma est plus transférable que tout benchmark spécifique, mais les organisations doivent malgré tout le tester face à leurs propres exigences en matière de qualité des données, de modes de défaillance et de contrôle des changements.

Implications pour les développeurs et les acheteurs d’entreprise

Pour les développeurs, l’approche de HPE Zerto met en lumière le grounding comme un problème d’intégration plutôt que comme un exercice de rédaction de prompts. L’agent a besoin d’un accès fiable à l’état actuel du produit, d’un schéma d’outils défini, d’une documentation pertinente et d’un contexte de session suffisant pour éviter de demander à plusieurs reprises des informations déjà disponibles dans la conversation. Un serveur MCP local peut fournir une interface structurée, mais il devient aussi un point de contrôle critique pour l’authentification, l’autorisation, la journalisation et la compatibilité des API.

Pour les acheteurs d’entreprise, les questions clés d’évaluation sont opérationnelles. Le système peut-il distinguer une alerte obsolète d’une condition actuelle ? Cite-t-il ou expose-t-il la source d’une recommandation ? Les administrateurs peuvent-ils limiter les outils par rôle et par environnement ? Que se passe-t-il lorsque le modèle est indisponible, que le résultat de la récupération est incomplet ou que la remédiation demandée pourrait augmenter le risque de perte de données ? L’article AWS établit l’architecture, mais ne répond pas à toutes ces questions d’achat et de gouvernance.

La valeur du système sera probablement la plus élevée là où les équipes font face à une forte densité d’information et à un niveau d’expérience des opérateurs inégal. Une couche en langage naturel peut réduire le temps nécessaire pour rassembler le contexte et expliquer les symptômes, en particulier pour les administrateurs moins expérimentés. Mais en reprise après sinistre, une explication utile n’est pas la même chose qu’une exécution sûre. Tout passage du diagnostic à la remédiation nécessite des autorisations explicites, des étapes de confirmation, des journaux d’audit et un retour fiable vers des opérateurs humains.

Ce qu’il faut surveiller ensuite

Les prochains signaux significatifs seront des preuves de déploiement au-delà de la description architecturale. HPE Zerto pourrait préciser si l’assistant est généralement disponible, quelles éditions du produit et quels environnements le prennent en charge, et si les clients peuvent configurer le choix du modèle ou les autorisations des outils.

Les développeurs devraient également surveiller les mesures publiées concernant la précision des réponses, la qualité de la récupération, les fausses recommandations, le temps gagné pendant l’enquête sur les incidents et le taux d’acceptation ou de rejet des actions suggérées par les utilisateurs. Ces métriques montreraient si le système améliore le travail opérationnel au lieu d’ajouter simplement une interface conversationnelle.

Du côté de la plateforme, la flexibilité des modèles restera un test important. HPE Zerto explique qu’Amazon Bedrock permet d’évaluer les modèles de fondation selon la qualité, la latence et le coût. Des comparaisons en conditions réelles, des conseils de déploiement et des détails plus clairs sur la résidence des données et le comportement en cas de panne réseau aideraient les entreprises à évaluer si cette flexibilité apporte un avantage pratique.

Perspective Creati.ai

Le système de HPE Zerto est un exemple utile de la manière dont l’IA agentique d’entreprise devient concrète : au sein d’un produit opérationnel existant, connectée à l’état en direct et contrainte par les API et les contrôles qui régissent déjà l’environnement. Le point le plus fort de la conception est la séparation entre une couche de raisonnement conversationnel et les interfaces opérationnelles sous-jacentes du produit.

La question plus difficile est la preuve. En reprise après sinistre, un agent doit être jugé non seulement sur sa capacité à expliquer une alerte, mais aussi sur le caractère actuel, vérifiable et sûr de ses conseils sous pression. Tant que HPE Zerto ou ses clients ne publieront pas de données de परिणाम, l’annonce est mieux comprise comme un schéma de déploiement crédible et une architecture à évaluer — pas encore comme la preuve que les agents ont résolu les opérations de reprise.