Actualités Opsphere

Glama référence le connecteur Opsphere pour les investigations opérationnelles

Glama référence Opsphere — DevOps & SRE Intelligence sous io.opsphere.mcp-cursor. Une session Glama peut atteindre la passerelle distante Opsphere en Streamable HTTP et OAuth2 pour investiguer des bugs, évaluer la préparation d’une release, chercher des logs, trier des pannes, diagnostiquer une CI en échec, vérifier des déploiements et interroger les plateformes cloud connectées. Glama marque la propriété comme vérifiée et indique qu’OAuth fonctionne dans Glama.

La fiche inclut des sous-agents QA en lecture seule. Opsphere est en lecture seule par défaut. Les systèmes connectés restent la source des preuves. Opsphere ne copie pas cette télémétrie dans un autre magasin.

Google Analytics 4 : trafic et conversions dans les investigations opérationnelles

Opsphere interroge désormais une propriété Google Analytics 4 connectée pendant une investigation opérationnelle. Les outils en lecture seule couvrent le trafic, l’acquisition, les pages, les événements, les conversions, les tunnels, le temps réel et les métadonnées de la propriété. Le module ga4 reste désactivé tant que ce tenant n’a pas lié Google avec Connect Google et qu’un opérateur n’a pas activé les modules google et ga4. Google Analytics reste la source de ces résultats.

Quand ga4_default_property est défini dans Admin, les outils utilisent cette propriété. Des macros peuvent placer les variations de trafic et de conversion à côté des déploiements et des incidents. Ce récit n’affirme pas qu’un déploiement ou un incident a causé la variation. Opsphere est en lecture seule par défaut.

Google Search Console : performance de recherche dans les investigations opérationnelles

Opsphere interroge désormais une propriété Google Search Console connectée pendant une investigation opérationnelle. Les outils en lecture seule couvrent la performance, les requêtes, les pages, les tendances, la répartition par appareil et pays, l’inspection d’URL et les sitemaps. Le module gsc reste désactivé tant que ce tenant n’a pas lié Google avec Connect Google et qu’un opérateur n’a pas activé le module. Google Search Console reste la source de ces résultats.

Quand un appel omet le site, Opsphere utilise gsc_default_site depuis Admin. Pour le travail de release et d’incident, macro_seo_technical_diagnostic associe l’inspection d’URL Search Console à des contrôles HTTP et DNS. Opsphere est en lecture seule par défaut.

Google Tag Manager : configuration du conteneur dans les investigations opérationnelles

Opsphere interroge désormais un compte Google Tag Manager connecté pendant une investigation opérationnelle. Dix outils en lecture seule couvrent les comptes, les conteneurs, les balises, les déclencheurs, les variables, les versions publiées, l’état du workspace et les écarts de version. Le module gtm reste désactivé tant que ce tenant n’a pas lié Google avec Connect Google et qu’un opérateur n’a pas activé le module. Google Tag Manager reste la source de cette configuration de conteneur.

L’API Tag Manager reflète la configuration du conteneur, pas le déclenchement dans le navigateur. La validation de bout en bout associe cette configuration à macro_tracking_integrity_audit et à des contrôles HTTP. Opsphere est en lecture seule par défaut et ne modifie pas le conteneur.

Grafana : tableaux de bord, alertes et PromQL dans les investigations opérationnelles

Opsphere interroge désormais une instance Grafana connectée pendant une investigation opérationnelle. Douze outils en lecture seule couvrent l’état de l’organisation, les datasources, les tableaux de bord, les alertes en cours, les annotations, PromQL via une datasource Grafana et les définitions de checks Synthetic Monitoring. Le module reste désactivé tant que ce tenant n’a pas configuré ses identifiants. Grafana reste la source de ces résultats.

PromQL passe par le proxy de datasource Grafana et exige l’UID de la datasource Prometheus de ce tenant. Il complète les outils Prometheus directs déjà disponibles. Les outils Synthetic Monitoring renvoient la définition du check, pas l’historique des sondes. Opsphere est en lecture seule par défaut et ne copie pas la télémétrie Grafana dans un autre magasin.

Noibu : investiguer les erreurs e-commerce et les métriques de session depuis Opsphere

