Le dépannage agentique de HPE Zerto fait entrer l’IA cloud dans la reprise sur site

HPE Zerto a lancé un système de dépannage agentique reposant sur trois rôles d’agents, mais sa caractéristique la plus importante est l’endroit où ces agents opèrent. L’environnement d’exécution du dépannage agentique de HPE Zerto se trouve au sein de l’environnement de chaque client. Il examine localement les signaux actifs de reprise après sinistre, tout en envoyant certaines requêtes d’inférence et de connaissances à Amazon Web Services.

Cette séparation remet en cause l’hypothèse selon laquelle des agents d’entreprise utiles doivent déplacer les données opérationnelles vers une application cloud centralisée. HPE Zerto a plutôt placé l’orchestration à côté de l’infrastructure analysée. Amazon Bedrock fournit l’accès aux modèles, la recherche de connaissances, des garde-fous et des contrôles associés, sans devenir le lieu d’hébergement du flux de dépannage complet.

Le système est entré en production au deuxième trimestre 2026. HPE et AWS indiquent que plus de 20 % des clients Zerto l’ont ensuite adopté. Ils font également état d’une réduction de 10 % des tickets de support dans les flux de travail couverts par le système. Ces chiffres proviennent des entreprises et n’ont pas fait l’objet d’une validation indépendante.

Le résultat architectural compte au-delà d’un seul produit de reprise. Les environnements de reprise après sinistre combinent des journaux sensibles, des configurations changeantes, des contrôles d’accès stricts et une forte pression temporelle. Un assistant qui ne peut pas voir les conditions actuelles ne fournit que des conseils génériques. Un agent doté d’un accès illimité crée un autre risque opérationnel.

HPE Zerto tente d’occuper l’espace étroit entre ces deux issues. Ses agents reçoivent un accès structuré aux informations locales, répartissent les enquêtes par domaine technique et renvoient une réponse condensée par l’intermédiaire d’un orchestrateur de contrôle. La question centrale est de savoir si cette architecture peut préserver le contexte, la sécurité et un comportement prévisible à mesure que les environnements réels se complexifient.

Le dépannage agentique de HPE Zerto commence dans l’environnement du client

Le changement déterminant n’est pas l’interface de chat. C’est le placement de l’environnement d’exécution des agents à côté des systèmes et des éléments de preuve qu’ils doivent examiner.

HPE Zerto Software prend en charge la reprise après sinistre, la protection continue des données et la cyberrésilience dans les infrastructures hybrides et multicloud. Les opérateurs utilisent le produit pour surveiller les charges de travail protégées, la préparation à la reprise, l’état de santé de la réplication et l’exposition aux accords de niveau de service.

Le dépannage de cet environnement nécessite traditionnellement des informations provenant de plusieurs sources. Un administrateur peut examiner une alerte, consulter le journal d’un composant, vérifier des données de configuration, rechercher dans la documentation produit et comparer les résultats avec un runbook. Lors d’une panne, chaque transfert entre ces sources ajoute un délai et multiplie les occasions de manquer des éléments pertinents.

Le nouveau système place une expérience de chat dans l’interface de gestion Zerto existante. Les opérateurs peuvent interroger l’état d’un groupe de protection, les alertes récentes, les pratiques de configuration, les retards de réplication, les échecs de mise à niveau ou les problèmes système actifs. L’assistant peut également faire remonter des problèmes de santé et guider les actions de correction.

Selon le récit architectural conjoint, HPE déploie la couche agentique sous la forme d’un pod dans l’environnement sur site du client. Un pod est un groupe déployable de conteneurs fonctionnant comme une seule unité applicative. Dans cette conception, il contient l’environnement d’exécution local des agents.

L’environnement d’exécution utilise Strands Agents, un framework open source développé par AWS pour créer des agents pilotés par des modèles. L’historique des sessions reste stocké localement, et les agents accèdent aux informations Zerto actives via un serveur local Model Context Protocol.

Model Context Protocol, ou MCP, définit une méthode standard permettant à une application d’IA d’appeler des outils et d’obtenir des données contextuelles. HPE a encapsulé les API existantes de Zerto Manager dans un serveur MCP, donnant aux agents un accès structuré aux informations actuelles de l’environnement.

