Du tri assisté à l’action autonome
Selon The Register, le responsable des activités réseau de HPE prévoit que l’IA traitera tous les tickets d’incident sans intervention humaine d’ici deux ans. Son raisonnement repose sur une comparaison simple : les opérateurs pourraient finir par faire confiance aux agents comme les conducteurs font aujourd’hui confiance aux boîtes de vitesses automatiques, sans se préoccuper de chaque décision sous-jacente.
La prédiction est ambitieuse. Toutefois, traiter un ticket ne consiste pas uniquement à établir un diagnostic. Dans les opérations réseau, sa résolution peut nécessiter de collecter l’état des équipements, d’interpréter une politique, de modifier une configuration, de valider le service, de conserver des preuves et d’annuler le changement en cas d’échec.
La question essentielle n’est donc pas seulement de savoir si un agent d’IA peut agir. L’entreprise doit pouvoir démontrer ce qu’il a observé, pourquoi l’action était autorisée, ce qui a changé et comment le résultat a été vérifié.
Les conditions d’une automatisation fiable
Conserver les preuves avant toute exécution
Un agent doit partir d’un état opérationnel connu, et non d’une simple description parfois incomplète dans un ticket. Les éléments utiles peuvent inclure l’actif concerné, sa configuration actuelle, les versions précédentes, sa place dans la topologie, les vulnérabilités connues et son statut de cycle de vie.
Ce contexte doit également être conservé. Lors d’un contrôle ultérieur, l’équipe doit retrouver les informations dont disposait l’agent au moment de sa décision, pas seulement l’état présent du réseau.
Définir clairement les limites d’approbation
« Sans intervention humaine » ne doit pas signifier « sans gouvernance ». Toutes les actions ne présentent pas le même risque :
Les diagnostics en lecture seule peuvent être exécutés automatiquement.
Une remédiation standard et préapprouvée peut suivre un workflow défini.
Les changements à fort impact peuvent continuer à exiger une autorisation.
Toute action hors politique doit être bloquée ou transmise à un opérateur.
L’autorisation devrait dépendre de l’actif, de l’action, de l’environnement et de l’impact potentiel, plutôt que du seul niveau de confiance exprimé par l’agent.
Produire un historique complet des changements
Chaque changement automatisé doit laisser une trace exploitable. Les opérateurs doivent au minimum pouvoir déterminer :
Quel actif et quel ticket étaient concernés.
Quel état l’agent a examiné.
Quelle action il a choisie.
Si une approbation était requise et accordée.
Quelle configuration a été modifiée.
Comment le résultat a été validé.
Si un retour arrière a été nécessaire.
Sans cette chaîne de preuves, l’automatisation rapide risque de transformer le dépannage en enquête a posteriori.
Intégrer le retour arrière au workflow
L’exécution réussie d’une commande ne signifie pas que l’incident est résolu. L’agent doit effectuer des contrôles après changement en lien avec le problème d’origine. Si la validation échoue, le workflow doit s’arrêter, solliciter une intervention ou restaurer la dernière configuration fonctionnelle selon la politique établie.
Le retour arrière doit donc être conçu comme une étape de l’automatisation, et non comme une fonction réservée aux urgences.
Une adoption progressive
Il n’est pas nécessaire de passer directement d’un traitement manuel à une autonomie complète. Une démarche par étapes permet de rendre le risque opérationnel visible :
Observer : l’IA rassemble le contexte et propose des causes possibles sans effectuer de changement.
Recommander : l’agent prépare un plan de remédiation soumis à un opérateur.
Exécuter après approbation : les actions validées sont lancées automatiquement, avec collecte des preuves et sauvegarde de la configuration.
Automatiser les cas connus : les incidents répétitifs et bien délimités suivent des workflows préapprouvés.
Étendre sous conditions : l’autonomie n’augmente que lorsque la validation, le retour arrière et les traces d’audit ont démontré leur fiabilité.
La confiance repose ainsi sur des résultats opérationnels observables plutôt que sur une promesse générale d’intelligence.
Comment ConnectMyAssets peut aider
ConnectMyAssets fournit une base sur site pour encadrer l’automatisation d’infrastructures réseau multiconstructeurs. Ses modules peuvent apporter le contexte et les garde-fous nécessaires au traitement des tickets par l’IA :
Dynamic CMDB et Topology fournissent le contexte des actifs et de leurs relations avant la sélection d’une action.
Backup & History conserve les versions de configuration et permet un retour arrière en un clic si la remédiation n’apporte pas le résultat attendu.
Automation & ZTP permet de construire des workflows reproductibles plutôt que d’autoriser des modifications improvisées sur les équipements.
Compliance Engine aide à évaluer les changements au regard des référentiels et des exigences internes, tout en conservant les éléments de conformité.
Le suivi des CVE par actif et End-of-Life Tracking enrichissent la priorisation avec le contexte des vulnérabilités et du cycle de vie.
Credential Vault et SSH Bastion contribuent à maintenir les accès privilégiés dans des chemins opérationnels contrôlés.
Local AI Insights conserve l’analyse assistée par l’IA sur site, notamment lorsque les données réseau ne peuvent pas être transmises à des services externes.
ConnectMyAssets ne remplace pas la gouvernance. La plateforme apporte les historiques de configuration, le contexte des actifs, les mécanismes d’exécution contrôlée et les capacités de restauration nécessaires pour inscrire l’automatisation dans un modèle auditable.
L’autonomie est aussi une question de contrôle
La prédiction selon laquelle l’IA traitera tous les tickets met l’accent sur les capacités techniques. Pour les équipes responsables de l’infrastructure, l’enjeu durable reste toutefois la maîtrise des opérations.
Un agent peut être rapide sans être sûr. Il devient réellement utile lorsque ses droits sont limités, ses preuves conservées, ses changements attribuables et ses décisions réversibles. C’est à ces conditions que le traitement automatisé des tickets pourra passer d’une démonstration impressionnante à une pratique réseau fiable.
Source : The Register