Opsphere relaie désormais Noibu pour l’investigation d’incidents e-commerce. Quinze outils ciblés couvrent la connexion du workspace et les contrôles en lecture seule : domaines de boutique surveillés, erreurs prioritaires, recherche d’incidents y compris le checkout, un diagnostic en langage clair et la tendance des occurrences. La connexion se fait une fois par workspace, via OAuth. Il n’y a pas de clé d’API statique à coller dans le chat.

Les métriques de session incluent conversion, rebond, revenu et trafic, ainsi que les sessions récentes et le trafic par page, les clics, la profondeur de scroll et les web vitals. Les fenêtres de highlights des sessions touchées sont incluses. Le replay de session, les heatmaps, les log drains, les expérimentations et toute écriture vers Noibu restent sur la console Noibu. Opsphere ne remplace pas Noibu.

Le module est disponible sur les plans payants et n’est pas activé sur Community. Associez-le aux contrôles de déploiement du storefront et aux flux d’incidents Datadog ou Sentry lorsqu’ils sont connectés. Les chiffres d’impact sur le revenu fournis par Noibu restent des projections Noibu.

Sentry : santé des releases par session, et une correction honnête des stats projet

L’intégration Sentry ajoute deux outils en lecture seule pour la Release Health. Les sessions peuvent être regroupées par release, avec le taux d’adoption sur la fenêtre choisie, et une release peut s’ouvrir pour ses métadonnées et sa part de sessions. Ils utilisent le même jeton d’authentification Sentry déjà configuré ; pas de nouveaux identifiants ni de slug d’intégration.

sentry_sessions_by_release lit les statistiques de session de l’organisation, regroupées par release. sentry_release_detail renvoie les métadonnées et la part de sessions d’une version sur cette fenêtre. Une fenêtre longue, par exemple 24 heures, inclut encore les sessions des releases plus anciennes du projet. Une fenêtre courte montre quelle part du trafic récent est déjà sur la nouvelle release. Les deux s’appuient sur les statistiques de session Sentry, pas sur la recherche d’issues.

sentry_projects_stats indique désormais le volume d’événements du projet. Ce n’est pas un graphique d’adoption de release. Le catalogue opérationnel complet d’Opsphere atteint 353 outils. Il s’agit d’une extension de capacités de l’intégration Sentry existante, pas d’un nouveau logo sur le hub.

Opsphere rejoint l'écosystème Santander X

Nous continuons à rapprocher Opsphere d'écosystèmes qui peuvent accompagner notre croissance technologique et entrepreneuriale.

Opsphere fait désormais partie de Santander X, l'écosystème mondial d'entrepreneuriat de Banco Santander pour les startups, les scaleups et les entrepreneurs.

Cette intégration nous ouvre de nouvelles opportunités, des avantages technologiques, des défis, des événements et des connexions au sein de sa communauté internationale.

Pour nous, c'est une occasion de plus de faire grandir Opsphere et de rapprocher notre plateforme d'intelligence opérationnelle de nouvelles équipes et organisations.

Xray Cloud : lire les tests manuels Jira, avec des écritures gouvernées si vous les activez

Opsphere se connecte à Xray Test Management for Jira Cloud pour que les agents lisent les tickets Test et leurs étapes manuelles. C’est une capacité d’assurance qualité aux côtés de Jira. Opsphere ne remplace pas Xray.

Deux outils sont en lecture : xray_test_get renvoie un ticket Test et ses étapes manuelles, et xray_tests_search recherche des tests et des doublons. Deux autres, xray_test_create et xray_test_steps_update, créent des tests et mettent à jour les étapes, mais restent désactivés tant que le tenant n’active pas les écritures.

Les identifiants sont le client id et le secret Xray, dans Jira → Apps → Xray, avec une URL de base facultative pour la région US ou UE. Le module reste désactivé tant qu’un administrateur ne l’active pas. Le catalogue complet atteint 341 outils. Community reste à 62 outils, et Xray ne fait pas partie de l’offre Community.

Un contexte opérationnel qui traverse les investigations

Le dépannage ne devrait pas repartir de zéro à chaque fois. Opsphere peut désormais construire une image opérationnelle ciblée de l'environnement investigué et réutiliser les connaissances pertinentes d'investigations précédentes lorsqu'elles aident à répondre à la question suivante.