Cette approche diffère sensiblement de la copie de chaque journal et enregistrement de configuration vers un chatbot distant. Les agents Zerto peuvent demander les éléments locaux nécessaires à une enquête tout en conservant l’environnement d’exécution au sein de l’appliance. HPE affirme que seules les requêtes d’inférence de modèle et les requêtes Amazon Bedrock Knowledge Bases quittent le réseau local via HTTPS.

Cette distinction doit être formulée avec prudence. Le système n’est pas entièrement déconnecté du cloud, et il ne s’agit pas d’un déploiement de modèle hors ligne. Amazon Bedrock traite toujours les requêtes de modèle, tandis que son service de connaissances géré récupère les informations produit pertinentes. La conception locale contrôle l’orchestration et l’accès opérationnel plutôt que d’éliminer le traitement externe.

Cette frontière crée la tension centrale de l’article. Un agent exploité localement peut rester proche d’éléments de preuve sensibles, mais son raisonnement dépend toujours de services de modèles distants et de requêtes sortantes soigneusement conçues. L’utilité du système dépend donc du contexte qui franchit cette frontière, de la manière dont il est filtré et de la capacité des recommandations retournées à rester fondées.

Cette version intègre également l’assistance IA plus profondément dans le flux de reprise. Elle ne se limite plus à expliquer la documentation. Le système peut examiner les conditions actuelles et constituer une enquête spécifique à un problème, ce qui augmente à la fois sa valeur opérationnelle et le coût d’une conclusion erronée.

Une architecture en étoile maintient un agent aux commandes

HPE Zerto a réparti le dépannage entre des agents spécialisés, tout en conservant un orchestrateur unique comme point de contrôle pour la délégation et les réponses finales.

L’architecture utilise un agent orchestrateur et au moins deux sous-agents spécialisés. L’orchestrateur traite directement les questions courantes et délègue les enquêtes approfondies lorsqu’un problème exige une analyse spécialisée.

Un sous-agent se concentre sur Zerto Manager, également appelé ZVM. Il enquête sur des domaines tels que les pannes de service, les problèmes réseau et les échecs de mise à niveau. Ses outils donnent accès aux données environnementales pertinentes, tandis que les compétences de domaine identifient les connaissances techniques et les schémas de journaux reconnaissables.

Un autre sous-agent se concentre sur le Zerto Replication Engine, ou VRA. Il traite les problèmes de réplication, la connectivité réseau intersite, les échecs d’installation et les retards. Il reçoit ses propres outils, instructions, connaissances de domaine et contexte de travail.

Cette répartition reflète un choix d’ingénierie important. Donner à un agent généraliste chaque journal, outil, instruction et détail de conversation peut produire un contexte démesuré aux signaux concurrents. Cela rend aussi les défaillances difficiles à isoler, puisque le même composant effectue le routage, l’analyse et la génération des réponses.

HPE utilise plutôt une structure en étoile. L’orchestrateur se trouve au centre, et les agents spécialisés fonctionnent comme des branches. Les sous-agents rendent compte à l’agent parent au lieu de s’appeler directement les uns les autres.

AWS décrit ce modèle multi-agent comme des agents-outils, dans lequel un agent coordinateur appelle des spécialistes via des interfaces délimitées. Chaque spécialiste peut utiliser une invite, un contexte, un modèle et un ensemble d’outils distincts.

Pour Zerto, cette séparation présente trois avantages pratiques. Premièrement, une enquête riche en journaux ne remplit pas le contexte de l’orchestrateur de données de diagnostic brutes. Le spécialiste renvoie un rapport plus court contenant ses conclusions, plutôt que l’intégralité de son processus de travail.

Deuxièmement, chaque agent devient testable indépendamment. Les ingénieurs peuvent évaluer si le spécialiste VRA sélectionne les bons outils sans exiger que chaque test traverse un comportement ZVM sans rapport. Cette séparation peut faciliter la localisation des régressions.

Troisièmement, l’orchestrateur reste responsable de la réponse finale. HPE affirme qu’il retire les secrets et les journaux bruts avant de présenter les résultats à l’utilisateur. Un chemin de sortie unique donne également au produit un emplacement unique pour appliquer les règles de réponse.

La structure en étoile limite l’autonomie latérale. Si un spécialiste découvre qu’un autre composant est responsable du problème, il renvoie cette observation à l’orchestrateur. Il n’appelle pas indépendamment un pair.

