La question n’est plus de savoir si les LLM sont meilleurs que les modèles NLP traditionnels. La question utile est : quelle pièce de mon pipeline a besoin de chaque approche ? Cette liste de vérification est destinée aux équipes qui ont déjà un produit en production et qui hésitent entre remplacer leur stack classique (spaCy, scikit-learn, regex, CRF, embeddings statiques) par un modèle génératif, ou conserver les deux.
Chaque point est une décision vérifiable, pas une opinion. Si vous en cochez moins de la moitié, vous n’avez probablement pas encore besoin de migrer.
1. Définir la tâche avant de choisir la technologie
1.1 S’agit-il d’une extraction fermée ou d’une compréhension ouverte ?
Si vous devez extraire des champs selon un schéma fixe (dates, montants, numéros d’entreprise, entités d’un domaine précis), un modèle supervisé traditionnel avec un étiquetage propre gagne généralement en précision et en coût. Les LLM brillent lorsque le schéma change chaque semaine ou lorsque la sortie exige un raisonnement sur le texte.
1.2 Avez-vous besoin d’une reproductibilité exacte ?
Un classifieur de régression logistique sur TF-IDF renvoie la même prédiction pour la même entrée. Un LLM avec une température supérieure à zéro, non. Si votre produit est de l’audit, de la conformité réglementaire ou du scoring, la détermination exacte pèse plus que la fluidité.
1.3 Existe-t-il une métrique de référence ?
Avant de changer quoi que ce soit, fixez une ligne de base : F1 par classe sur un ensemble de test figé. Selon la documentation des fournisseurs de NLP classique, dans les tâches de classification de texte avec des catégories bien définies et des milliers d’exemples étiquetés, les modèles linéaires atteignent souvent des valeurs proches de celles des grands modèles, pour une fraction du coût. Sans cette ligne de base, vous ne pouvez pas justifier la migration.
2. Vérifier le coût réel, pas celui de la démo
2.1 Latence par requête
Un modèle classique sur CPU répond en millisecondes. Un LLM dans le cloud ajoute de la latence réseau et de génération. Pour un moteur de recherche interne ou une autocomplétion, cette différence est visible pour l’utilisateur. Cela ne fonctionne pas pour X : n’utilisez pas un LLM sur le chemin critique d’une interface exigeant une réponse inférieure à 200 ms, sauf si vous disposez d’un cache agressif ou d’un petit modèle local.
2.2 Coût par volume
Faites le calcul avec votre trafic réel : tokens d’entrée moyens × requêtes × prix du modèle. Un classifieur traditionnel entraîné une fois coûte pratiquement la même chose pour 10 000 que pour 10 millions d’inférences. Beaucoup d’équipes découvrent en production que 80 % de leurs appels concernent des tâches triviales qu’un modèle classique résolvait tout aussi bien.
2.3 Coût de maintenance de l’étiquetage
Le modèle classique exige d’annoter des données. Le LLM exige de rédiger des prompts, d’évaluer systématiquement et de surveiller les changements de version du fournisseur. Les deux ont un coût humain ; choisissez celui que votre équipe peut soutenir.
3. Vérifier la qualité avec vos propres données
3.1 Tester sur le domaine, pas sur des benchmarks publics
Un LLM peut obtenir un score élevé sur un benchmark général et échouer sur votre jargon. Cas concret qui apparaît fréquemment dans les équipes de support : un modèle classique entraîné avec des tickets historiques identifiait correctement la catégorie de réclamation de facturation parce qu’il avait appris les abréviations internes de l’entreprise ; le LLM général, sans exemples de ces abréviations dans le prompt, les confondait avec des noms de produit. La solution n’a pas été d’écarter le LLM, mais d’ajouter une étape de normalisation préalable avec le modèle classique.
3.2 Évaluer avec une stratification par difficulté
Séparez votre test en cas faciles, ambigus et adversariaux. Il est fréquent que le LLM gagne sur les ambigus et fasse match nul ou perde sur les faciles. Si votre distribution réelle est majoritairement facile, la moyenne trompe.
3.3 Mesurer l’hallucination, pas seulement la réussite
En extraction, un champ inventé est pire qu’un champ vide. Les modèles classiques échouent en renvoyant l’étiquette la plus probable ; les LLM peuvent fabriquer la valeur. Définissez une métrique d’abstention correcte.
4. Revoir les exigences de confidentialité et de déploiement
4.1 Les données peuvent-elles sortir de votre infrastructure ?
Si le texte contient des données personnelles, des contrats ou des informations médicales, l’envoi à une API externe exige une revue juridique. Un modèle classique local élimine complètement ce vecteur. Les LLM auto-hébergés existent, mais ils changent le profil de coût : il vous faut un GPU et quelqu’un pour le maintenir.
4.2 Devez-vous fonctionner hors ligne ?
Appareils sur le terrain, bornes interactives, environnements industriels : le modèle classique embarqué reste l’option pragmatique. Un petit LLM quantifié peut tourner en local, mais sa qualité sur des tâches complexes chute et doit être validée tâche par tâche.
5. Vérifier si le problème vient des données, pas du modèle
5.1 Volume d’étiquettes disponibles
Avec moins de quelques centaines d’exemples par classe, le modèle classique est insuffisant et le LLM en few-shot part avec un avantage. Avec des dizaines de milliers, l’avantage se réduit et le coût par inférence devient le facteur décisif.
5.2 Dérive du domaine
Si votre vocabulaire évolue rapidement (nouveaux produits, nouveaux jargons), le modèle classique se dégrade et il faut le réentraîner. Le LLM absorbe mieux le changement sans réentraînement, mais introduit de la variabilité. Un schéma robuste consiste à utiliser le LLM pour générer de nouvelles étiquettes et le modèle classique pour servir à l’échelle.
5.3 Langues et variétés
Les modèles classiques multilingues existent, mais leurs performances sur des variétés dialectales ou du texte informel sont irrégulières. Les LLM généralisent souvent mieux sur les langues à faibles ressources. Vérifiez néanmoins avec des échantillons réels : ne partez pas du principe qu’un grand modèle comprend votre variante locale mieux qu’un modèle entraîné avec vos données.
6. Décider de l’architecture hybride avant le remplacement
6.1 Schéma à deux étapes
Modèle classique pour filtrer et classifier le volume élevé ; LLM uniquement pour les cas dépassant un seuil de confiance. Cela réduit le coût et maintient la qualité là où elle compte.
6.2 Schéma de génération de données
Utilisez le LLM pour étiqueter un lot initial, révisez un échantillon humain et entraînez un modèle classique avec ces étiquettes. C’est une façon documentée en pratique de réduire le coût d’annotation sans renoncer à un serveur déterministe.
6.3 Schéma de secours
Si le LLM échoue ou renvoie une sortie qui ne valide pas le schéma, basculez vers le modèle classique. Ne laissez jamais une défaillance de l’API externe casser tout votre flux.
7. Liste de vérification finale avant de toucher à la production
- ☐ Je dispose d’une ligne de base mesurée avec mon propre test, pas avec des benchmarks publics.
- ☐ J’ai calculé le coût et la latence avec mon volume réel, pas avec une démo.
- ☐ Je sais quelles tâches exigent du déterminisme et lesquelles tolèrent la variabilité.
- ☐ J’ai revu la confidentialité et la localisation des données avec les personnes concernées.
- ☐ Je dispose d’une métrique d’abstention, pas seulement de réussite.
- ☐ Il existe un plan de secours si le fournisseur change de modèle.
- ☐ J’ai testé l’approche hybride avant de remplacer complètement.
- ☐ J’ai documenté ce que je ne sais pas : les limites du modèle dans mon domaine et les cas non couverts.
Aucun de ces points ne garantit de résultats. Les données du secteur suggèrent que les équipes qui maintiennent les deux approches obtiennent un meilleur rapport qualité-coût que celles qui misent tout sur une seule technologie, mais chaque domaine a ses exceptions qu’il convient de mesurer.