Il y a un problème que tout le monde a rencontré au moins une fois sans vraiment savoir comment s’en sortir : des milliers de lignes de texte libre, saisies par des humains différents, qui décrivent toutes à peu près la même chose — mais jamais avec les mêmes mots. Comment trier ça ? Comment faire émerger des catégories cohérentes depuis ce fatras de formulations ? C’est exactement là qu’un LLM local classificateur change la donne. Pas de données d’entraînement, pas d’API externe, pas de modèle supervisé à alimenter pendant des semaines. Juste un modèle de langage qui comprend ce que vous voulez dire, hébergé sur votre propre machine.
Pourquoi le clustering classique s'en sort mal.
Le réflexe habituel face à ce type de données, c’est d’aller chercher du côté du clustering non supervisé. K-means, DBSCAN, LDA… Ces méthodes ont prouvé leur efficacité sur des documents longs, riches en signal statistique. Mais sur des annotations courtes — une ou deux phrases — elles butent sur un problème fondamental : elles raisonnent sur des tokens, pas sur du sens.
Prenez deux phrases comme « ce code ne tourne qu’en environnement de test » et « non-production, aucun risque de déploiement ». Elles expriment exactement la même idée. Leurs vecteurs d’embedding sont pourtant suffisamment proches pour se retrouver dans le même cluster… mais pas toujours. Et quand le vocabulaire diverge davantage, le clustering peut les séparer complètement. Ajoutez à ça les modèles de topic modeling comme LDA, qui cherchent des co-occurrences de mots dans un corpus : sur des phrases d’une ligne, il n’y a tout simplement pas assez de signal. Vous obtenez des clusters nommés « test », « code », « sécurité » — des mots, pas des concepts.
Le matching par mots-clés ou expressions régulières ne règle rien non plus. Vous pouvez écrire des règles pour attraper « code de test » ou « non-production », mais vous raterez « uniquement utilisé pendant l’intégration continue », « fixture de développement », « jamais déployé en prod » — et des dizaines d’autres formulations qui disent pourtant la même chose.
Comment fonctionne un LLM local classificateur en mode zéro-shot.
L’idée de fond est simple, presque déconcertante de simplicité : plutôt que de laisser un algorithme découvrir des groupes, vous définissez vos catégories vous-même — à partir de votre connaissance métier — et vous demandez au modèle de langage d’y ranger chaque entrée.
Ça marche parce qu’un LLM traite du sens, pas des patterns de tokens. Deux phrases qui ne partagent presque aucun mot commun peuvent exprimer la même idée, et le modèle le sait. Des travaux de recherche récents ont d’ailleurs montré que de grands LLMs en mode zéro-shot se comportent de façon compétitive face à des modèles fine-tunés sur des tâches de classification de stance — sans une seule donnée labellisée.
Concrètement, le pipeline tient en trois composants. D’abord, une liste de catégories candidates, mutuellement exclusives, définies à partir de votre domaine. Ensuite, un prompt de classification structuré, avec une température très basse — autour de 0,1 — pour que le modèle reste cohérent d’une entrée à l’autre. Enfin, un LLM hébergé localement via un outil comme Ollama. Pas d’envoi de données à l’extérieur, pas de coût par requête, et une vitesse suffisante pour traiter plusieurs milliers d’entrées en une session.
Un pipeline en trois étapes, du texte brut aux catégories.
Dans la pratique, ça ressemble à ça. Une phase de prétraitement d’abord : on nettoie le texte des URLs, des formules creuses, des artefacts de formatage. On normalise certains termes récurrents. Cette étape seule peut réduire le budget de tokens d’environ 30 %, ce qui accélère sensiblement le traitement et améliore la cohérence des classifications.
Ensuite, la classification à proprement parler. Chaque entrée passe dans le LLM avec la liste des catégories et un prompt court qui demande un label et une brève justification. Avec Gemma 2 (9 milliards de paramètres) sur un MacBook Pro, 7 000 entrées ont été traitées en environ 45 minutes. Llama 3.2, plus léger, va plus vite mais se montre moins précis sur les cas ambigus, là où deux catégories se ressemblent un peu trop. Pour des runs longs, il vaut mieux prévoir des checkpoints toutes les centaines d’entrées — une interruption en cours de traitement serait dommage.
Enfin, l’analyse : agrégation des résultats, visualisation de la distribution. Dans le cas documenté par l’article source, plus d’un quart des entrées décrivaient du code non-production, et près de 22 % des cas où un framework de sécurité gérait déjà le risque. Ces deux catégories représentaient à elles seules la moitié du corpus — une information qu’aucune méthode classique n’aurait fait émerger aussi proprement.
Ce que cette approche ne résout pas.
Honnêteté oblige : ce n’est pas un outil universel. Si vos catégories sont définissables par des mots-clés simples, une regex fera le travail dix fois plus vite. Si vous avez des données labellisées, un classifieur supervisé sera plus rapide et moins coûteux en temps de traitement. Et si vous avez besoin de classer en temps réel à grande échelle, les embeddings avec un lookup nearest-neighbor sont nettement mieux adaptés.
Il y a aussi la question du volume. Au-delà de 100 000 entrées, un LLM local commence à montrer ses limites en termes de débit. Et si vous ne savez pas encore quelles catégories définir — si la taxonomie reste à construire — il vaut mieux commencer par un topic modeling exploratoire avant de passer à la classification LLM.
Un bon outil, au bon endroit.
Ce qui rend l’approche intéressante, c’est sa polyvalence dans une niche bien précise : des données texte de taille moyenne, sémantiquement riches, sans données labellisées disponibles. Tickets support, retours clients, descriptions de bugs, annotations métier… Le terrain d’application est large. Et le fait de pouvoir tout faire tourner en local — sans dépendance à une API, sans exposition des données — n’est pas un détail, surtout dans des contextes où la confidentialité compte.
La vraie difficulté n’est pas technique. C’est de définir des catégories qui tiennent la route : mutuellement exclusives, collectivement exhaustives. Le conseil à retenir : commencez par classifier manuellement une centaine d’entrées, repérez les catégories vers lesquelles vous revenez naturellement, et utilisez-les comme point de départ. Après ça, laissez le modèle faire le travail à l’échelle.