La plateforme maintient des relations entre entités opérationnelles : comptes, environnements, services, dépôts et domaines. Ce contexte est récupéré de façon sélective — seulement lorsqu'il est pertinent pour la tâche en cours — plutôt que de déverser un inventaire d'infrastructure entier dans chaque conversation avec l'IA. Le contexte opérationnel est limité au tenant, au compte et à l'environnement concernés, selon le même modèle d'isolation que partout ailleurs dans Opsphere.

Les investigations précédentes peuvent être stockées comme mémoire opérationnelle structurée : contexte affecté, hypothèses, conclusions, références de preuves, recommandations et informations de vérification. Lorsqu'un nouvel incident ressemble à un cas déjà investigué, Opsphere peut faire remonter les cas précédents les plus pertinents comme contexte supplémentaire.

La télémétrie reste dans les systèmes qui la possèdent déjà. Opsphere n'a pas besoin de devenir un autre magasin d'observabilité : elle conserve les relations opérationnelles, la provenance et la connaissance d'investigation, et interroge les systèmes en direct lorsque des preuves actuelles sont nécessaires.

Diagnostics réseau : lookup CNAME et sondes d’origine directes depuis Cursor

Les diagnostics réseau intégrés interrogent désormais A, AAAA et CNAME en un seul appel dns_lookup via recordTypes, pour cartographier les hôtes d’origine sans dig. http_check envoie toujours des requêtes HEAD vers les URL publiques de chaque environnement, avec les mêmes valeurs par défaut.

Vous pouvez aussi sonder l’origine directement : en-tête Host personnalisé, ouverture TCP/TLS vers connectHost, et SNI TLS via servername. Ce contournement du CDN sert au triage des 502/520 — comparez codes de statut et en-têtes avec le edge public sans quitter Cursor.

Il s’agit d’une extension de capacités du module de diagnostics existant, accessible en Community : pas une nouvelle intégration, pas de logo sur le hub. Aucun nouvel outil, aucune credential. Cela s’articule avec les flux endpoint-health et d’incident, et se combine aux outils Cloudflare lorsqu’ils sont configurés.

Des investigations opérationnelles qui montrent leurs preuves

L'IA opérationnelle ne devrait pas passer d'un symptôme à un récit de cause racine asséné avec certitude. Opsphere structure désormais les investigations autour de plusieurs explications possibles et les confronte progressivement à ce que les systèmes opérationnels connectés rapportent réellement.

Les hypothèses peuvent porter sur les déploiements, la configuration, l'infrastructure, le comportement applicatif, les dépendances externes, le réseau, le CDN et d'autres domaines opérationnels. Les preuves collectées via de vrais appels d'outils peuvent étayer, infirmer ou laisser une hypothèse non résolue, tandis que les faits observés restent clairement séparés de l'inférence.

La confiance est calculée à partir des preuves disponibles : leur qualité, les sources indépendantes qui les corroborent et les contradictions. Lorsque les systèmes sources fournissent des horodatages, Opsphere construit aussi une timeline d'investigation à partir des preuves déjà collectées, sans requêtes supplémentaires inutiles.

Les conclusions et recommandations étayées peuvent inclure des conditions de vérification explicites : ce qui doit devenir vrai avant qu'un incident ou une résolution proposée soit considéré comme validé. Opsphere reste en lecture seule par défaut — elle investigue, corrèle et recommande, sans modifier silencieusement la production. Les investigations de haut niveau et les macros du gateway MCP peuvent renvoyer le même résultat structuré à Cursor, Codex et aux autres clients compatibles MCP.

Azure : outils KQL Log Analytics, recherche Blob et métadonnées Key Vault

L'intégration Azure inclut désormais quatre outils de données en lecture seule pour le triage d'incidents : KQL Log Analytics, découverte de clés Blob, et noms et métadonnées de secrets Key Vault. Ils utilisent la même session Azure déléguée déjà ouverte — aucun secret Opsphere ni slug d'intégration supplémentaire.

Interrogez Log Analytics avec du KQL en lecture seule lorsqu'un workspace est disponible. Trouvez des clés blob par préfixe ou nom exact sans télécharger le contenu. Listez les noms de secrets Key Vault et inspectez les métadonnées d'un secret — jamais la valeur. Utile pendant un incident données sans ouvrir le portail Azure.

C'est une extension de capacités sur l'intégration Azure existante, pas un nouveau logo sur le hub. Les outils données Synapse, Cosmos et ACR restent sur la feuille de route et ne font pas partie de cette version.

