> ## Content Index > Fetch the complete content index at: https://www.sfeir.dev/llms.txt > Use this file to discover other available public pages before exploring further. # Classification de texte en entreprise : arrêtez de demander à votre LLM de trier le courrier. - URL: https://www.sfeir.dev/ia/classification-de-texte-en-entreprise-arretez-de-demander-a-votre-llm-de-trier-le-courrier/ - Published: 2026-10-14T12:15:00.000Z - Updated: 2026-10-14T12:15:00.000Z - Description: Envoyer 100 % des tickets IT à un LLM pour du tri, c'est convoquer un comité d'experts à l'accueil. Benchmark sur 20 000 tickets : nous comparons SaaS décisionnel, LLM local et modèle spécialisé. Bilan : enseigner vos règles métier à un petit modèle bat le zero-shot et valide le pattern hybride. - Author: Gilles Stenger - Tags: Agent IA, IA, IA Générative, JEV, Laya, IA Décisionnelle, agents IA, Agentic AI *Dès qu'un texte entre dans un système d'information, le réflexe est toujours le même : appeler un LLM. Mais router un email ou trier un ticket, est-ce vraiment un travail pour Shakespeare ?* L'engouement autour des [LLM](https://www.sfeir.dev/data/comment-demarer-un-projet-llm/) propriétaires — [OpenAI](https://www.sfeir.dev/ia/introduction-a-lutilisation-des-modeles-dia-generative-creez-votre-propre-chatbot-2/), [Anthropic](https://www.sfeir.dev/ia/claude-quand-les-modeles-dia-parlent-le-langage-de-la-litterature/), [Google](https://www.sfeir.dev/ia/google-i-o-2026-face-au-mirage-conversationnel-lempire-contre-attaque/) — a installé un réflexe d'architecture presque pavlovien : dès qu'un texte entre dans un système d'information, [on appelle un LLM](https://www.sfeir.dev/ia/devops-agentique-et-si-le-llm-ne-devait-pas-tout-decider/). Besoin de trier un ticket ? LLM. Besoin de router un email ? LLM. Besoin de déterminer si une demande concerne le support, la facturation ou les RH ? Encore un [LLM](https://www.sfeir.dev/ia/modeles-de-fondation-la-base-pas-si-simple-de-lia-generative/). Et pourtant, une grande partie des problèmes métier que nous rencontrons en entreprise ne demandent absolument pas de générer du texte. Ils demandent simplement de prendre une décision parmi quelques choix connus: - Aiguiller un ticket support vers l'un des 10 départements. - Attribuer un niveau de priorité. - Router un email vers le bon service. - Identifier une catégorie de non-conformité documentaire. Détecter le type d'incident remonté à un SOC. La question est souvent aussi simple que : « Parmi ces N catégories, laquelle correspond le mieux à ce texte ? » C'est précisément ce problème que cherchent à résoudre les nouveaux modèles de décision comme Jev de TypeSafe. Et c'est une approche intéressante. Mais elle pose une autre question : Que se passe-t-il si, au lieu de demander à un modèle SaaS généraliste de comprendre notre métier en zero-shot, on prend un petit modèle local et qu'on lui apprend directement à partir de nos propres données ? Nous avons voulu le vérifier. Pour cela, nous avons pris un historique de 20 000 tickets d'assistance IT, isolé 500 tickets pour le test, et comparé plusieurs approches : modèle décisionnel SaaS, LLM local et petit modèle discriminant fine-tuné. Le résultat est assez contre-intuitif. ### **1\. Système 1 vs Système 2 : faut-il vraiment sortir le bazooka ?** Pour simplifier le problème, imaginons deux manières de traiter un ticket entrant. ![](https://storage.ghost.io/c/0b/31/0b31478e-a66a-46f1-8c34-d44388e21192/content/images/2026/10/data-src-image-2c3a62c8-ef68-449f-8c7f-d775862acf47.jpeg) Ici « Système 1 » et « Système 2 » sont vus comme une métaphore d'architecture, et non comme une transposition littérale des mécanismes cognitifs humains. Le **Système 1** est notre classifieur : un modèle compact qui transforme le texte en représentation vectorielle et choisit une catégorie. Pas de rédaction. Pas de paragraphe. Pas de réponse en langage naturel. Juste une décision. Le **Système 2**, lui, est notre LLM généraliste. Il peut prendre davantage de contexte, suivre des instructions complexes et intervenir lorsque la situation sort du cadre prévu. Le problème apparaît lorsqu'on demande systématiquement au Système 2 de faire le travail du Système 1\. Envoyer 100 % des tickets IT à un grand modèle génératif pour savoir s'ils relèvent de *Billing* ou de *Technical Support*, c'est un peu comme convoquer un comité d'experts pour trier le courrier à l'accueil. Ça fonctionne. Mais est-ce vraiment nécessaire ? ### **2\. Quatre approches pour un même problème** Pour notre expérience, nous avons comparé plusieurs façons de faire. ![](https://storage.ghost.io/c/0b/31/0b31478e-a66a-46f1-8c34-d44388e21192/content/images/2026/10/Gemini_Generated_Image_54mdqc54mdqc54md.jpg) **Option A — Le LLM génératif classique** C'est l'approche que nous connaissons tous. On envoie par exemple : *« Analyse ce ticket et réponds uniquement par le nom du département. »* Le LLM comprend le contexte puis génère sa réponse. C'est flexible, immédiat et particulièrement intéressant lorsque les catégories sont nouvelles ou que la tâche nécessite une compréhension générale. Mais pour une simple classification, il y a tout de même quelque chose d'assez étrange : on utilise un moteur de génération pour produire un résultat qui ne contient finalement qu'un label. **Option B — Le LLM contraint** On peut réduire le problème. Au lieu de demander au modèle de rédiger une réponse, on lui donne un espace de sortie très limité : - A = Billing - B = Technical Support - C = Customer Service - D = Human Resources et on lui demande de choisir. Lorsque l'API le permet, les logprobs permettent en plus d'obtenir un signal probabiliste sur les tokens produits. On conserve ainsi la compréhension générale du LLM tout en supprimant une partie de la génération inutile. Mais on reste dépendant de l'API, du fournisseur et de la latence réseau. **Option C — Le modèle décisionnel SaaS : Jev** C'est là que Jev (de TypeSafe AI) devient intéressant. L'idée est de ne plus détourner un LLM génératif pour effectuer une classification. On utilise directement un modèle SaaS conçu pour prendre des décisions structurées. Il ne génère aucun texte : on lui fournit un texte brut, une question structurée (choix, score, oui/non) et les critères possibles, et il renvoie directement une décision typée, accompagnée d'un score de confiance. C'est exactement le bon problème. Mais une question subsiste : que sait-il réellement de mon entreprise ? Si je lui donne les dix catégories de mon service IT, il connaît mes catégories. Mais il ne connaît pas forcément les 20 000 décisions historiques qui expliquent pourquoi, chez nous, tel ticket est considéré comme *Technical Support* et tel autre comme *Customer Service*. [**Option D**](https://www.sfeir.dev/ia/devops-augmente-en-local-avec-un-petit-llm-peut-on-vraiment-en-tirer-quelque-chose/) **— Le LLM local : Qwen3 4B** Pour éviter une comparaison trop facile entre un SaaS décisionnel et un classifieur spécialisé, nous avons également ajouté un véritable LLM local au benchmark. Notre candidat : **Qwen3-4B**. Il s'agit d'un petit modèle de langage généraliste (4 milliards de paramètres), autorégressif et open-weights. C'est un LLM classique qui prédit les tokens, que l'on contraint ici à répondre par un unique label. L'intérêt est de vérifier si la capacité de raisonnement d'un petit LLM généraliste exécuté en local suffit en zero-shot, et s'il peut rivaliser avec un modèle discriminant entraîné sur nos données. **Option E — Le petit modèle local spécialisé : Laya** Dernière approche : **Laya**. Il s'agit d'un petit modèle discriminant (\~421M de paramètres) basé sur une architecture d'encodeur compact, exécutable en local sur nos serveurs. Comme Jev, il ne cherche pas à devenir un chatbot et ne rédige aucun paragraphe. Il calcule uniquement la probabilité d'appartenance à des catégories prédéfinies. Il apprend simplement les frontières entre les catégories. Et surtout : il apprend notre manière à nous de classifier les tickets. ### **3\. Le crash-test : 500 tickets que les modèles n'ont jamais vus** Nous disposions d'un historique de 20 000 tickets d'assistance IT. Nous avons conservé un jeu de test isolé de 500 tickets, qui n'a pas été utilisé pendant l'entraînement. La tâche était double : - prédire l'un des 10 départements ; - prédire l'un des 3 niveaux de priorité. Voici les résultats obtenus jusqu'à présent : Le but n'est pas de trouver « le meilleur modèle ». Le but est de comprendre ce que chaque approche apporte. ### **4\. Premier constat : la connaissance métier compte énormément** Le premier résultat saute assez vite aux yeux. Jev obtient **41,0 %** sur les 10 départements. Qwen3 4B (Zero-Shot) obtient **42,4**. Notre modèle local Laya en zero-shot fait légèrement mieux avec **44,8 %**. ### Accuracy : Prédiction des Départements Jev SaaS Zero-Shot 41,0 % Qwen3 4B Zero-Shot 42,4 % Laya Zero-Shot Base 44,8% Laya LoRA Apprentissage léger 57,8 % Laya Full FT Entraînement métier 62,0 % Mais le véritable saut apparaît dès que nous montrons au modèle l'historique métier. - Avec Laya LoRA : **57,8 %**. - Avec Laya Full fine-tuning : **62,0 %**. Même phénomène sur la priorité : ### Accuracy : Prédiction des Priorités Jev SaaS 57,0 % Qwen3 4B (Zero-Shot) 57,2 % Laya Zero-Shot 51,8 % Laya LoRA 65,6 % Laya Full FT 72,2 % La conclusion n'est pas que Jev est mauvais. C'est même tout le contraire. Jev résout le problème sans entraînement. Et c'est précisément sa force. Mais notre modèle local possède quelque chose que le modèle SaaS n'a pas : l'expérience de notre entreprise. ### **5\. Deuxième constat : un modèle peut être sûr de lui... et avoir tort** Un résultat nous a particulièrement surpris. *Jev affiche une confiance moyenne de 87 %, alors que son *taux de bonnes classifications* sur les départements n'est que de 41 %* sur notre jeu de test. Autrement dit, dans notre expérience, le modèle peut être très affirmatif alors même que la décision est incorrecte. Pour un [système de routage automatique](https://www.sfeir.dev/ia/ai-act-pourquoi-la-plupart-des-entreprises-ne-savent-toujours-pas-quelles-ia-elles-utilisent-reellement/), c'est un vrai sujet. Imaginez : - Ticket → Billing - Confiance → 87 % alors que le ticket devrait être envoyé ailleurs. Le problème n'est plus seulement : *« Est-ce que le modèle a raison ? »*mais aussi : *« Est-ce que son niveau de confiance nous permet de lui faire confiance ? »* À l'inverse, notre modèle local utilise une calibration des probabilités par *Temperature Scaling*. L'objectif est simple : faire en sorte que son score de confiance soit davantage corrélé à sa probabilité réelle de succès. Ce signal va devenir particulièrement utile pour notre architecture hybride. ### **6\. Troisième constat : le zero-shot n'apprend pas votre nomenclature métier** Notre nomenclature comporte dix catégories. Et, comme souvent en entreprise, elles ne sont pas représentées de manière parfaitement équilibrée. Certaines catégories sont fréquentes. D'autres beaucoup moins. #### 1\. Approche Zero-Shot Technical SupportSur-représenté Billing Customer Service (Ignoré) Human Resources (Ignoré) #### 2\. Après Full Fine-Tuning Technical SupportÉquilibré Billing Customer Service Human Resources Dans notre benchmark, l'approche zero-shot a complètement laissé de côté plusieurs catégories minoritaires comme *Customer Service*, *Human Resources* ou *General Inquiry*. Aucune prédiction. À l'inverse, *Technical Support*, très présent dans le vocabulaire des tickets IT, absorbe une grande partie des décisions. Après fine-tuning, la distribution est beaucoup plus proche de la structure originale du corpus. Le problème n'est donc pas nécessairement que le zero-shot « ne comprend pas ». C'est qu'il ne connaît pas les frontières de décision propres à notre entreprise. Et c'est exactement ce que le fine-tuning lui permet d'apprendre. ### **7\. Quand ajouter des précisions dégrade le résultat** Nous avons également testé une idée qui semblait plutôt raisonnable : rendre les critères plus précis. Par exemple : *Technical Support: software bugs, excluding internal IT or usage questions* Intuitivement, plus de détails devraient aider. Chez nous, c'est l'inverse. Le taux de bonne classification passe de 62,0 % → 56,6 %. Notre règle empirique est donc devenue assez simple : **pour un petit classifieur, mieux vaut des critères courts, affirmatifs et mutuellement exclusifs qu'une longue liste d'exceptions et de négations.** Ce n'est évidemment pas une loi universelle sur les encodeurs. C'est simplement ce que nous avons observé dans notre configuration. Mais c'est un bon rappel : lorsqu'on passe d'un LLM généraliste à un modèle spécialisé, il faut aussi changer notre manière de décrire le problème. ### **8\. Alors, faut-il remplacer les LLM par des petits modèles ou des** modèles **décisionnel?** Non. Ce serait d'ailleurs une assez mauvaise conclusion. La question n'est pas : *Petit modèle OU grand modèle OU modèle* décisionnel *?* La vraie question est : *Quel modèle doit traiter quelle requête ?* Et c'est là qu'une architecture hybride devient intéressante. ### **9\. Le pattern hybride : le petit modèle devant, le LLM derrière** Imaginons notre architecture de production : ![](https://storage.ghost.io/c/0b/31/0b31478e-a66a-46f1-8c34-d44388e21192/content/images/2026/10/data-src-image-a10d0a46-de6a-4eda-8876-b227be3e04c6.jpeg) Le principe est simple. Le petit modèle traite les cas évidents. Lorsqu'il est suffisamment sûr de sa décision, on route automatiquement. Lorsqu'il hésite, on escalade. [Vers un LLM. Ou vers un humain.](https://www.sfeir.dev/ia/agent-code-verification-faits-pull-request/) Le LLM n'est donc plus le moteur de classification. Il devient le filet de sécurité. ### **10\. Le LLM n'est pas supprimé. Il est mieux utilisé.** Prenons deux tickets. Le premier : *« Ma facture de mars contient deux prélèvements identiques. »* Le second : *« Depuis la migration, mes accès ne fonctionnent plus. Je ne sais pas si le problème vient de mon compte ou de la facturation. »* Le premier ressemble fortement à un cas de classification évident. Le second est ambigu. C'est exactement là que le pattern hybride prend son sens. ![](https://storage.ghost.io/c/0b/31/0b31478e-a66a-46f1-8c34-d44388e21192/content/images/2026/10/data-src-image-a2e611bb-ce1e-4000-bc35-dd3ec37674eb.jpeg) Le modèle le plus cher et le plus généraliste n'est appelé que lorsqu'il apporte réellement quelque chose. ### **11\. La vraie rupture n'est pas là où on l'attendait** *La comparaison est finalement instructive. Qwen3 4B obtient 42,4 % sur les départements, soit un résultat comparable à Jev (41,0 %) en zero-shot. Ce qui confirme que la vraie rupture n'est pas entre LLM génératif et modèle décisionnel SaaS — c'est entre zero-shot et fine-tuning.* Et dans les deux cas, le fine-tuning de Laya fournit un autre point de comparaison : *Que gagne-t-on en abandonnant le zero-shot pour apprendre directement sur les données de l'entreprise ?* C'est cette question qui nous intéresse le plus. ### **12\. Le vrai arbitrage** On peut finalement résumer les approches ainsi : ### Résumé des approches : Le vrai arbitrage | Approche | Type de Modèle | ConnaissanceMétier | Cas d'usageidéal | | --------- | ---------------- | ------------------------- | --------------------------------------------------- | | Jev | SaaS Décisionnel | Généraliste(Zero-Shot) | Bootstrapping immédiat,aucune donnée requise. | | Qwen3 4B | LLM Local | Généraliste(Zero-Shot) | Souveraineté, flexibilitépour de multiples tâches. | | Laya (ZS) | Encodeur Local | Généraliste(Zero-Shot) | Classification basiqueultra-rapide et locale. | | Laya (FT) | Encodeur Local | ✓ Spécialisé(vos données) | Production fort volume,précision et faible latence. | Il ne s'agit donc pas simplement de chercher le modèle avec le meilleur score. Chaque approche répond à un besoin différent. - **Jev** : je veux classifier maintenant, sans entraîner de modèle. - **Qwen3** : je veux un LLM généraliste, mais [local et maîtrisé](https://www.sfeir.dev/ia/cpu-cloud-souverain-mistral-europe/). - **Laya Zero-Shot** : je veux un modèle discriminant local sans entraînement. - **Laya Fine-Tuning** : j'ai des données et je veux que le modèle apprenne réellement mon métier. ### **Conclusion — Votre LLM n'a peut-être pas besoin de tout décider** La leçon que nous retenons de cette expérimentation n'est finalement pas : *« Les petits modèles sont meilleurs que les LLM. »* Ce serait beaucoup trop simple. La vraie leçon est plutôt : **un modèle n'a pas besoin d'être généraliste lorsqu'on lui demande de prendre une décision spécialisée.** Jev apporte quelque chose de nouveau et de pertinent : un modèle SaaS pensé pour la décision plutôt que pour la génération. Mais dès qu'une entreprise possède un [historique métier](https://www.sfeir.dev/ia/du-legacy-a-letat-de-lart-moderniser-avec-lia-sans-rejouer-le-big-bang/) suffisamment riche, une autre question apparaît : *Pourquoi demander à un modèle généraliste de deviner nos règles métier alors que nous pouvons les apprendre directement à partir de nos données ?* Dans notre expérimentation, le passage du zéro-shot au fine-tuning fait passer Laya de 44,8 % à 62,0 % de taux de bonnes classifications sur les départements, et de 51,8 % à 72,2 % sur les priorités. Le coût est évidemment déplacé : il faut préparer les données, entraîner le modèle et maintenir le pipeline. Mais le résultat est un modèle qui connaît réellement les frontières de décision de l'entreprise. Et le meilleur des deux mondes est probablement hybride : 1. Petit modèle [local](https://www.sfeir.dev/ia/cpu-cloud-souverain-mistral-europe/) pour les décisions évidentes. 2. LLM pour les cas ambigus. 3. Humain lorsque même le LLM hésite. Au lieu de mettre un LLM derrière chaque requête, on peut donc construire quelque chose de beaucoup plus intéressant. Le futur des architectures IA n'est peut-être pas de choisir entre petits et grands modèles. C'est de faire en sorte que le grand modèle n'intervienne que lorsqu'on a réellement besoin de lui. Et vous, dans vos architectures IA actuelles, quel pourcentage de vos appels LLM sert uniquement à faire du tri ou de la classification de texte ?