Contexte et objectif
Le 14 octobre 2026, SolarWinds Worldwide LLC a présenté Avior, une plateforme autonome d’intelligence artificielle destinée aux équipes IT d’entreprise. Le produit répond à un problème récurrent : les agents IA basés sur des modèles probabilistes peuvent produire des résultats différents d’une exécution à l’autre, ce qui crée des risques d’indisponibilité et d’audit. Avior vise à « ground probabilistic models in deterministic execution », selon le CTO Krishna Sai, afin de garantir que chaque action soit prévisible, traçable et réversible.
Architecture et mécanismes
Avior s’installe comme une application autonome sur la SolarWinds Platform. Il communique avec les systèmes tiers via le Model Context Protocol, éliminant ainsi la nécessité de migrer les données existantes. Cette couche d’abstraction permet d’interroger des environnements auto‑hébergés ou cloud sans reconfigurer les sources de vérité.
Le cœur du système repose sur un cadre fixe de goals (objectifs) et de contrôles d’approbation. Les modèles probabilistes calculent les actions nécessaires, puis le moteur déterministe les exécute dans l’ordre défini. Chaque workflow est journalisé, chaque action hérite des permissions de l’utilisateur qui l’a initiée et un mécanisme de rollback est intégré. Le processus de décision s’appuie sur 25 ans d’expérience de SolarWinds sur le comportement des environnements IT, ce qui fournit des heuristiques concrètes pour la priorisation des incidents.
Fonctionnalités opérationnelles
Au lancement, Avior prend en charge trois cas d’usage majeurs :
Fusion d’alertes : les alertes corrélées sont agrégées en un incident unique, réduisant le bruit opérationnel.
Détection et restauration de configurations : le système identifie les changements de configuration effectués hors des canaux habituels et restaure automatiquement la dernière configuration valide sur les appareils critiques.
Gestion de l’inventaire obsolète : les enregistrements d’appareils disparus mais toujours actifs dans le système de monitoring sont retirés, évitant les fausses alertes.
Le degré d’autonomie est modulé par un classement de risque interne. Les actions jugées « potentiellement dangereuses » requièrent une validation humaine explicite avant d’être exécutées. Les données transmises sont limitées au strict nécessaire, masquées et exclues de tout entraînement ultérieur des modèles.
Analyse d’impact et limites
Sur le plan de la fiabilité, la combinaison d’un calcul probabiliste suivi d’une exécution déterministe réduit les fenêtres d’incertitude, ce qui se traduit par une moindre exposition aux pannes liées à des décisions IA imprévisibles. La traçabilité complète des actions, associée aux permissions d’utilisateur, renforce la conformité aux exigences d’audit et de gouvernance.
En matière de sécurité, le modèle d’autorisation « action‑as‑user » limite les privilèges excessifs et le journal d’audit fournit une source d’investigation immédiate. Cependant, la dépendance à un protocole propriétaire (Model Context Protocol) introduit un point d’intégration qui doit être correctement sécurisé pour éviter des vecteurs d’attaque.
Les limites actuelles résident dans le périmètre fonctionnel : seules les fonctions de corrélation d’alertes, de gestion de configuration et de nettoyage d’inventaire sont disponibles. D’autres processus ITSM, comme la gestion des changements ou le provisioning automatisé, restent à développer. De plus, l’absence de tarification publique complique l’évaluation du retour sur investissement pour les organisations.