Cette contrainte réduit le risque que des conversations récursives entre agents consomment des jetons sans parvenir à une décision. Elle crée aussi une séquence traçable pour l’observabilité. Chaque délégation commence et s’achève au même point de contrôle.

Le compromis est un risque de friction dans le routage. L’orchestrateur doit reconnaître correctement quand une question nécessite une spécialisation et sélectionner l’agent approprié. Un spécialiste doit également condenser ses conclusions sans supprimer les éléments essentiels au diagnostic final.

HPE utilise des profils de modèles différents pour ces responsabilités. Les tâches courantes peuvent rester du ressort de l’orchestrateur, tandis que les enquêtes exigeant davantage de raisonnement peuvent utiliser un modèle plus puissant. L’entreprise indique avoir d’abord évalué des modèles plus grands pour établir la faisabilité, puis comparé des alternatives selon la qualité des réponses, la latence et le coût.

Cette approche multi-modèle évite de traiter chaque requête comme une tâche d’égale difficulté. Vérifier l’état d’un groupe de protection ne requiert pas le même budget de raisonnement que l’interprétation d’une longue séquence de défaillances à travers les journaux et l’état du réseau.

Elle transforme également la sélection de modèles, d’une décision d’approvisionnement ponctuelle, en processus d’ingénierie continu. À mesure que les modèles de fondation évoluent, HPE peut réévaluer quel modèle convient à chaque agent sans reconstruire l’ensemble du produit autour d’un flux de travail spécifique à un fournisseur.

Les données de reprise actives constituent à la fois l’avantage et le risque

Le système devient utile lorsqu’il peut interroger l’infrastructure actuelle, mais ce même accès rend essentiels l’ancrage dans les faits, les autorisations et la sélection des outils.

Un agent de dépannage a besoin de plus que de manuels produit. La documentation peut expliquer la signification d’une alerte, mais elle ne peut pas révéler si un moteur de réplication particulier est retardé, quel itinéraire réseau échoue ou si une modification récente de configuration a affecté la préparation à la reprise.

HPE connecte ses agents aux données opérationnelles actives via un serveur MCP local. Le serveur expose certaines API de Zerto Manager sous forme d’outils structurés. Au lieu de demander à un modèle de langage d’interpréter un vidage de données brutes, l’agent peut appeler une opération définie et recevoir un résultat typé.

La spécification MCP publique distingue les outils, les ressources et les invites via une interface client-serveur convenue. Pour les logiciels d’entreprise, cette structure peut transformer une API produit existante en couche accessible aux agents sans réécrire les services opérationnels sous-jacents.

L’accès typé aide, mais ne garantit pas un diagnostic correct. L’agent doit toujours choisir l’outil approprié, fournir des paramètres valides, interpréter les informations retournées et les relier à la documentation pertinente.

HPE associe les outils locaux à Amazon Bedrock Knowledge Bases. La génération augmentée par récupération, ou RAG, récupère des sources pertinentes avant que le modèle ne crée une réponse. L’objectif est d’ancrer les recommandations dans la documentation produit et les runbooks approuvés plutôt que dans la seule mémoire du modèle.

Le service de base de connaissances d’Amazon gère la récupération de documents et peut renvoyer des sources pertinentes pour une requête. Dans la conception de Zerto, ces connaissances externes complètent l’état de l’environnement local obtenu via MCP.

La distinction entre ces sources est importante. La documentation produit décrit le comportement attendu. Les API locales décrivent l’état actuel du client. Un dépannage fiable exige que l’agent compare les deux sans confondre une procédure générique avec des éléments de preuve concernant l’incident actif.

Prenons la question d’un retard de réplication. La documentation peut citer les contraintes de bande passante, les interruptions réseau, les variations de charge ou l’état de santé de l’appliance comme causes possibles. Les outils locaux doivent déterminer quelles conditions sont réellement présentes dans l’environnement du client. Une réponse utile doit réduire le champ des possibilités plutôt que répéter toute la liste.

HPE indique que les agents spécialisés utilisent également des compétences métier contenant des schémas de journaux connus. Ces compétences fournissent au modèle des instructions structurées pour reconnaître les signaux associés à certains composants et types de défaillances.

