Une Plateforme IA Interne pour les Opérations Réseau

Pourquoi le construire à l’interne

Dès 2024, chaque ingénieur réseau collait déjà des configurations épurées dans des agents conversationnels publics. C’est un incident de fuite de données en attente, et c’est aussi passer à côté de l’essentiel : un assistant ne vaut que par son accès à votre environnement réel. Plutôt que d’interdire l’IA, nous avons construit une plateforme où l’utiliser correctement était aussi la façon la plus simple de l’utiliser.

L’objectif n’a jamais été un agent conversationnel. C’était trois résultats concrets : empêcher les données sensibles de fuir vers des outils grand public, donner à l’équipe réseau un assistant qui connaît réellement notre réseau, et réduire le travail d’investigation qui pèse sur la rotation de garde.

La couche plateforme

La fondation est Open WebUI, l’interface IA auto-hébergée open source devenue le standard de fait. Elle nous a donné le chat multi-utilisateurs avec contrôle d’accès par rôles, la gestion des modèles, des bases de connaissances avec RAG intégré et des intégrations d’outils personnalisées, le tout déployable sur notre propre infrastructure.

Derrière elle, deux familles de modèles :

• Des modèles ouverts locaux tournant sur des GPU dans nos propres salles serveurs, servis via une couche d’inférence compatible OpenAI. Nous avons fait tourner les candidats au rythme du domaine, pour retenir Qwen 2.5 en 7B et 14B pour les tâches mécaniques rapides, puis gpt-oss-20b d’OpenAI dès sa sortie, qui tient confortablement sur un seul GPU moderne grâce à son architecture à mélange d’experts. Les modèles locaux traitent tout ce qui touche aux données sensibles et chaque charge à haut volume où le coût par jeton des API ferait mal.
• Des API commerciales (Anthropic, OpenAI et autres) connectées à la même interface, sous conditions entreprise avec une politique explicite de non-entraînement sur nos données. Elles portent les tâches de raisonnement réellement difficiles, où la qualité du modèle domine le coût.

Exploiter les deux familles côte à côte nous a appris plus que n’importe quel banc d’essai : les petits modèles locaux sont d’excellents résumeurs, extracteurs et formateurs, et des architectes décevants. Router le travail mécanique vers les modèles locaux bon marché et le travail de jugement vers les API de pointe est devenu le principe d’exploitation central de la plateforme.

Des assistants spécialisés, pas un robot généraliste

Open WebUI permet d’envelopper un modèle de base avec une invite système, une base de connaissances et un ensemble d’outils, puis de le publier vers des groupes d’utilisateurs précis. Nous avons utilisé cela pour livrer un catalogue d’assistants étroits plutôt qu’un seul assistant générique. Chaque assistant possède exactement le contexte et les accès que son rôle exige, et rien de plus. Les bases de connaissances vivent dans des compartiments S3 à accès contrôlé, versionnées avec la documentation dont elles sont issues.

Le produit phare est le Network Expert. Il combine :

• Une base de connaissances RAG construite à partir de nos documents de conception, standards et livrables d’audit. Une leçon durement acquise : les exports CSV bruts et les tableaux se comportent très mal en RAG, alors nous avons converti les données d’inventaire en courts paragraphes narratifs avant l’indexation, ce qui a rendu la récupération nettement plus précise.
• Un outil qui interroge l’API NetBox en direct, pour que les réponses sur les équipements, baies, préfixes et circuits proviennent de la source de vérité et non d’un embedding périmé.
• Un outil qui interroge l’API GitLab, où chaque configuration d’équipement est versionnée, pour lire la configuration réelle de n’importe quel équipement avant de répondre.

Le résultat est un assistant capable de répondre à « quels équipements à Paris terminent encore le tunnel hérité, et quel serait l’impact d’une fenêtre de maintenance? » avec le vrai inventaire et les vraies configurations derrière la réponse. L’équipe s’en sert pour la planification des maintenances, les questions d’architecture et la vérification des bonnes pratiques.