Cinq outils MCP en production : purge cache Cloudflare, métriques Datadog, logs de déploiement Vercel, traceroute et rollup d'incident

Cinq outils jusqu'ici marqués comme planifiés sont désormais généralement disponibles : purger le cache Cloudflare par URL, tag, hôte ou préfixe ; interroger des séries temporelles Datadog ; lire les logs de build et de runtime d'un déploiement Vercel ; lancer un traceroute depuis l'environnement Opsphere ; et obtenir une timeline d'incident en lecture seule. Ils utilisent les identifiants Cloudflare, Datadog et Vercel déjà configurés — aucun secret ni slug d'intégration supplémentaire.

La purge du cache Cloudflare est une écriture destructive, encadrée par une politique d'approbation. Le rollup d'incident est un instantané JSON en lecture seule ; le triage interactif d'une panne reste le workflow macro. Le traceroute diagnostique le chemin réseau depuis l'hôte Opsphere.

Cette livraison referme l'écart entre les lignes de la référence API encore étiquetées « planned » et la passerelle en production. C'est une extension de capacités sur des intégrations et diagnostics existants, pas de nouveaux logos fournisseur sur le hub.

Datadog : résultats d'exécution Synthetics et un up/down honnête par localisation

L'intégration Datadog inclut désormais un outil pour lister et inspecter les résultats d'exécution des tests Synthetic — succès ou échec pour un test nommé sur une fenêtre temporelle. Il utilise les mêmes clés API et App Datadog déjà configurées ; aucune nouvelle credential ni slug d'intégration.

Les synthèses par localisation suivent maintenant le dernier statut d'exécution de chaque test, pas le flag de configuration live ou paused. S'il n'y a aucune exécution dans la fenêtre, Opsphere signale ce vide au lieu d'un graphique de disponibilité à 100 % trompeur. L'inventaire et le statut de configuration restent sur le résumé Synthetics existant — cette vue n'est pas du pass/fail.

Le catalogue opérationnel complet d'Opsphere atteint 328 outils. C'est une extension de capacités sur l'intégration Datadog existante, pas un nouveau logo fournisseur sur le hub. Lorsque Datadog est connecté via Opsphere, les agents doivent utiliser ces outils plutôt que de demander une API Datadog locale.

Cloudflare Load Balancing : quatre outils en lecture seule pour les pools, origines et contrôles de santé

L'intégration Cloudflare inclut désormais quatre outils Load Balancer en lecture seule : inventaire des équilibreurs (filtre de zone optionnel), détail des pools, origines et steering d'un équilibreur, santé des pools du compte et configuration des moniteurs de santé — chemin, intervalle et codes de statut attendus. Ils utilisent le même jeton API Cloudflare déjà configuré ; aucune nouvelle credential ni slug d'intégration.

Les réponses sont mappées vers des champs adaptés aux agents, pas du JSON Cloudflare brut. Les listes vides sont valides si le compte n'a pas encore de pools ni de moniteurs — utile pour le triage du trafic edge, la santé des origines et le steering sans ouvrir le tableau de bord Cloudflare.

Le module Cloudflare totalise maintenant 54 outils sur la passerelle. Le catalogue opérationnel complet d'Opsphere atteint 327 outils — une extension de capacités sur l'intégration existante, pas un nouveau logo fournisseur sur le hub.

Opsphere apporte le contexte opérationnel dans Slackbot via MCP

Opsphere propose désormais une intégration Slack dédiée : activez la passerelle MCP distante comme application dans les conversations Slackbot, authentifiez la connexion et posez des questions en langage naturel sur toute intégration configurée sur votre plan souscrit — sans quitter Slack. La surface Slackbot est disponible sur tous les plans actuels ; les outils qui répondent suivent toujours les intégrations que vous avez connectées.

Le site public ajoute une page d’intégration Slack complète sur la configuration MCP, l’authentification et l’activation dans le chat, plus la découverte depuis le hub d’intégrations (Alerting et DevOps & Collaboration) et le carrousel de la page d’accueil.

Cette version étend Opsphere au-delà des éditeurs et du client web, jusque dans le chat où les équipes triagent déjà le travail — une passerelle opérationnelle, désormais accessible depuis Slackbot.

Opsphere publie une intégration Codex dédiée