Le système doit ensuite préserver la traçabilité en interne. Les ingénieurs doivent pouvoir distinguer une conclusion étayée par des données en direct d’une hypothèse déduite par le modèle. La présentation publiée par AWS décrit la télémétrie, les évaluations et les sorties structurées, mais ne divulgue pas le comportement complet en matière de citations présenté aux administrateurs.

Le contrôle des accès constitue un autre point de tension. Un outil MCP étendu peut exposer davantage d’informations opérationnelles qu’une question ne l’exige. Un outil plus ciblé réduit cette exposition, mais peut omettre le contexte nécessaire au diagnostic. La définition de la frontière de l’outil devient donc une décision de sécurité et de produit, et non une simple tâche d’intégration.

Le balisage des requêtes par locataire ajoute un autre contrôle. L’architecture utilise des balises de rôle AWS Identity and Access Management associées à chaque locataire. CloudWatch, DynamoDB et Lambda permettent de surveiller l’utilisation et d’appliquer les limites propres à chaque locataire.

Amazon Bedrock Guardrails vérifie les prompts et les sorties autour de l’inférence du modèle. La documentation AWS indique que ses contrôles de garde-fous peuvent filtrer certains contenus, détecter les attaques par prompt, restreindre les sujets interdits et masquer les informations sensibles.

Ces filtres réduisent certains risques, mais ne peuvent pas vérifier chaque conclusion opérationnelle. Une réponse peut rester dans un sujet approuvé tout en recommandant une remédiation erronée. Les garde-fous régissent les limites de contenu, tandis que l’évaluation et la logique produit doivent garantir l’exactitude technique.

C’est pourquoi l’architecture locale de HPE ne doit pas être interprétée comme une simple promesse de confidentialité. L’orchestration locale réduit la collecte centralisée et maintient l’exécution des outils à proximité de l’environnement. Elle ne supprime pas le besoin de contrôles sur les données sortantes, de conception des autorisations, de tests des risques liés aux modèles ou de jugement humain lors d’incidents à fort impact.

Réponses testées de HPE Zerto, parcours d’outils, latence et tokens

HPE a traité l’évaluation comme un système opérationnel, et non comme un test unique de précision effectué avant la mise en production.

L’évaluation des agents est difficile, car la réponse finale n’est qu’un résultat observable parmi d’autres. Un agent peut produire une réponse plausible après avoir sélectionné le mauvais outil, utilisé des éléments non pertinents ou suivi un parcours excessivement coûteux. Ce comportement peut échouer dans des conditions légèrement différentes.

HPE a construit ses tests avec PyTest et le kit de développement logiciel d’évaluation Strands Agents. L’entreprise a créé des tâches qui exécutent à plusieurs reprises une suite plus large à mesure que les agents, les modèles et les prompts évoluent.

La première catégorie de tests couvre les requêtes de base. Chaque test fournit une requête unique et évalue la réponse. Cette approche convient aux questions stables dont le résultat attendu est clair ou dont les critères de notation sont définis.

La deuxième catégorie évalue les conversations à plusieurs tours. Un modèle simulant l’utilisateur interagit avec l’agent après la requête initiale, puis l’intégralité de la conversation est évaluée. Ce format vérifie si le système demande les informations manquantes et maintient le contexte sur plusieurs échanges.

La troisième catégorie génère des tests dynamiques. Le générateur d’expériences Strands crée des cas à partir de critères sélectionnés, offrant à HPE un moyen d’explorer des scénarios non représentés dans un jeu de tests fixe. La génération dynamique élargit la couverture, même si les tests générés doivent toujours reposer sur des critères pertinents et être examinés.

Chaque test peut appliquer quatre évaluateurs. Un évaluateur de réponse note celle-ci par rapport à des exigences prédéfinies. Un évaluateur de trajectoire examine si l’agent a sélectionné les outils appropriés et suivi un parcours acceptable.

Un évaluateur de latence vérifie le délai d’exécution par rapport à un seuil. Un évaluateur de tokens vérifie que la consommation reste dans des limites définies. Ensemble, ces mesures reflètent le compromis de production entre qualité du diagnostic, temps de réponse et consommation d’inférence.

L’évaluation de trajectoire est particulièrement importante pour un agent opérationnel. La formulation finale peut sembler correcte même lorsque le système y est parvenu par une séquence non sûre ou peu fiable. Tester le parcours peut révéler qu’un agent a ignoré une vérification en direct, appelé une API sans rapport ou privilégié la documentation alors que des données actuelles étaient disponibles.