Le gain inattendu a été l’intégration des nouveaux. Les recrues posent au Network Expert toutes les questions qu’elles hésiteraient à poser à un senior occupé, au rythme qui leur convient, et le temps avec les pairs est passé de la lecture guidée de documents à du vrai accompagnement pratique. Un spécialiste réseau arrivé après le déploiement l’a formulé ainsi :

« L’intégration a été fluide. J’ai étonnamment beaucoup aimé interagir avec le Network Expert. Il allait à mon rythme, répondait à mes questions en détail et était incroyablement compétent. Cela m’a permis d’absorber les connaissances très facilement. »

Le NOC assisté par IA

La deuxième application majeure s’appuie sur notre pile de supervision (Zabbix pour le SNMP et la disponibilité, Graylog pour les journaux, alertes distribuées vers PagerDuty et un canal Teams). La supervision vous dit que quelque chose ne va pas. La partie coûteuse est l’heure qui suit : se connecter aux équipements, lancer des commandes show, vérifier les changements récents, formuler une hypothèse. Nous avons construit un pipeline d’agents pour faire cette première heure automatiquement.

1. Agrégation et triage. Les alertes de Zabbix et Graylog arrivent dans un agent de triage en parallèle des notifications destinées aux humains. Il déduplique les répétitions, regroupe les tempêtes d’alertes en un seul incident (un lien WAN instable peut produire des dizaines d’alertes en aval : sessions BGP coupées, hôtes injoignables, rafales syslog), et corrèle par site, équipement et fenêtre temporelle. La sortie est un objet JSON propre et structuré décrivant l’incident.
2. Collecte de preuves. Un agent d’enrichissement prend ce JSON et rassemble le contexte : état en direct des équipements concernés via des identifiants en lecture seule, rôle et connexions prévus de l’équipement depuis NetBox, configuration actuelle et changements récents depuis GitLab, et lignes de journaux associées depuis Graylog. Tout est ajouté au dossier de preuves.
3. Investigation. Un modèle de raisonnement reçoit le dossier de preuves complété et produit un rapport d’investigation : cause racine la plus probable, hypothèses alternatives classées, preuves à l’appui de chacune, et prochaines étapes concrètes avec les commandes exactes à exécuter.
4. Livraison. L’ingénieur de garde reçoit le rapport en même temps que l’alerte d’origine. L’alerte continue de notifier un humain, et un humain effectue toujours chaque changement. L’IA arrive simplement avec les devoirs déjà faits.

L’effet sur la réponse aux incidents est exactement celui qu’on espère. Au lieu de partir d’une icône rouge et d’une montée d’adrénaline, l’ingénieur part d’un document qui a déjà consulté les compteurs d’interface, remarqué le changement de configuration de la veille et suggéré où regarder d’abord. Le temps de résolution baisse parce que l’investigation démarre à l’hypothèse trois au lieu de l’hypothèse zéro, et la qualité des escalades s’est améliorée parce que chaque transfert transporte ses preuves avec lui.

Garde-fous

Quelques limites ont rendu cette plateforme digne de confiance pour un usage en production :

• Identifiants en lecture seule et à portée restreinte pour chaque outil qu’un agent peut toucher. Aucun agent ne peut modifier l’état d’un équipement.
• Modèles locaux pour les contenus sensibles, API externes sous contrats de non-entraînement pour le reste.
• Chaque investigation générée par IA est étiquetée comme telle, avec ses preuves jointes, pour que les ingénieurs vérifient au lieu de croire.
• L’accès aux assistants et aux bases de connaissances suit l’appartenance aux équipes via le contrôle d’accès par rôles.

La plateforme a commencé comme un geste défensif contre l’usage clandestin de l’IA. Elle a fini comme l’outil interne le plus utilisé de l’équipe, et le patron d’architecture (une passerelle, plusieurs assistants étroits, des outils plutôt que du savoir statique) est la partie qui mérite d’être copiée.