Un assistant IA local peut-il diagnostiquer un problème réseau sans obtenir tout le réseau ?
La version open source de Transit laisse le choix entre un modèle local et un modèle hébergé. Les commandes, les identifiants et les données qui franchissent cette limite déterminent ce que l’outil peut examiner en sécurité.
Une agence signale que ses téléphones peuvent appeler mais reçoivent mal les appels. L’équipe réseau constate un changement d’interface, un événement de routage et plusieurs délais dépassés. Un assistant pourrait ordonner les observations et proposer la prochaine commande en lecture seule. Le choix du modèle ne résout qu’une partie de la tâche. La personne qui mène l’enquête doit aussi savoir quels identifiants l’outil peut utiliser, quel texte quitte la machine et si le modèle peut provoquer des changements.
Transit est un outil de diagnostic réseau qui a placé son client dans un projet open source sous Apache 2.0 le 21 octobre 2026. Sa page de transition fixe le 5 novembre comme date limite pour l’accès annuel et indique le 17 novembre comme date prévue de changement pour l’IA hébergée. Ces dates concernent la transition commerciale. La disponibilité du logiciel et la situation d’un compte hébergé sont des questions distinctes. Les versions publiées, le README et la documentation des fonctions sont les meilleures références pour la version qu’une équipe veut tester.
Ce que signifie local pendant une enquête
Choix du point d’accès au modèle. Illustration originale de Telli.sh.
Le client peut utiliser Ollama ou un autre point d’accès compatible OpenAI. Il documente aussi l’utilisation d’une clé OpenAI ou Anthropic et un aperçu de connexion pour les comptes ChatGPT Plus ou Pro admissibles. Un serveur Ollama sur le même ordinateur peut maintenir l’inférence sur cette machine. Un point d’accès d’entreprise reçoit les données sur son propre serveur. Un fournisseur cloud reçoit la demande après le masquage décrit par le projet.
Le client doit par ailleurs joindre les équipements réseau pour recueillir des preuves. Une enquête peut mobiliser un serveur de rebond, un compte en lecture seule et plusieurs appareils. Un modèle local ne limite pas les équipements que le client peut contacter. Cela dépend de la connectivité et des droits du compte.
Le dépôt décrit un nombre limité d’outils et une liste de commandes autorisées pour les fournisseurs pris en charge. Des règles configurées par l’opérateur peuvent approuver automatiquement les commandes correspondantes sur les systèmes compatibles. Le filtrage et le masquage forment des couches que l’équipe peut éprouver. Considérez les bannières et journaux des équipements comme du texte non fiable, surtout lorsqu’ils contiennent des ordres. L’assistant peut les résumer sans les prendre pour des instructions.
| Limite | Question pour l’opérateur | Essai utile |
|---|---|---|
| Point d’accès au modèle | Où la demande assemblée est-elle envoyée ? | Observer les destinations de connexion avec un cas fictif |
| Accès aux équipements | Quels appareils et comptes l’outil peut-il atteindre ? | Essayer un hôte explicitement hors périmètre en laboratoire |
| Approbation des commandes | Qui peut valider une action proposée ? | Refuser une commande et vérifier qu’elle ne s’exécute pas sur l’équipement |
| Preuves et journaux | Quelles données persistent ou quittent la machine ? | Utiliser des valeurs témoins inoffensives et inspecter les exports |
Des commutateurs et panneaux de brassage du type examiné par les équipes réseau. Photo de contexte de Dsimic, recadrée et redimensionnée, CC BY-SA 4.0. Source de l’image · Licence.
Construisez un pilote autour d’un défaut connu
Enquête réseau. Illustration originale de Telli.sh.
Montez un petit laboratoire avec un problème connu d’interface ou de routage. Donnez à l’outil un compte aux droits minimaux sur l’équipement voulu et ajoutez un hôte sans rapport qui doit rester inaccessible. Demandez une hypothèse et quelques observations capables de l’infirmer. Relisez une commande de consultation proposée avant de l’exécuter. Comparez le résultat à la même observation obtenue manuellement.
Pour le deuxième essai, donnez un symptôme ambigu. Plusieurs chemins réseau peuvent expliquer un service lent. Sur un réseau réel, une commande peut révéler des identifiants de clients. Des valeurs témoins fictives permettent de vérifier où les résultats sont transmis, enregistrés ou conservés. Séparez le laboratoire du serveur de rebond de production tant que les opérateurs ignorent ce que chaque mode expose.
Lors de l’export, rattachez la commande, l’heure, l’identité de l’équipement et le résultat pertinent à l’hypothèse qu’ils étayent. L’opérateur pourra suivre une chaîne de preuves au lieu de se rappeler quelle phrase venait du routeur et laquelle venait du modèle.
L’intégrité de la version et les limites d’un modèle local
Transit indique que ses versions ne sont pas signées. Le fichier SHA256SUMS associé à chaque version permet de vérifier que le téléchargement correspond à l’empreinte publiée. Cette comparaison n’authentifie pas à elle seule l’éditeur. Les équipes qui exigent des artefacts signés peuvent envisager une compilation à partir d’un tag examiné, dans leur propre circuit de distribution. La documentation d’installation Windows indique également qu’il faut PowerShell 7.
L’inférence locale peut réduire la dépendance à un fournisseur cloud et convenir à un environnement qui limite le partage. Un modèle local plus petit peut oublier des éléments, mal lire les résultats de plusieurs fournisseurs ou mettre plus de temps sur le matériel disponible. Comparez le même cas connu en local et sur un service hébergé approuvé si les deux sont autorisés. Mesurez les hypothèses correctes, les commandes inutiles, les associations au mauvais équipement et le temps total passé.
Pour commencer, attendez-vous à un outil qui recueille des preuves dans un périmètre limité. Désactivez l’approbation automatique et demandez à un opérateur de relire chaque proposition. Si le laboratoire produit des preuves cohérentes et un rapport défendable, identifiez les catégories de diagnostics en lecture seule qui pourraient suivre le même processus en production. C’est une décision plus concrète que d’ouvrir tout le réseau à un modèle.
Installez une version connue et notez ses limites
La version v6.5.11 corrige un décalage dans les noms du manifeste d’empreintes pour les faire correspondre aux noms normalisés par GitHub. Choisissez délibérément la version et la plateforme, puis contrôlez l’empreinte publiée avant de lancer l’installation. Lisez les notes de version et obtenez les fichiers auprès du dépôt officiel. Si votre organisation distribue les logiciels approuvés par un catalogue, suivez cette procédure même si l’empreinte correspond.
Le README décrit six outils d’enquête. Ce petit nombre aide si l’opérateur sait ce que chacun peut atteindre. Recensez le point d’accès au modèle, le serveur de rebond et le commutateur de test avant d’accorder des identifiants. Notez le compte qui a ouvert chaque connexion. Si une personne configure un serveur Ollama séparé, vérifiez l’adresse réellement contactée. Depuis l’ordinateur portable, un service du réseau de bureau reste une destination externe.
- Créez un cas de laboratoire avec un symptôme connu et un compte limité à l’équipement prévu.
- Vérifiez la version choisie et examinez le point d’accès, les identifiants et les réglages de conservation.
- Demandez à l’assistant la prochaine observation et une hypothèse que cette observation pourrait réfuter.
- Une fois l’approbation automatique désactivée, refusez une proposition et vérifiez le journal avant d’autoriser une autre commande sûre.
- Insérez des valeurs témoins inoffensives dans les journaux de test. Vérifiez si le client les masque et où elles apparaissent dans les traces locales ou au point d’accès configuré.
- Exportez les constats et demandez à un autre opérateur de reproduire le diagnostic avec les preuves enregistrées.
Une personne qui change parfois de fournisseur devrait refaire l’exercice après la modification. Le même bouton peut emprunter un nouveau chemin lorsque le point d’accès change. Dans un laboratoire autorisé, l’observation du réseau permet de vérifier les destinations. Une capture de l’écran de réglages ne prouve pas qui a reçu une demande.
Distinguez un commutateur compatible d’un shell générique
Le modèle de menace de la version Transit décrit une politique de commandes pour les fournisseurs compatibles. Une règle correspondante activée au préalable peut donner une approbation automatique. L’essai peut désactiver cette option et exiger une vérification humaine de chaque proposition. L’outil a toujours besoin d’un compte aux droits limités. Une boîte de dialogue de confirmation ne réduit pas les privilèges d’un compte de service.
Le même document décrit un régime différent pour Linux et Unix génériques. Le client affiche un avertissement, exige une approbation pour chaque commande et ne propose pas de règle d’autorisation permanente. La politique sous-jacente ne restreint pas les commandes sur les systèmes génériques. Écartez ce parcours du premier essai en lecture seule si l’organisation ne peut pas limiter les actions indépendamment. La catégorie de l’appareil et les droits du compte font partie de la sécurité.
Un deuxième cas de laboratoire peut montrer comment l’outil réagit à un résultat inconnu. Une commande peut renvoyer un compteur que le modèle ne reconnaît pas, ou deux fournisseurs peuvent nommer différemment une interface. Une bonne réponse cite l’observation d’origine et propose une vérification qui aide à départager les hypothèses. Une réponse plus faible présente une interprétation plausible comme un fait. L’équipe peut comparer les deux sans exposer un équipement de production.
Rendez l’export utile à l’équipe suivante
Un diagnostic d’une ligne peut suffire à la personne qui l’a posé. Pour prendre le relais, il faut la dernière observation confirmée, les causes écartées, les incertitudes et une vérification possible sans rouvrir toutes les sessions. Ajoutez la preuve à côté de chaque affirmation importante. Si le modèle change de diagnostic après une nouvelle entrée du journal, notez pourquoi.
La comparaison la plus utile inclut la procédure manuelle déjà utilisée. Mesurez le temps jusqu’à la première observation utile, le nombre de commandes superflues proposées et la durée de rédaction du passage de relais. Un modèle local peut améliorer la confidentialité s’il répond à la tâche assez vite. Pour un cas difficile, un modèle hébergé approuvé peut être plus pratique si les règles de données le permettent. Dans les deux cas, gardez les chemins de connexion et les preuves lisibles.
Suivez les destinations séparément
Un dossier de configuration utile indique ce qui est envoyé par l’interface, transmis au modèle ou collecté auprès des équipements. Il facilite la revue d’un changement de fournisseur. Séparez les règles de conservation de chaque destination. La suppression d’un historique local ne prouve pas qu’un point d’accès a effacé une ancienne requête.
| Mode | Destination de l’inférence | Vérification utile |
|---|---|---|
| Ollama sur le même poste | Adresse de bouclage | Confirmer que le processus atteint le service local voulu |
| Serveur d’inférence de l’entreprise | Adresse interne | Vérifier l’authentification du service et la conservation des demandes |
| Fournisseur hébergé | Point d’accès du fournisseur approuvé | Tester le masquage et les règles avec des données inventées |
| Connexion de compte en aperçu | Compte admissible auprès du fournisseur | Vérifier le compte utilisé et les contrôles administratifs disponibles |
Le tableau présente des configurations courantes. L’équipe doit observer les points d’accès et la configuration réels. Un écran de réglages peut afficher la même marque pour un service hébergé et une passerelle privée. Identifier le nom d’hôte et l’exploitant rend le flux vérifiable.
Vérifiez le masquage avec des données synthétiques
Préparez un journal fictif contenant une adresse IP inventée, un nom d’équipement imaginaire et une valeur qui ressemble à un identifiant client. Indiquez ce que la règle doit conserver, masquer ou supprimer. Essayez le même exemple dans deux opérations, comme un résumé de conversation et un export. Le système peut produire ces sorties différemment. Contrôlez chaque canal avant d’utiliser des données réelles.
Placez un deuxième marqueur dans une description longue ou un résultat mis en forme. Une règle peut repérer une valeur dans un champ connu et la manquer dans du texte courant. Si le résultat transmet encore la valeur à une destination non autorisée, fermez ce chemin avant de connecter le matériel de production. Réduisez le jeu de données et recommencez pour identifier le contrôle qui fonctionne réellement.
Réévaluez après une mise à jour
Après une mise à jour du client, notez le fournisseur sélectionné et relancez les mêmes cas de laboratoire. La liste des commandes ou la sélection des approbations automatiques peut changer ce que l’outil propose. Les valeurs par défaut du point d’accès peuvent modifier le trajet des preuves. Vérifiez ensemble un refus de commande, un cas de masquage et un diagnostic connu réussi. Ce petit ensemble de régressions facilite l’exploitation du logiciel lorsque l’environnement évolue.
Vérifiez les outils et le compte d’équipement séparément
Un outil de lecture peut renvoyer des métadonnées ou des preuves déjà collectées. Un outil d’exécution peut demander de nouvelles données à l’équipement à l’aide d’un compte connecté. Un résumé doit rester possible quand l’exécution est indisponible. Pour vérifier cette limite, déconnectez l’équipement en laissant le modèle accessible. La réponse doit distinguer une observation antérieure d’une nouvelle donnée qu’elle n’a pas pu recueillir.
Connectez ensuite un compte capable d’examiner un seul commutateur, sans passer en mode configuration ni atteindre un autre segment. L’équipe peut éprouver le refus dans son laboratoire sans demander à l’assistant de réaliser une vraie modification. Comparez le journal des propositions de l’application aux traces de connexion et de commandes de l’équipement. Cela distingue la décision de l’outil des droits que détient réellement le compte.
Sources
Pour retrouver facilement la trace des conversations et décisions liées à votre travail, créez un compte Telli.sh.