Aller au contenu

Classifier du texte avec BERT, un SLM ou une API LLM ?

BERT, SLM ou API LLM pour classifier du texte ?

Pour classifier du texte en 2026, trois familles de solutions coexistent. Il y a l'encodeur finetuné (BERT, RoBERTa, DeBERTa, CamemBERT), le SLM génératif en few-shot (Qwen, Llama, Phi) et l'API LLM en zero-shot (GPT, Claude). Sur une tâche cadrée avec des données annotées, l'encodeur finetuné est en général le plus précis et le moins cher à l'inférence. Sans données ni taxonomie stable, le LLM ou le SLM génératif prennent le relais.

Le réflexe du moment est de tout envoyer à une API LLM. C'est souvent le choix le plus cher et le moins précis sur une tâche de classification bien cadrée, et je le vois régulièrement en mission.

Cet article se concentre sur la classification de texte précisément, pas sur le choix SLM vs LLM en général. J'ai déjà posé cette grille de décision plus large dans quand choisir un petit modèle plutôt qu'un LLM. Ici, j'ajoute une option que cet article ne couvrait pas en détail, l'encodeur finetuné à l'ancienne, souvent oublié depuis l'arrivée de ChatGPT, alors que sur cette tâche précise, il reste redoutable.

Les trois familles pour classifier du texte

Chaque famille répond à un besoin différent selon ce que vous avez déjà en main, des données annotées, une taxonomie stable, ou aucune des deux.

