Meilleur LLM pour le support technique en ESN (IT)

Mettre en place une ia support informatique local répond à une contrainte concrète des ESN : tickets, logs et runbooks contiennent des données clients couvertes par des clauses de confidentialité. Avec une ia support informatique local, ces éléments restent sur une machine que vous maîtrisez, et chaque réponse peut être rattachée à une source.

Cette page traite uniquement du support IT interne : qualification de tickets techniques, lecture de logs expurgés, recherche dans les runbooks, traçabilité et escalade. Le commerce, les remboursements et la traduction du service client sont couverts par le guide support client multilingue avec un LLM local.

Le plan : critères de choix, sélection de modèles, mémoire par quantification, débit et benchmarks, licences, puis chaîne de déploiement.

Ce que le support IT d'une ESN exige d'un modèle

Le support interne ne demande pas les mêmes qualités qu'un assistant généraliste. Quatre critères comptent :

• Fenêtre de contexte : un extrait de logs, un runbook et l'historique d'un ticket dépassent vite 30 000 tokens. Les modèles limités à 4 096 tokens (Snowflake Arctic Instruct) ou 8 192 tokens (Grok-1 (base)) sont écartés pour cet usage.
• Sortie structurée : le modèle doit produire un JSON stable (catégorie, gravité, équipe cible) que l'outil de ticketing peut consommer.
• Fidélité aux sources : la réponse doit citer le runbook ou la ligne de log utilisée, sinon la traçabilité est perdue.
• Licence : le modèle tourne souvent dans le cadre d'une prestation facturée, donc en usage commercial.

La sélection : sept modèles entre 68 et 85 Go en Q4

Les modèles ci-dessous sont les plus légers du catalogue de référence de cette page. Tous demandent un serveur ou une station à grande mémoire, pas un poste de technicien.

• Mistral Small 4 : 119B, Apache 2.0, ~72 Go en Q4, contexte 256 000. Premier choix par défaut grâce à sa licence permissive et son grand contexte. Poids sur la page Hugging Face de Mistral.
• Qwen 3.5 122B-A10B : 122B, Apache 2.0, ~73 Go en Q4, contexte 262 000. Le suffixe A10B indique environ 10 milliards de paramètres actifs par token, ce qui favorise le débit. Voir Alibaba sur Hugging Face.
• Nemotron 3 Super 120B : 120B, NVIDIA Open Model License, ~72 Go en Q4, contexte 128 000. Pertinent sur une infrastructure déjà équipée NVIDIA (NVIDIA sur Hugging Face).
• Laguna S 2.1 : 118B, OpenMDW 1.1, ~68 Go en Q4, contexte 262 144. Le plus léger de la sélection, orienté code, utile pour les tickets touchant scripts et pipelines.
• Qwen3.8 Flash Next 125B-A6B : 125B, licence « Autre (open weights) », ~72 Go en Q4, contexte 256 000. Licence à lire avant tout usage chez un client.
• Mistral Medium 3.5 128B : 128B, Modified MIT, ~74 Go en Q4, contexte 256 000.
• Mixtral 8x22B Instruct : 141B, Apache 2.0, ~82 Go en Q4, contexte 64 000. Contexte plus court, suffisant pour un ticket et un runbook, juste pour de longs extraits de logs.

Deux modèles sont limités par leur contexte de 32 768 tokens : dots.llm1 Instruct (142B, MIT, ~85 Go) et DBRX Instruct (132B, Databricks Open Model License, ~76 Go). Ils conviennent au tri de tickets, moins à l'analyse de logs.

Pour une équipe disposant de plus de mémoire, Step 3.5 Flash (196B, Apache 2.0, ~118 Go) et MiniMax-M2.7 (229B, Apache 2.0, ~138 Go) constituent le palier suivant.

Mémoire par quantification et matériel

Seules les valeurs Q4 proviennent du catalogue. Les autres niveaux sont des ordres de grandeur estimés par règle de proportionnalité, à confirmer sur chaque fiche.

Pour la classe 118B-128B :

• Q4 : 68 à 74 Go (catalogue)
• Q5 : ~82 à 90 Go (estimé)
• Q8 : ~120 à 135 Go (estimé)
• FP16 : ~236 à 256 Go (estimé)

Pour Mixtral 8x22B Instruct (141B) :

• Q4 : ~82 Go (catalogue)
• Q5 : ~97 Go (estimé)
• Q8 : ~150 Go (estimé)
• FP16 : ~282 Go (estimé)

Ces chiffres ne comptent pas le contexte : charger 100 000 tokens de logs ajoute plusieurs Go de cache. Prévoyez une marge d'au moins 15 à 20 % (estimé).

Côté matériel, un Q4 de 72 Go tient sur une machine à mémoire unifiée de 96 Go avec peu de marge, et plus confortablement sur 128 Go. Les pages Mac 96 Go et Mac 128 Go détaillent ces configurations. Sur PC, il faut additionner plusieurs cartes graphiques : voir le guide choisir un GPU pour un LLM local.

Débit et benchmarks : ce qui reste à confirmer

Aucun débit mesuré n'est publié ici pour ces sept modèles : les tokens/sec sont à confirmer sur votre matériel. Deux repères qualitatifs :