Opsphere propose désormais une intégration de premier plan pour OpenAI Codex CLI et ChatGPT desktop — le même gateway MCP distant et la même surface d'outils opérationnels déjà utilisés dans Cursor, avec un plugin natif Codex, une installation marketplace et un client OAuth. Les ingénieurs peuvent enquêter sur les incidents, vérifier la santé des endpoints, diagnostiquer la CI, configurer des intégrations et ouvrir des contextes Connection Hub sans quitter la session d'agent.

Le site public ajoute une page Codex dédiée, calquée sur le récit produit Cursor mais avec une installation et des skills adaptés à Codex, plus la découverte depuis le hub d'intégrations (outils IA) et le carrousel de la homepage. La navigation regroupe Cursor et Codex sous Plugins pour garder les deux clients à un clic.

Cette publication renforce Opsphere comme couche opérationnelle partagée pour les éditeurs natifs IA : un gateway, des skills guidés et des flux d'investigation en lecture seule — que les équipes travaillent dans Cursor ou dans Codex.

AWS : diagnostiquer les agents Bedrock et les Lambdas des action groups

L’intégration AWS ajoute deux outils en lecture seule pour diagnostiquer les agents Bedrock avec la même session SSO ou IAM que vos autres outils aws_* — aucun nouveau secret Opsphere. L’accent est mis sur le diagnostic opérationnel (statut, alias, action groups, IAM, knowledge bases et findings), pas sur le produit Agent Core.

aws_bedrock_agent_diagnose renvoie en un appel la santé de l’agent, les alertes IAM, l’état des KB, les Lambdas liées et un graphe de relations. aws_lambda_agent_diagnose approfondit les Lambdas des action groups avec la config, les politiques IAM et les signaux d’erreur CloudWatch (valeurs d’environnement masquées). Le prompt guidé investigate-bedrock-agent exécute le même flux en lecture seule dans le chat web et les playbooks MCP.

Il s’agit d’une extension de l’intégration AWS existante — pas de nouveau logo fournisseur sur le hub. Le catalogue gateway Opsphere atteint 318 outils opérationnels.

AWS : outils Athena, recherche S3, requête DynamoDB et Aurora Data API

L’intégration AWS ajoute cinq outils en lecture seule pour investiguer le plan de données : SQL Athena, découverte d’objets S3 par préfixe ou clé, describe et Query DynamoDB (sans Scan), et SQL Aurora via l’API RDS Data. Ils utilisent la même session SSO ou IAM déjà connectée — aucun nouveau secret Opsphere ; les mots de passe restent dans votre Secrets Manager.

Interrogez Athena dès qu’un workgroup ou un emplacement de résultats S3 est disponible. Trouvez des clés S3 sans télécharger le contenu. Décrivez les clés et index DynamoDB, puis interrogez par clé primaire. Exécutez du SQL en lecture seule sur Aurora en HTTPS avec les ARN du cluster et du secret — utile en incident données sans ouvrir la console AWS.

Il s’agit d’une extension de capacités de l’intégration AWS existante, pas d’un nouveau logo sur le hub. Le catalogue gateway Opsphere atteint 312 outils opérationnels.

Cloudflare : 14 nouveaux outils en lecture seule pour Workers, Logpush, Snippets et KV

L'intégration Cloudflare inclut désormais 14 outils en lecture seule supplémentaires pour les opérations edge avancées — inventaire des scripts Workers, historique des déploiements, domaines personnalisés, jobs Logpush, Snippets de zone, listes de règles de compte, espaces de noms KV et paramètres de zone. Ils utilisent le même jeton API Cloudflare déjà configuré ; aucune nouvelle credential ni slug d'intégration.

Listez les scripts Workers, déploiements et domaines personnalisés depuis le compte. Inspectez les jobs Logpush et les règles Snippets de zone aux côtés des outils DNS et WAF existants. Consultez les listes de règles de compte et les espaces de noms KV sans ouvrir le tableau de bord Cloudflare — utile pour le triage d'incidents edge, les audits de listes WAF et les zones gérées par Terragrunt.

Le module Cloudflare totalise maintenant 49 outils sur la passerelle. Le catalogue opérationnel complet d'Opsphere atteint 307 outils — une extension de capacités sur l'intégration existante, pas un nouveau logo fournisseur sur le hub.

Connection Hub : une connexion Cursor pour chaque espace client