La suite d’évaluation prend également en charge la conception multi-modèles. HPE peut comparer un modèle plus petit à un modèle plus grand selon les mêmes critères de réponse, de trajectoire, de latence et de tokens. Le remplacement d’un modèle devient ainsi une décision empirique, plutôt qu’une hypothèse générale selon laquelle un modèle plus grand obtient toujours de meilleures performances.

Le système diffuse l’avancement de l’investigation vers l’interface au moyen de Server-Sent Events. SSE est un mécanisme web qui permet à un serveur d’envoyer continuellement des mises à jour à un navigateur via une seule connexion. Les utilisateurs peuvent suivre la progression pendant qu’un spécialiste examine un problème.

HPE affirme que le streaming a amélioré l’expérience utilisateur, car les opérateurs n’attendent plus sans retour d’information. Dans la reprise après sinistre, une progression visible aide aussi à distinguer une investigation en cours d’une interface figée.

Toutefois, l’activité diffusée en continu peut créer une fausse impression de confiance si elle affiche des étapes sans en expliquer la valeur probante. Une liste d’appels d’outils ne constitue pas un diagnostic vérifié. L’interface doit présenter suffisamment de progression pour inspirer confiance sans transformer le raisonnement interne en mise en scène.

La même prudence s’applique aux affirmations de HPE sur l’adoption. L’entreprise rapporte que plus de 20 % des clients utilisent activement le système et que les cas de support concernés ont diminué de 10 %. Ces résultats suggèrent une véritable utilisation du produit, mais la publication publique ne définit ni l’usage actif, ni la période de mesure, ni la population de flux de travail couverte.

Une diminution des cas de support peut également avoir plusieurs explications. L’agent peut résoudre les problèmes avec succès, orienter les utilisateurs vers la documentation existante, modifier la manière dont les cas sont classés ou décourager certaines escalades. Des données indépendantes sur les taux de résolution et les résultats offriraient une vision plus claire.

Pour les équipes d’ingénierie qui envisagent une conception similaire, la leçon n’est pas que quatre évaluateurs suffisent à établir la fiabilité. La leçon est que les agents de production nécessitent des comportements mesurables à plusieurs niveaux. La qualité des réponses, le choix des outils, la réactivité et l’utilisation des ressources peuvent échouer indépendamment les uns des autres.

Une base de connaissances d’ingénierie consultable suit un principe similaire. La recherche devient plus utile lorsque les documents restent organisés, à jour et reliés au travail effectué par les ingénieurs.

Les plateformes de reprise cloud font désormais face à une question d’interface

La pression concurrentielle se déplace des seules fonctionnalités de réplication vers la capacité à interpréter l’état de reprise et à guider un opérateur pendant un incident.

HPE Zerto évolue sur un marché qui comprend déjà des services de reprise natifs du cloud. Amazon Elastic Disaster Recovery réplique les charges de travail prises en charge, sur site et dans le cloud, vers une zone de préparation au sein d’un compte AWS. Les opérateurs peuvent lancer des instances de reprise pour des exercices ou de véritables incidents.

Le service de reprise AWS met l’accent sur la réplication continue, la reprise à un instant donné, les tests non perturbateurs et le basculement de retour. Il est étroitement intégré à l’infrastructure AWS et vise la reprise dans Amazon EC2.

Microsoft Azure Site Recovery gère la réplication, le basculement et le basculement de retour pour les machines virtuelles et serveurs physiques pris en charge. Sa plateforme de reprise couvre la réplication Azure vers Azure ainsi que plusieurs scénarios sur site avec Azure comme cible de reprise.

Ces services ne correspondent pas directement à chaque déploiement Zerto. HPE Zerto prend en charge des modèles d’exploitation hybrides plus larges et conserve sa propre architecture produit. La comparaison pertinente ici n’est pas une liste de contrôle des fonctionnalités de réplication.

La nouvelle pression concerne l’interface opérationnelle au-dessus de ces fonctionnalités. Les systèmes de reprise génèrent des alertes, des états de configuration, des métriques de réplication et des résultats d’exercices. Un agent peut potentiellement traduire ces informations en une investigation guidée sans exiger que chaque administrateur sache où se trouve chaque signal.

