Les tests réseau sont devenus plus complexes à mesure que les environnements combinent de plus en plus les architectures mobiles, segmentées et nativement cloud. Quand une panne survient, sa résolution peut nécessiter l'intervention simultanée de plusieurs experts. C’est un défi que Spirent Communications, rachetée par Keysight Technologies en octobre 2025, entend relever avec Luma son offre agentique pour les tests et l’assurance qualité réseau. « Quand un problème arrive, qu’il s’agisse de tests manuels ou automatisés, la prédiction des pannes, la recherche de la cause profonde et la mise en œuvre d'une solution restent des étapes fastidieuses et chronophages », a déclaré Anil Kollipara, vice-président de la gestion des produits chez Spirent, à Network World. Il ajoute, « ce problème est ancien, mais nous n'avions pas de solution adéquate pour le résoudre de manière exhaustive. C'est pourquoi nous avons introduit Luma ».

Une architecture multi-agents

Luma repose sur un graphe de connaissances spécifique au domaine, un moteur de règles déterministe et une architecture multi-agents. L’offre s’intègre pour l’instant dans Landskide, la plateforme de test réseau  de Spirent, utilisée principalement par les opérateurs, les fournisseurs de services et les hyperscalers pour les tests de performance avant production. L'objectif est d'étendre progressivement Luma à l'ensemble du portefeuille de Spirent. Cela comprend Velocity, son produit d'automatisation des tests, et VisionWorks, sa plateforme d'assurance de service réseau en temps réel.

Concrètement, Luma s’articule autour de trois piliers fonctionnels : la connaissance, la génération de cas de test et l'analyse des causes profondes. Sur le premier point, il traite les requêtes relatives aux spécifications techniques, aux flux d'appels, à la documentation produit et aux exigences de conformité. Le pilier « génération de cas de test » permet aux ingénieurs de décrire un scénario de test de manière conversationnelle et de laisser Luma le configurer au sein de la plateforme Landslide de Spirent. Enfin, le pilier « analyse des causes profondes » traite les journaux, les indicateurs clés de performance et les captures de paquets (PCAP) d'un test afin d'identifier le point de défaillance. Luma exécute ces flux de travail grâce à une architecture IA MoE (Mixture of experts). Par exemple, un agent est spécialisé dans le traitement et l'interprétation des fichiers PCAP. Un autre l’est dans la compréhension de la configuration du produit. Enfin, un troisième est expert dans la collecte de toutes ces informations et l'identification de la cause racine. « Nous disposons d'une dizaine d'agents, et nous continuons d'en ajouter, qui collaborent pour fournir au client un flux de travail complet », précise Anil Kollipara.

Une pointe de règles déterministes

L'un des principaux problèmes liés à l'IA est que les modèles de langage (LLM) ne sont pas déterministes et peuvent produire des informations erronées. Il s'avère que la meilleure façon de minimiser ces erreurs est de réduire l'utilisation des LLM, du moins pour le cas d'usage de Spirent. « Nous avons fait appel à des plateformes IA tierces, nous avons testé différents modèles de langage naturel (LLM), et nous avons rapidement réalisé que le LLM ne représente qu'une partie de la solution, et non la solution complète », a déclaré le responsable produit. « Dans Luma, le rôle du LLM ne représente qu'environ 10 % du total, et se limite au traitement du langage naturel. La majeure partie des connaissances du domaine est intégrée à la base de données RAG, ce graphe de connaissances que nous avons développé », ajoute-t-il.

Au-dessus de la couche de base de données, Spirent a ajouté des ensembles de règles déterministes liés au comportement de la pile de protocoles. « Nous avons constaté des cas où un problème survient chez un abonné chez qui un indicateur de performance clé (KPI) est erroné, et n'importe quel algorithme d'apprentissage automatique peut détecter un écart », a expliqué Kollipara. « Mais la cause profonde est difficile à identifier uniquement à l'aide d'algorithmes d'apprentissage automatique, car cela nécessite une connaissance approfondie du domaine et de la manière dont les protocoles sont structurés. L'intégration de cet ensemble de règles est essentielle pour obtenir ce caractère déterministe du résultat. »

Réduire le temps de résolution des pannes

L'un des principaux moteurs du produit est le manque d'expertise dans les différents domaines des réseaux modernes. Kollipara a souligné que les experts en télécommunications ne maîtrisent pas forcément le cloud natif, et inversement. Lorsqu'une panne affecte les deux sujets, sa résolution nécessite une coordination entre des équipes aux spécialisations variées.

Anil Kollipara a cité un exemple concret tiré d'un essai bêta. Un client a soumis un ticket d'assistance qui a transité par trois niveaux de support avant d'atteindre le service R&D. Entre la collecte des journaux, la disponibilité du client et les transferts entre équipes, la résolution du ticket a pris sept semaines. Lorsque Spirent a fourni les mêmes fichiers à Luma, le problème a été résolu en seulement deux minutes.