Contexte et besoin
Virtana a annoncé l’ajout d’Agentic Observability Enterprise Management à sa plateforme, permettant à ses agents d’intelligence artificielle d’inviter des agents provenant d’autres fournisseurs dans le traitement d’un incident IT. Jusqu’ici, les agents d’entreprise étaient enfermés dans un produit unique, ce qui empêchait une vision globale lorsqu’une panne traversait plusieurs systèmes hétérogènes. Cette fragmentation obligeait les ingénieurs à consolider manuellement les diagnostics.
Architecture des agents et protocoles
Le nouveau mécanisme repose sur deux standards ouverts : le Model Context Protocol et le Agent2Agent protocol. Tout agent compatible peut être sollicité, y compris ceux déjà fournis avec les logiciels du client. Depuis février, les agents externes peuvent interroger le System‑Aware MCP Server, qui diffuse plus de 25 000 métriques en temps réel. Parallèlement, le System Dependency Graph expose la dépendance des applications à l’infrastructure sous‑jacente, offrant ainsi un contexte partagé à chaque participant de l’enquête.
Dans le scénario illustré par Virtana, un agent tiers détecte une lenteur d’application, adresse une requête au root‑cause analysis agent de Virtana via Agent2Agent, et reçoit une analyse pointant un goulot d’étranglement de base de données survenu après un déploiement logiciel. D’autres agents spécialisés peuvent alors être mobilisés, et le système confirme la restauration du service.
Analyse des impacts opérationnels et de sécurité
Le CPO Amitkumar Rathi indique que « une équipe d’agents peut accomplir le même travail en millisecondes », contre plusieurs heures pour un war‑room traditionnel. Cette accélération repose sur l’automatisation du flux de diagnostic et la disponibilité immédiate de données métriques et de graphes de dépendance. Sur le plan de la gouvernance, les politiques client définissent quels agents externes sont autorisés, le nombre de tokens consommés et imposent un audit log détaillé pour chaque action, limitant ainsi les risques d’escalade non contrôlée.
Le modèle repose toutefois sur la conformité des agents tiers aux protocoles ouverts. Un agent non conforme ou mal configuré ne pourra pas être intégré, ce qui impose aux fournisseurs de publier ou d’adapter leurs interfaces. De plus, la gestion des tokens introduit une contrainte de capacité : un dépassement peut bloquer l’accès aux données critiques, d’où l’importance de politiques de quota précises.
Limites et perspectives
L’autonomie des agents est restreinte aux types d’incidents préalablement définis par le client. Les organisations qui privilégient la validation humaine doivent activer des étapes de validation avant chaque action corrective, ce qui rallonge le cycle mais augmente la sécurité. Enfin, la dépendance à un flux de plus de 25 000 métriques en temps réel implique une infrastructure de collecte robuste ; toute défaillance du MCP Server pourrait réduire la visibilité disponible pour les agents externes.
