Michael JohnsonAWS a annoncé CloudWatch Omni le 22 septembre 2026 et l’a indiqué comme étant généralement disponible le 23 septembre. Ces dates correspondent à deux événements différents : l’annonce et le début de la disponibilité générale. Omni réunit l’observabilité des applications et des agents d’IA dans une même expérience, avec une interface web autonome et des extensions pour les IDE, ainsi qu’une intégration à CloudWatch. L’annonce de CloudWatch Omni par AWS
Cette combinaison répond à un angle mort en production : une requête d’agent peut aboutir sans qu’une erreur de service classique soit détectée, tout en produisant une mauvaise réponse ou en choisissant le mauvais outil. AWS met en avant la possibilité d’examiner les traces et les évaluations des agents en parallèle de la télémétrie des applications. La question pratique est de savoir si ces signaux seront utiles dans un espace de travail partagé, et quelles données, quels accès et quels coûts impliquera leur acheminement à cet endroit.
Le produit va au-delà des traces d’agents
Omni est une extension de CloudWatch, et non un remplacement. AWS indique que les alarmes, les tableaux de bord, les API et les flux de travail existants de CloudWatch restent opérationnels. Les données de télémétrie déjà envoyées à CloudWatch peuvent apparaître dans Omni sans reconfiguration ; les autres charges de travail instrumentées peuvent transmettre leurs données via le protocole OpenTelemetry (OTLP). AWS décrit également la découverte des services et la cartographie des dépendances, ainsi que des espaces permettant de réunir, lorsqu’ils sont configurés à cette fin, des données de télémétrie provenant de plusieurs comptes et régions. La documentation de CloudWatch Omni
L’expérience ne se limite pas à la console de gestion AWS. AWS propose une interface web autonome avec authentification unique, ainsi que des extensions pour VS Code, Cursor et Kiro. La note de mise à jour du 23 septembre indique que le service est généralement disponible dans l’est des États-Unis (Virginie du Nord), l’ouest des États-Unis (Oregon) et en Europe (Irlande). Les équipes doivent vérifier la prise en charge régionale avant d’intégrer Omni à une architecture de production.
Pour les agents, AWS décrit l’exploration des traces, l’évaluation et l’expérimentation avec des frameworks tels que l’OpenAI Agents SDK, LangGraph, CrewAI, Vercel AI SDK et Strands. Pour les enquêtes sur les applications, les utilisateurs peuvent poser des questions en langage naturel ou explorer directement la télémétrie ; AWS indique que ses fonctions d’investigation assistées par l’IA s’appuient sur DevOps Agent. Dans son article de lancement consacré aux applications, AWS précise également que DevOps Agent est activé par défaut dans chaque session d’investigation Omni, un comportement que les administrateurs doivent comprendre lorsqu’ils évaluent ce flux de travail.
Pourquoi le rapprochement des signaux pourrait compter
Il s’agit d’un avantage opérationnel plausible, et non d’un résultat de performance démontré. Les documents de lancement d’AWS décrivent un flux de travail unifié, mais n’établissent pas qu’il permet de résoudre les incidents plus rapidement que les outils existants. Les équipes devront vérifier si les évaluations et les investigations d’Omni sont utiles pour leurs propres charges de travail.
OpenTelemetry peut faciliter l’envoi de données de télémétrie issues d’instrumentations existantes, mais un protocole commun ne rend pas les plateformes d’observabilité interchangeables. La spécification OTLP définit le mode de transmission des données de télémétrie ; les équipes doivent néanmoins vérifier de quels signaux, requêtes et fonctions propres à une plateforme dépendent leurs flux de travail.
La centralisation nécessite une configuration
Omni peut réunir des données provenant de plusieurs comptes et régions, mais les équipes ne doivent pas supposer que l’activation de son interface agrège automatiquement la télémétrie de tous les comptes. La documentation de configuration d’AWS décrit la création de domaines et d’espaces, puis la configuration de la manière dont les données de télémétrie provenant de plusieurs comptes sont rassemblées dans un espace. Les données CloudWatch existantes peuvent être consultées sans réinstrumentation, mais l’organisation doit tout de même configurer les accès et les flux de données souhaités. Les instructions de configuration d’Omni
Cette distinction compte autant pour le déploiement que pour les coûts. La page tarifaire d’AWS distingue les frais d’ingestion, de stockage et d’analyse des données de télémétrie. Elle décrit également les frais liés aux copies centralisées supplémentaires, tandis que la première copie centralisée est gratuite selon la tarification indiquée. Les coûts des requêtes dépendent des données analysées et des quotas ; les évaluations d’agents sont facturées selon les tarifs d’Amazon Bedrock AgentCore Evaluations. Une estimation utile doit donc tenir compte du volume, de la durée de conservation, des types de requêtes, des copies et de la fréquence des évaluations, et pas seulement du nombre d’agents.
Les traces et les accès doivent être examinés
Les traces d’agents peuvent contenir des invites, des réponses, des documents récupérés et des informations personnelles. AWS indique qu’Omni ne détecte ni ne masque automatiquement les informations personnelles identifiables. Ses consignes relatives aux données sensibles recommandent de choisir où le filtrage est effectué ; le masquage au moment de la capture est l’option qui empêche les contenus sensibles de quitter l’application.
AWS indique également qu’Omni n’utilise pas le contenu des clients pour entraîner des modèles de fondation ni pour améliorer Omni lui-même. Cela ne signifie pas qu’aucun contenu n’est traité ailleurs : certaines fonctions transmettent des données à des services tels que Bedrock ou AgentCore, et AWS documente l’inférence interrégionale pour les fonctions d’IA. Les données restent stockées dans la région de l’espace, mais les requêtes d’IA peuvent être traitées ailleurs, au sein de la même zone géographique. Les équipes doivent examiner la politique d’utilisation des données d’AWS et les détails de l’inférence interrégionale, surtout si leurs politiques limitent les lieux où le contenu des traces peut être traité.
Les contrôles d’accès méritent autant d’attention que le pipeline de télémétrie. AWS indique que, par défaut, les membres d’un espace peuvent lire toutes les données de télémétrie qu’il contient ; les périmètres de données peuvent limiter les lignes de journaux et de traces visibles par un membre. Toutefois, ces périmètres ne masquent pas les champs d’une ligne et ne remplacent donc pas le masquage des contenus que certains utilisateurs ne devraient jamais voir. Les contrôles de visibilité des membres
Évaluer Omni de façon mesurée
Pour les équipes qui utilisent déjà CloudWatch, un test limité peut montrer si la vue partagée des applications et des agents d’Omni aide à gérer un flux de travail réel. Avant d’envoyer des traces de production, déterminez les signaux nécessaires, configurez le filtrage, définissez les accès aux comptes et aux régions, puis estimez les coûts d’ingestion, de stockage, d’analyse et d’évaluation. Comparez ensuite les investigations générées et les résultats des évaluations aux procédures d’incident actuelles.
Pour les organisations qui utilisent d’autres plateformes d’observabilité, ce lancement est une raison d’évaluer le flux de travail, pas à lui seul une raison de migrer. Omni rapproche les signaux de qualité des agents des opérations applicatives, mais sa valeur dépendra de l’utilité des investigations, de l’adéquation des contrôles et du coût des flux de données.