Consultants, agences et équipes plateforme gèrent souvent un tenant Opsphere par client — et basculer entre connexions IDE casse le flux pendant les incidents. Connection Hub est une capacité plateforme Opsphere propriétaire, pas une intégration fournisseur : il relie plusieurs espaces clients à une seule session Cursor via OAuth pour rester dans le même IDE en changeant de contexte opérationnel.

Liez les tenants clients avec ops_account_link_start, ouvrez un contexte de travail côté serveur avec ops_context_open et exécutez des outils opérationnels limités par context_id. La passerelle résout les identifiants côté serveur — rien de sensible dans la configuration IDE. Les skills plugin link-account et open-work-context guident l'onboarding ; les ressources MCP opsphere://hub/connections et opsphere://hub/active-context exposent l'état des connexions aux agents.

Les installations hub ne peuvent pas configurer d'intégrations ni exécuter d'outils opérationnels sans contexte de travail actif. Les grants sont chiffrés au repos. Cette version ajoute cinq outils de plan de contrôle broker au catalogue gateway ; la page d'intégration Cursor du site décrit désormais Connection Hub aux côtés du flux plugin officiel existant.

L'intégration Algolia prend en charge les Applications par environnement via Cloud Catalog

L'intégration Algolia d'Opsphere associe désormais chaque environnement Cloud Catalog — dev, staging, production ou vos propres slugs de catalogue — à sa propre Application Algolia. Configurez les Application IDs, index par défaut et clés API Search restreintes par environnement dans le Cloud Catalog admin ; les outils MCP Search API acceptent un env optionnel pour que des requêtes comme « lister les index en staging » résolvent la bonne Application plutôt que la production. Les diagnostics globaux de cluster restent sans credentials.

Les storefronts enterprise exécutent souvent des Applications Algolia distinctes par tier. Cette mise à jour aligne Opsphere sur ce modèle et évite les fuites de credentials entre environnements. La configuration legacy avec un seul Application ID et une clé API reste prise en charge pour les tenants mono-application.

La page d'intégration et la référence API du site décrivent désormais la configuration multi-environnement aux côtés des workflows existants de triage recherche et index.

Récupération mémoire opérationnelle améliorée et contrôles GDPR admin

La mémoire opérationnelle Opsphere fournit aux agents MCP un contexte distillé issu d'incidents passés, de notes de dépôt, de résumés de session et de décisions légères — pour que les enquêtes s'appuient sur des précédents plutôt que de reprendre le même terrain. La mémoire complète l'observabilité et les outils d'infrastructure en direct ; les agents vérifient toujours l'état courant avec Datadog, Kubernetes, Vercel et les autres sources opérationnelles.

Cette version améliore la récupération : recherche plein texte avec ranking pondéré sur le titre, expansion automatique multi-passes du vocabulaire ops et ranking heuristique qui priorise incidents actifs, décisions récentes et dépôts fréquemment utilisés. L'approche est calibrée pour de courts corpus opérationnels — récupération rapide sans latence d'embeddings ni infrastructure de recherche supplémentaire.

Les administrateurs tenant disposent aussi de contrôles de gouvernance dans le portail admin : lister et filtrer les éléments mémoire, invalider les entrées obsolètes avec motif et lancer une purge GDPR utilisateur avec aperçu dry-run — avec piste d'audit pour les purges. Les outils MCP en libre-service restent disponibles pour les utilisateurs qui ont besoin d'effacement sans intervention admin.

L'intégration Railway ajoute le triage des déploiements et du runtime PaaS à Opsphere

Opsphere s'intègre désormais à Railway, étendant la visibilité opérationnelle sur les projets PaaS, les déploiements et la santé runtime. Les équipes peuvent consulter le statut projet par environnements et services, inspecter les déploiements récents, extraire les logs build et runtime et lancer un diagnostic d'incident en lecture seule pour des hypothèses corrélées — le tout depuis le même espace opérationnel que Vercel, Kubernetes, Datadog et AWS.

Relier signaux de déploiement et logs Railway aux données d'infrastructure et d'observabilité aide les ingénieurs à déterminer si une panne vient d'une release échouée, d'un motif d'erreur runtime ou d'une dépendance en amont — sans alterner entre Railway, outils de monitoring et fil d'incident à chaque enquête.

Cet ajout poursuit l'expansion d'Opsphere comme couche opérationnelle unifiée, en aidant les équipes à corréler le triage PaaS avec livraison, observabilité et infrastructure dans une expérience cohérente en lecture seule.

