Vers une gestion de crise automatisée des incidents réseaux

Alliancy a récemment organisé avec Verizon un débat sur le futur de l’automatisation des réseaux. Pour Edwin Determann, Associate Director Solutions Architect pour Verizon, l’ère d’une « gestion de crise automatisée des incidents réseaux » approche à grand pas.

Que retenez-vous du débat organisé au sein de la rédaction Alliancy avec des directeurs du numérique sur le thème du futur de l’automatisation des réseaux et de la sécurité ?

Il était intéressant de constater que, selon les entreprises, les postures peuvent être très différentes. La volonté d’automatiser les réseaux augmente avec la taille et le caractère international des organisations, mais il est encore nécessaire de faire beaucoup d’évangélisation et de pédagogie sur les enjeux de ces transformations. Parmi nos clients, beaucoup d’organisations ont des stratégies de croissance externe et se retrouvent avec des systèmes d’information très fragmentés, aux normes et processus variés, qu’elles doivent harmoniser. La tâche est ardue lorsqu’on souhaite, dans ce cadre, instaurer une gouvernance plus centrale avec une même structure appliquée à l’ensemble des filiales et des entités locales. Il n’existe évidemment pas de recette unique pour y parvenir, mais le point commun réside dans la nécessité d’agir sur le management des réseaux et les règles de cybersécurité.

Ce chemin d’harmonisation peut aussi être l’occasion de « redécouvrir » son système d’information…

Oui, nous voyons des entreprises qui ont mis en place une gouvernance globale pour uniformiser réseaux et sécurité, en ayant conscience qu’entre différents pays, cela peut être difficile… Et elles découvrent, au fil du temps, des outils locaux, des serveurs qui existent un peu à part, des systèmes anciens qui ont été oubliés… Cela arrive très souvent ! On est très loin de morceaux de SI qui peuvent faciliter l’automatisation dans ces cas-là.

Quel est, pour vous, le dénominateur commun qui permet à une organisation d’avancer sur la voie d’une transformation profonde de ses réseaux et de sa sécurité numérique ?

Je pense que la volonté de la direction générale elle-même de centraliser est la clé de départ pour bien aborder les problèmes au niveau des infrastructures IT. Quand les grandes organisations ont des directions régionales et des directions des systèmes d’information dans chaque pays, avec leurs propres enjeux, c’est bien au PDG et la direction générale de créer le « choc de centralisation » autour de la recherche d’économies d’échelle, de l’amélioration de la qualité du service client ou de l’expérience employé. Il faut donner un sens stratégique à ces transformations, qui sont complexes. D’ailleurs, j’ai en tête des exemples de DSI ou de CTO qui ont essayé de s’attaquer au sujet sans un tel soutien de très haut niveau et, face à la résistance des métiers, ils ont fini par être évincés de l’entreprise… Heureusement, la proximité et l’intégration des DSI avec les processus métiers changent de plus en plus pour le mieux. C’est un facteur d’accélération sur ces sujets.

Et une fois ce soutien assuré, quelles sont les étapes suivantes ?

On peut alors se positionner sur le chemin de l’automatisation et du « network as a service »… Le CTO doit bien identifier les demandes les plus stratégiques des métiers afin d’y répondre. Côté offre, les possibilités sont là. Nous publions, par exemple, l’ensemble des API disponibles pour faciliter le pilotage des clients, ce qui leur permet d’intervenir directement sur les règles d’automatisation. Les freins se situent plutôt du côté des choix de gouvernance. Par exemple, de très grandes entreprises nous demandent encore spécifiquement de ne pas pouvoir accéder à ces capacités, pour qu’elles n’entrent pas en conflit avec leur cadre de « bon de commande » traditionnel… quitte à perdre toute flexibilité. Les approches d’achat de capacités réseau restent encore souvent très conservatrices, ce qui entraîne des conséquences en cascade sur ce qu’il est possible ou non de faire en matière d’automatisation, d’amélioration de la sécurité, etc.

Établir une cartographie des risques qui justifient ce chemin vers l’automatisation des réseaux n’est-il pas un moyen d’aider à faire évoluer les pratiques ?

Il est effectivement important de donner une visibilité transversale à l’entreprise : quel est le fonctionnement actuel des réseaux et leurs limites, qu’est-ce qui est résilient et moins résilient, quels sont les impacts d’un point de vue business et activité des métiers. Cela implique un suivi organisé de la part de l’IT. Une fois par mois, une fois par trimestre… Il faut tester les impacts d’incidents sur les systèmes. Nous le faisons, par exemple, sur des plages coordonnées pour nos clients, afin qu’ils puissent voir comment ils peuvent continuer à fonctionner, même en mode dégradé, quand des incidents réseau ont lieu. Le but est de ne pas s’arrêter aux indicateurs purement techniques, pour plutôt comprendre la finalité pour l’activité. Pour y parvenir, il faut mener des analyses de risques et un travail de documentation important. Beaucoup d’organisations font déjà des audits, mais cela n’empêche pas de passer à côté de certaines réalités métiers. Un cas classique, c’est une machine ou un processus qui n’est pas en train de fonctionner au moment précis de l’audit. Sur le papier, on a l’impression d’avoir une approche exhaustive, et malheureusement, en bout de chaîne, l’impact est complètement sous-estimé, parce qu’on n’est pas allé plus loin qu’un audit.

Pourra-t-on tout de même parvenir un jour à une forme de « gestion de crise automatisée » des incidents réseau ?

Ce n’est pas si loin ! Grâce à l’agentic AI, notamment. L’autonomie et l’automatisation des agents IA vont permettre de faire bouger les lignes, entre l’alerte de départ et la remédiation en tant que telle. Ces neuf derniers mois, nous avons déjà pu constater des avancées certaines. On voit des entreprises imaginer les « meilleurs scénarios » de réponse, en fonction d’indicateurs types qui remontent. Donc, d’un point de vue technologique, je pense que les possibilités sont là. En revanche, s’en emparer demande aux équipes de vraiment changer leur façon de voir la problématique et de passer à des approches « by design » en termes de sécurité et de résilience. Cela implique, par exemple, que les techniciens, les ingénieurs réseau ou sécurité, ne se connectent plus en direct aux systèmes et équipements. Ils doivent plutôt vérifier que les paramètres des systèmes de commande sont corrects pour pouvoir les déployer automatiquement sur les services cloud et virtualisés, selon les règles de l’art, à partir de modèles prédéfinis. C’est un changement de métier : leur travail n’est plus de faire du cas par cas manuellement, mais plutôt de penser la résolution globale des problèmes et leur automatisation. Leur expertise prend toute sa valeur pour conceptualiser et créer des réponses à l’échelle. Trop souvent, on a eu tendance à cantonner la sécurité et le réseau à des sous-domaines très limités, alors qu’il est urgent d’amener, au contraire, de la généralisation et de la transversalité. La maîtrise pour les entreprises viendra de cette évolution des métiers IT, réseau, sécurité, et d’un nouvel emploi plus pertinent de leurs compétences.