• Architecture MoE : à taille égale, un modèle à faible nombre de paramètres actifs (A6B, A10B) lit moins de données par token et génère plus vite qu'un modèle dense.
• Concurrence : une équipe de support envoie plusieurs requêtes simultanées. Un serveur comme vLLM traite les requêtes par lots et augmente le débit total, alors que llama.cpp reste le plus simple pour un flux unique en GGUF.

Pour les scores MMLU ou HumanEval, consultez l'Open LLM Leaderboard et les fiches du catalogue. Ces scores sont à confirmer modèle par modèle et mesurent mal le métier du support.

Un jeu d'essai interne est plus fiable : 50 tickets clos et anonymisés, avec la catégorie, la gravité et la résolution réelles. Mesurez le taux de bonne catégorisation, le taux de citations exactes du runbook et le nombre d'escalades à tort. La page benchmark local décrit la méthode de mesure du débit.

Licences : vérifier avant d'installer chez un client

• Apache 2.0 (Mistral Small 4, Qwen 3.5 122B-A10B, Mixtral 8x22B Instruct) : usage commercial permis, avec conservation des mentions de licence.
• MIT (dots.llm1 Instruct) : usage commercial permis, contraintes minimales.
• Modified MIT (Mistral Medium 3.5 128B) : les clauses ajoutées sont à lire, conditions à confirmer.
• NVIDIA Open Model License, OpenMDW 1.1, Databricks Open Model License : licences propres aux éditeurs, à faire relire avant déploiement en prestation.
• Autre (open weights) (Qwen3.8 Flash Next 125B-A6B) : conditions à confirmer au cas par cas.

Le guide LLM local en entreprise et RGPD complète ce point pour les données personnelles présentes dans les tickets.

Chaîne de déploiement : tickets, logs expurgés, runbooks, escalade

Une chaîne de support local tient en cinq étapes :

1. Expurgation déterministe : un script remplace adresses IP, noms d'hôtes, jetons et adresses e-mail par des identifiants neutres avant tout envoi au modèle. La table de correspondance reste hors du modèle.
2. Recherche dans les runbooks : les procédures sont découpées et indexées, puis le modèle reçoit uniquement les passages pertinents avec leur référence.
3. Qualification : le modèle renvoie un JSON avec catégorie, gravité, hypothèse de cause et sources citées.
4. Règle d'escalade : toute réponse sans source, tout incident de gravité haute et toute action modifiant la production passent à un technicien.
5. Journal : chaque échange est enregistré avec la version du modèle, la quantification, le prompt et les passages utilisés.

Pour l'interface d'équipe, Open WebUI se branche sur un serveur local. Le guide déployer un chatbot d'équipe sur l'intranet détaille l'installation, et architecture d'un agent local couvre l'appel d'outils.

FAQ

Q : Ces modèles tournent-ils sur le poste d'un technicien ?

Non. Le plus léger de la sélection, Laguna S 2.1, demande environ 68 Go en Q4, hors contexte. Le schéma réaliste est un serveur partagé ou une station à 96-128 Go de mémoire, interrogé par l'équipe via le réseau interne. Pour des machines plus modestes, le configurateur du site propose des modèles adaptés à la mémoire disponible.

Q : Faut-il affiner le modèle sur nos tickets ?

Pas en premier lieu. La recherche dans les runbooks, avec citations, apporte déjà le vocabulaire et les procédures de l'ESN sans réentraînement. L'affinage devient utile si le format de sortie reste instable ou si la catégorisation plafonne sur votre jeu d'essai. Il demande des données anonymisées et une vérification de la licence du modèle.

Q : Le modèle peut-il expurger lui-même les logs ?

Ce n'est pas recommandé. Un modèle peut oublier une adresse IP ou un jeton dans un long extrait. L'expurgation doit être faite par un script déterministe, testé et versionné, placé avant le modèle. Celui-ci travaille alors sur des identifiants neutres, et la correspondance avec les valeurs réelles reste dans un système séparé.

Q : Le modèle peut-il clore un ticket seul ?

Mieux vaut l'éviter au démarrage. Le modèle propose une qualification et une piste de résolution, puis un technicien valide. Après quelques semaines de mesure, certaines catégories à faible risque peuvent être automatisées, par exemple les demandes documentaires. Les incidents de production et les actions à privilèges restent soumis à validation humaine.

Q : Quel contexte minimal viser pour l'analyse de logs ?

Visez au moins 64 000 tokens, ce qu'offre Mixtral 8x22B Instruct, et de préférence 128 000 ou plus pour corréler plusieurs fichiers. Les modèles à 32 768 tokens obligent à découper fortement les extraits. Un grand contexte consomme plus de mémoire et ralentit la génération : filtrez les logs avant envoi.

Q : Cette sélection couvre-t-elle le service client ?

Non. Elle vise le support IT interne d'une ESN : incidents, logs, runbooks, escalade. Les échanges commerciaux, les remboursements et la traduction des conversations avec des clients finaux relèvent d'autres critères, notamment la qualité multilingue. Ils sont traités dans le guide consacré au support client multilingue avec un LLM local.

Conclusion

Pour une ia support informatique local en ESN, Mistral Small 4 et Qwen 3.5 122B-A10B forment le point de départ le plus sûr : licence Apache 2.0, contexte d'environ 256 000 tokens, 72 à 73 Go en Q4. Les débits et scores restent à confirmer sur votre matériel et vos propres tickets. Indiquez votre mémoire disponible dans le configurateur pour vérifier la compatibilité, ou parcourez le catalogue pour comparer licences et besoins en VRAM.