L’initiative précoce de HPE lui donne la possibilité d’établir un comportement agentique autour de son contexte opérationnel propriétaire. Ses spécialistes peuvent encoder des schémas de journaux spécifiques aux composants et utiliser des API déjà associées à Zerto Manager et aux moteurs de réplication.

Les fournisseurs cloud disposent d’un autre avantage. Ils contrôlent l’infrastructure, la télémétrie, les services d’identité, les API de reprise et les plateformes d’IA gérées dans leurs clouds respectifs. Ils peuvent potentiellement construire des agents ayant un accès direct à une collection plus large de signaux natifs.

Cela crée le principal adversaire de l’approche HPE Zerto : le dépannage sous contrôle local face à l’intelligence opérationnelle centrée sur le cloud. Il ne s’agit pas simplement d’une compétition entre HPE, AWS ou Microsoft, car AWS fournit les modèles qui sous-tendent le système de Zerto. Il s’agit d’une concurrence entre différents emplacements architecturaux du contrôle et du contexte.

Le contrôle local maintient l’orchestration à proximité d’une infrastructure protégée et peut prendre en charge des environnements soumis à des politiques strictes de résidence des données. Les systèmes centrés sur le cloud peuvent s’appuyer sur une télémétrie intégrée et des services gérés sans maintenir un environnement d’exécution d’agent dans l’appliance de chaque client.

L’architecture HPE combine les deux approches. Les agents et les outils opérationnels restent locaux, tandis que l’inférence du modèle et la recherche documentaire utilisent AWS. Cette configuration hybride cherche à préserver sur site la frontière d’exécution la plus sensible sans renoncer aux modèles de fondation gérés.

Cette approche confère également à HPE des responsabilités de déploiement qu’un service cloud entièrement géré peut éviter. Le pod local doit rester compatible avec les versions du produit, les politiques réseau des clients, les systèmes d’authentification et les connexions sortantes restreintes. Le dépannage de l’agent de dépannage devient une partie de la charge opérationnelle.

Les environnements isolés du réseau présentent la limite la plus nette. HPE indique que l’infrastructure de reprise après sinistre est souvent isolée du réseau, sensible à la latence ou soumise à des exigences de résidence des données. Pourtant, le système décrit nécessite toujours un accès HTTPS pour l’inférence du modèle et les requêtes de connaissances.

Les installations strictement déconnectées ne peuvent donc pas utiliser l’architecture exactement telle qu’elle est décrite. D’autres clients peuvent autoriser un trafic sortant étroitement contrôlé, mais les équipes de sécurité devront toujours examiner les destinations, le contenu des requêtes, les contrôles d’identité, le comportement de rétention et les modes de défaillance.

La latence couvre également deux emplacements. Les appels d’outils vers Zerto restent locaux, tandis que les requêtes de raisonnement transitent vers AWS. Une investigation complexe peut nécessiter plusieurs cycles entre les décisions du modèle et les résultats des outils locaux. Le streaming peut rendre cette attente visible, mais il ne peut pas supprimer la dépendance au réseau.

La valeur stratégique de l’architecture dépend de la capacité de ce compromis hybride à surpasser les alternatives. S’il fournit des recommandations fiables et fondées sur des preuves sans centraliser les données opérationnelles brutes, il offre aux éditeurs de logiciels d’entreprise un modèle réutilisable. Si les contraintes réseau ou les erreurs d’ancrage prédominent, les acheteurs pourront préférer une assistance plus simple ou des opérations cloud entièrement gérées.

Le prochain test déterminera si le diagnostic guidé devient une exploitation fiable

Trois signaux montreront si le dépannage agentique HPE Zerto devient une infrastructure fiable plutôt qu’une interface de support attrayante.

Le premier signal concerne la qualité de résolution. Les chiffres d’adoption et de cas de support constituent des points de départ utiles, mais ils n’indiquent pas si les utilisateurs ont choisi des remèdes sûrs ou résolu les incidents plus rapidement.

HPE devrait à terme publier des indicateurs de résultats pour les workflows pris en charge. Parmi les signaux utiles figurent la résolution réussie en libre-service, l’escalade après interaction avec un agent, les incidents récurrents, l’acceptation par les administrateurs et les erreurs découvertes lors de la revue. Des périodes de mesure comparables rendraient ces résultats plus significatifs.