L'intégration Algolia apporte la santé des index et de la recherche au contexte opérationnel

Opsphere s'intègre désormais à Algolia, étendant la visibilité opérationnelle sur l'infrastructure de recherche et la santé des index. Les équipes peuvent consulter l'état global du cluster et l'historique d'incidents sans identifiants, lister les index avec le nombre d'entrées et les métadonnées de build, reproduire des requêtes de recherche, valider des enregistrements indexés par objectID et examiner l'activité API récente — le tout depuis le même espace opérationnel en lecture seule.

Relier les données d'index Algolia aux déploiements, aux changements CMS et à l'observabilité storefront aide les ingénieurs à déterminer si un problème de recherche vient d'enregistrements obsolètes, de paramètres de ranking ou d'incidents en amont — sans alterner entre Algolia, Contentful CMS, Datadog et Sentry à chaque enquête.

Cet ajout poursuit l'expansion d'Opsphere comme couche opérationnelle unifiée, en aidant les équipes à corréler le triage recherche avec l'infrastructure, l'observabilité et les signaux de livraison dans une expérience cohérente en lecture seule.

Opsphere prépare le lancement de son plugin officiel pour Codex

Opsphere finalise le lancement imminent de son plugin officiel pour Codex et Cursor, conçu pour apporter l'intelligence opérationnelle et le diagnostic DevOps directement dans l'environnement de développement et l'interface de chat. S'appuyant sur une architecture MCP (Model Context Protocol) distante, le plugin permettra aux ingénieurs et aux équipes SRE d'enquêter sur les incidents, consulter les métriques, analyser les déploiements et exécuter des diagnostics réseau sur des plateformes telles que Datadog, Vercel, GitHub, AWS, Sentry ou Jira — sans quitter l'éditeur ni changer de contexte.

L'intégration d'Opsphere dans Codex et Cursor supprime la friction entre l'écriture de code et l'analyse de production. Grâce à des flux guidés en langage naturel, les équipes pourront réaliser des contrôles de santé d'endpoints, du triage d'incidents et l'analyse de défaillances de pipelines CI/CD en quelques secondes, le tout sous un modèle de permissions en lecture seule et une authentification OAuth2 qui maintient les identifiants entièrement protégés sur la passerelle distante.

Le plugin sera disponible publiquement dans les prochains jours et inclura une période d'essai gratuite avec le plan Community, consolidant Opsphere comme couche centralisée de contexte opérationnel et d'investigation pour les agents d'intelligence artificielle.

PagerDuty et Prometheus étendent la réponse aux incidents et la visibilité infrastructure

Opsphere s'intègre désormais à PagerDuty et Prometheus, enrichissant le contexte opérationnel pour le monitoring d'infrastructure et la gestion d'incidents. Les équipes peuvent consulter incidents actifs, services et timelines PagerDuty, tout en interrogeant métriques, alertes, règles, cibles de scrape et données PromQL Prometheus depuis la même interface.

Combiner métriques d'infrastructure et informations d'incident permet d'enquêter plus efficacement sans alterner constamment entre plateformes de monitoring et de gestion d'incidents. L'accès aux informations nécessaires pour comprendre la production s'en trouve accéléré.

Avec ces ajouts, Opsphere continue de se développer comme couche opérationnelle centrale reliant clouds, observabilité, CI/CD et outils d'incident management dans une expérience en lecture seule unifiée.

GitLab et SonarQube renforcent le workflow de livraison logicielle

Opsphere inclut désormais des intégrations natives GitLab et SonarQube, étendant la visibilité opérationnelle sur tout le cycle de livraison. Les équipes accèdent aux projets, merge requests, pipelines et historiques de déploiement GitLab, et consultent quality gates, métriques de code, security hotspots et analyses de nouveau code SonarQube depuis le même espace opérationnel.

Rassembler l'activité CI/CD et la qualité de code permet de comprendre rapidement ce qui a changé, si un quality gate a passé et comment les livraisons récentes se rapportent à la production. Moins de bascule entre plateformes pendant les investigations, plus de contexte développement aux côtés de l'infrastructure et de l'observabilité.

Ces intégrations poursuivent l'expansion de la plateforme opérationnelle unifiée d'Opsphere, connectant livraison logicielle et intelligence opérationnelle via une expérience cohérente en lecture seule.