L'encodeur finetuné (BERT, RoBERTa, DeBERTa, CamemBERT). Un encodeur ne génère pas de texte. Il lit une séquence et produit une représentation, qu'on branche ensuite sur une petite couche de classification. BERT et ses dérivés sont pensés pour ça depuis 2018. Pour le français, CamemBERT reste la référence, avec CamemBERTa (basé sur l'architecture DeBERTaV3) qui pousse les scores plus loin. Sur le benchmark FLUE, CamemBERTav2 atteint 95,63 % d'accuracy sur la tâche de classification CLS et 93,4 de F1 en reconnaissance d'entités sur FTB (CamemBERT 2.0, arXiv 2411.08868). Le prix à payer est réel. Il faut des exemples annotés, et chaque nouvelle classe demande un réentraînement ou au minimum un réajustement.

Le SLM génératif en few-shot (Qwen, Llama, Phi). Un petit modèle génératif fonctionne sans données au départ. On lui donne quelques exemples dans le prompt (few-shot) et il produit une sortie, qu'on force ensuite dans un format structuré (JSON avec le label). Il peut aussi être finetuné par la suite, comme je le détaille dans mon article sur comment entraîner un SLM. Son avantage, c'est qu'il gère les cas ouverts et les libellés qui ne rentrent pas dans une liste fermée, puisqu'il sort du texte plutôt qu'un score. Son inconvénient, c'est qu'il est plus lourd qu'un encodeur, et qu'il faut gérer la sortie structurée ainsi que l'incertitude du modèle.

L'API LLM en zero-shot (GPT, Claude). Zéro donnée, zéro infrastructure, un prompt suffit pour démarrer. C'est l'option la plus rapide à mettre en place, et souvent la première qu'on teste. Mais à l'échelle, le coût grimpe vite, la latence n'est pas maîtrisable puisqu'elle dépend d'un fournisseur tiers, les données partent hors de votre infrastructure, et la précision sur une tâche cadrée est en général inférieure à un modèle spécialisé sur cette tâche précise.

DeBERTa finetuné contre GPT-4 en zero-shot

Sur une tâche de prise de position (stance detection), un DeBERTa finetuné atteint 0,94 de F1 contre 0,58 pour GPT-4 en zero-shot (Bucher & Martini, arXiv 2406.08660). Sur une tâche de détection d'émotion dans du texte politique, le même papier mesure 0,89 d'accuracy pour l'encodeur finetuné contre 0,20 pour GPT-4.

Il faut lire ce chiffre pour ce qu'il est, pas plus. C'est une mesure sur des benchmarks précis, avec des catégories bien définies et un jeu d'entraînement disponible pour l'encodeur. Ce n'est pas une preuve que BERT bat systématiquement GPT-4 sur tout. L'encodeur gagne quand deux conditions sont réunies, des données annotées existent, et la taxonomie est stable dans le temps.

Ce qui explique l'écart, c'est la nature de la tâche. Classer, c'est choisir parmi un nombre fini d'options, exactement ce qu'un encodeur apprend à faire avec une couche de classification dessus. Un LLM en zero-shot, lui, doit deviner la bonne catégorie sans avoir jamais vu d'exemple annoté de votre taxonomie précise. Sur une tâche assez générale (sentiment positif/négatif basique), l'écart se resserre. Sur une tâche fine, avec des nuances propres à votre domaine, il se creuse.

Coût, latence et souplesse comparés

Au-delà de la précision, chaque famille a un profil très différent sur le coût, la latence et la capacité à s'adapter à une taxonomie qui bouge.

Critère Encodeur finetuné (BERT/DeBERTa) SLM génératif (few-shot) API LLM (zero-shot)
Précision sur tâche cadrée Très élevée, si données dispo Correcte, dépend du prompt Variable, souvent en retrait
Données nécessaires 200-500 exemples annotés par classe Aucune au départ, few-shot Aucune
Coût d'inférence au million de requêtes Très faible Faible à modéré Élevé, jusqu'à 100x plus
Latence Très faible, une seule passe Modérée, génération token par token Dépend du fournisseur
Souplesse si la taxonomie change Faible, réentraînement requis Bonne, on change le prompt Bonne, on change le prompt
Confidentialité / on-prem Totale, tourne sur votre infra Totale si auto-hébergé Données envoyées à une API
Explicabilité des scores Bonne, probabilité par classe Faible sans travail dessus Faible, pas de score natif

Sur le coût, l'écart est net et mesuré. Une étude de 2026 comparant encodeurs finetunés et prompting LLM sur quatre benchmarks de classification (IMDB, SST-2, AG News, DBPedia) chiffre le coût à 7,03 à 10,90 dollars par million de requêtes pour un encodeur finetuné, contre 463,20 à 2 701,89 dollars pour du prompting LLM sur les mêmes tâches (Valdés González, arXiv 2602.06370). L'écart peut dépasser un facteur 100 selon le modèle LLM choisi.

Sur la latence, la logique est mécanique. Un encodeur fait une seule passe avant et produit directement des probabilités par classe. Un modèle génératif doit produire du texte token par token, même pour répondre par un simple label, ce qui rend la génération nettement plus lente que le traitement du prompt en entrée. C'est pour ça qu'un encodeur reste imbattable en temps réel sur du volume, que ce soit pour de la modération, du routage ou du tri de tickets.

Quand choisir chaque option

La bonne question n'est jamais "quel modèle est le plus impressionnant", mais "qu'est-ce que j'ai déjà en main pour cette tâche précise".

L'encodeur finetuné est le bon choix dans ces cas de figure.

  • vous avez déjà, ou pouvez rapidement constituer, quelques centaines d'exemples annotés par classe ;
  • la taxonomie est stable et ne va pas changer tous les mois ;
  • le volume est important et la latence compte (modération en temps réel, routage de tickets, tri de flux) ;
  • les données sont sensibles et doivent rester sur votre infrastructure.

Le SLM génératif en few-shot devient intéressant dans ces situations.

  • vous n'avez pas encore de données annotées mais devez démarrer vite ;
  • la taxonomie est ouverte ou évolue régulièrement ;
  • vous voulez garder la possibilité de finetuner plus tard une fois les premières données collectées, en repartant du même modèle. J'ai déjà détaillé un cas concret de classification d'intentions avec un SLM, avec la démarche few-shot puis mesure.

L'API LLM en zero-shot se justifie dans ces cas.

  • le volume est faible et ne justifie pas d'investir dans un entraînement ;
  • vous testez un premier prototype avant de décider si le sujet mérite un encodeur dédié ;
  • la tâche sort du cadre d'une classification fermée et demande un vrai raisonnement (résumer puis catégoriser, croiser plusieurs signaux).

Ma méthode reste la même que sur tous les projets de classification. Je pars du besoin, pas du modèle le plus impressionnant du moment. Est-ce qu'on a des données annotées ? Est-ce que la taxonomie bouge ? Quel est le volume attendu ? Y a-t-il une contrainte de confidentialité qui impose de rester on-prem ? Ces quatre questions suffisent à trancher dans la grande majorité des cas.

Et si aucune donnée annotée n'existe encore, ce n'est pas une raison pour sauter directement sur l'API LLM à vie. Le bon enchaînement, c'est souvent de prototyper avec un LLM ou un SLM en few-shot, mesurer, utiliser les prédictions (relues) comme base d'annotation, puis finetuner un encodeur une fois qu'on a de quoi l'entraîner. On gagne le droit de finetuner, on ne se l'accorde pas par défaut, mais sur une tâche de classification qui tourne en volume, ce droit se gagne vite.

Gérer l'incertitude, quel que soit le modèle choisi

Un score de classification n'est jamais une certitude absolue, et le traiter comme tel est l'erreur la plus fréquente que je vois sur ce type de projet.

Sur un encodeur, on récupère naturellement une probabilité par classe. Sur un modèle génératif contraint à une sortie structurée, le constrained decoding force le modèle à choisir un label valide, mais ça peut masquer une vraie hésitation du modèle entre deux catégories proches.

Dans les deux cas, je préfère regarder l'écart entre le score de la classe la plus probable et celui de la deuxième. Si la marge est faible, mieux vaut ne pas comptabiliser la prédiction que de polluer une métrique métier avec un faux label. Une réponse "incertain" coûte moins cher qu'une fausse certitude, surtout si la classification alimente ensuite une décision automatisée.

Questions fréquentes sur BERT vs LLM pour la classification

BERT ou GPT pour classifier du texte ? Ça dépend de ce que vous avez. Avec des données annotées et une taxonomie stable, un encodeur type BERT/DeBERTa finetuné est en général plus précis, moins cher à l'inférence et plus rapide. Sans données et avec une taxonomie qui change, un LLM en zero-shot ou un SLM en few-shot est plus pragmatique.

Faut-il encore finetuner BERT en 2026 ? Oui, sur les tâches de classification cadrées. BERT et ses variantes n'ont rien perdu de leur pertinence depuis l'arrivée des LLM. Ce qui a changé, c'est le réflexe. Beaucoup sautent sur une API LLM sans vérifier qu'un encodeur finetuné ne ferait pas mieux pour moins cher.

Un LLM peut-il être plus précis qu'un encodeur finetuné pour classifier ? Sur une tâche ouverte ou sans données annotées, oui, faute d'alternative. Mais sur une tâche cadrée avec des exemples disponibles, l'encodeur finetuné dépasse en général largement un LLM en zero-shot, avec 0,94 de F1 contre 0,58 sur un benchmark de prise de position.

Combien de données faut-il pour finetuner un encodeur de classification ? Moins qu'on ne croit. Les performances saturent souvent autour de 200 à 500 exemples annotés par classe, si ces exemples sont représentatifs et bien répartis. La diversité compte plus que le volume brut.

Quel modèle choisir pour classifier du texte en français ? CamemBERT ou CamemBERTa restent les références pour un encodeur finetuné en français, avec de bons résultats sur les benchmarks comme FLUE. Pour un modèle génératif en few-shot, un petit modèle comme Qwen ou Llama en français fonctionne correctement, mais demande plus de travail sur la sortie structurée.

Un SLM génératif est-il meilleur qu'un encodeur pour classifier ? Pas sur une tâche fermée et cadrée. L'encodeur finetuné gagne presque toujours en précision et coûte moins cher. Le SLM génératif devient meilleur dès que la tâche est ouverte, que la taxonomie évolue souvent, ou que les données annotées manquent encore.

Quel est le coût réel d'une API LLM pour classifier du texte à grande échelle ? Il grimpe vite. Une étude de 2026 chiffre le coût à environ 7 à 11 dollars par million de requêtes pour un encodeur finetuné, contre 460 à 2 700 dollars pour du prompting LLM sur les mêmes tâches de classification, un facteur qui peut dépasser 100.

Pour aller plus loin

Si mes articles vous intéressent, que vous avez des questions ou simplement envie de discuter de vos propres défis liés à l'IA, n'hésitez pas à m'écrire à anas@tensoria.fr, j'adore échanger sur ces sujets !

Vous hésitez entre un encodeur finetuné et une API LLM pour votre projet de classification ? Découvrez mon activité de conseil sur tensoria.fr.

Vous pouvez aussi réserver un créneau d'échange ou vous abonner à ma newsletter :)

À propos de moi

Je suis Anas Rabhi, consultant Data Scientist freelance. J'accompagne les entreprises dans leur stratégie et mise en œuvre de solutions d'IA (RAG, Agents, NLP).

Découvrez mes services sur tensoria.fr ou testez notre solution d'agents IA heeya.fr.