Si des résultats examinés de manière indépendante démontrent un diagnostic précis dans des environnements clients variés, l’argument en faveur d’opérations agentiques locales se renforcera. Si les réductions de recours au support interviennent sans données de résolution fiables, le récit de performance publié restera incomplet.

Le deuxième signal est l’extension au-delà des tâches de conseil. HPE cite l’exécution de tâches pour les utilisateurs comme l’un des objectifs du système. L’architecture publique explique surtout l’assistance, l’investigation, les alertes de santé et les recommandations de mitigation.

Passer des recommandations aux actions modifie le modèle de risque. Une explication erronée fait perdre du temps, tandis qu’un changement de configuration erroné peut affecter la protection ou la préparation à la reprise. Les agents capables d’agir nécessitent des autorisations limitées, des approbations, des pistes d’audit complètes, des opérations idempotentes et des mécanismes de restauration fiables.

Toute version permettant au système de modifier une configuration devrait donc faire l’objet d’une attention particulière. Des actions limitées, réversibles et assorties d’une confirmation explicite renforceraient l’architecture de HPE. Une remédiation autonome étendue, sans détails publiés sur les contrôles, accroîtrait l’incertitude.

Le troisième signal concerne le comportement de l’agent lors d’une connectivité dégradée et d’incidents majeurs. Une question de support courante suppose un accès réseau stable et une urgence modérée. Un événement de ransomware ou une panne d’infrastructure peut perturber les mêmes chemins d’identité, de réseau ou de cloud qu’utilise l’agent.

HPE doit définir clairement le comportement du système lorsque Amazon Bedrock devient indisponible, qu’une requête de connaissances expire, qu’un outil local renvoie des données obsolètes ou que l’orchestrateur ne peut pas mener une investigation à son terme. Une dégradation sûre devrait distinguer les éléments de preuve manquants d’une infrastructure saine et orienter les opérateurs vers les procédures de reprise établies.

L’utilisation interne de l’entreprise fournit un autre terrain de test. HPE indique que ses ingénieurs utilisent le système pour enquêter sur des problèmes courants, tandis que son équipe d’assurance qualité l’intègre aux workflows de test. Ces utilisateurs peuvent mettre au jour des schémas de défaillance avant que les clients ne dépendent du même comportement en situation de crise.

L’architecture contient déjà plusieurs contraintes raisonnables. Les agents spécialisés reçoivent des responsabilités limitées. La récursion pair à pair est interdite. L’orchestrateur contrôle le résultat final. Des API locales fournissent des données actuelles, tandis que des évaluations répétées examinent les réponses et les trajectoires des outils.

Aucun de ces contrôles ne rend le raisonnement des modèles de langage déterministe. Le système continue d’opérer à travers l’évolution des versions logicielles, des topologies clients, des formats de journaux, des versions de modèles et de la documentation. L’évaluation continue doit donc accompagner le produit après son déploiement.

Pour les acheteurs d’entreprise, la bonne question n’est pas de savoir si un agent peut résumer une alerte. Il s’agit de savoir si le système montre d’où provient sa réponse, respecte les autorisations opérationnelles, reconnaît les preuves manquantes et escalade avant que l’incertitude ne se transforme en action.

Les développeurs devraient surveiller la frontière des outils. Un serveur MCP bien conçu peut rendre des API existantes exploitables par des agents, mais chaque opération exposée étend l’autorité du système. Les équipes produit devraient concevoir les outils avec le même soin que les API publiques et les rôles administratifs.

Les travailleurs du savoir peuvent tirer un enseignement plus large de ce déploiement. L’IA devient plus utile lorsqu’elle peut relier des documents de référence fiables au contexte de travail actuel. Cet avantage dépend de la qualité des sources, des limites d’accès et d’une distinction claire entre les faits récupérés et le jugement généré.

HPE Zerto a transposé cette idée dans l’un des environnements les moins indulgents de l’informatique d’entreprise. Le système associe une orchestration locale, des données de reprise après sinistre en temps réel, des agents spécialisés et une inférence cloud gérée au sein d’un même parcours opérationnel.

Les preuves doivent désormais aller au-delà de l’adoption. Il faudra observer si HPE publie des résultats de résolution, introduit des actions contrôlées et documente le comportement en mode dégradé. Ces signaux détermineront si le modèle de dépannage agentique de HPE Zerto devient un modèle que d’autres fournisseurs d’infrastructure devraient suivre.