Choisir entre un grand modèle de langage (LLM) et un pipeline classique de traitement automatique du langage naturel (NLP) n’est pas une question de mode, mais d’adéquation technique. Cette liste de vérification est conçue pour être utilisée comme filtre avant d’engager un budget, une infrastructure ou une équipe entière dans la mauvaise direction. Chaque point inclut la nuance que l’on apprend généralement à ses dépens : quand la réponse évidente échoue.
Comment utiliser cette checklist
Ce n’est pas un questionnaire à répondre par oui ou non. Cochez chaque case avec des preuves (un test, un document, une mesure), pas avec une intuition. Si vous ne pouvez pas remplir une case avec des données, cette case est précisément là où votre projet se brisera en production.
1. Définissez la tâche avec une précision chirurgicale
1.1 S’agit-il d’une tâche fermée ou ouverte ?
Classer 40 000 tickets dans 12 catégories fixes est une tâche fermée. Résumer des conversations hétérogènes est une tâche ouverte. Les modèles traditionnels (régression logistique sur TF-IDF, SVM, CRF pour l’étiquetage de séquences, modèles de sujets comme LDA) restent compétitifs sur des tâches fermées avec un vocabulaire stable et des frontières bien définies. Les LLM brillent lorsque la sortie ne peut pas être énumérée à l’avance.
1.2 La bonne étiquette est-elle sans équivoque ?
Si deux experts ne sont pas d’accord pour étiqueter le même exemple, un LLM aura tendance à produire des réponses plausibles mais incohérentes d’une exécution à l’autre, et un modèle classique apprendra simplement le bruit. Avant de choisir une technologie, mesurez l’accord entre annotateurs. Sans cette métrique, toute comparaison ultérieure est de la fumée.
1.3 Avez-vous besoin d’extraction structurée ou de génération ?
Extraire des entités, des relations et des dates de contrats est un problème d’extraction. Un LLM peut le faire avec un format JSON forcé, mais un modèle de reconnaissance d’entités entraîné avec des données propres est généralement moins cher par document, plus rapide et plus stable face aux variations de format. La génération libre, en revanche, est un territoire presque exclusivement réservé aux LLM.
2. Auditez vos données avant d’auditer les modèles
2.1 Volume et déséquilibre
Avec 300 exemples étiquetés par classe, un modèle classique bien ajusté peut suffire. Avec 30, aucun des deux ne fonctionnera bien, et le LLM aura besoin d’exemples dans le prompt (apprentissage en contexte) ou d’un ajustement fin, qui n’est pas gratuit. Vérifiez le déséquilibre : en classification de fraude ou d’incidents critiques, la classe minoritaire est celle qui compte et celle qui a le moins de données.
2.2 Domaine et jargon
Un LLM généraliste connaît l’espagnol standard, mais pas nécessairement le jargon interne de votre entreprise, les codes produits ou les abréviations de votre secteur. Les modèles classiques non plus, mais leur entraînement est moins coûteux et vous pouvez injecter un vocabulaire contrôlé sans réentraîner un modèle de plusieurs milliards de paramètres.
2.3 Sensibilité et résidence des données
Si le texte contient des données personnelles, des dossiers cliniques ou des informations sous secret contractuel, envoyer chaque document à une API externe exige une évaluation des risques que beaucoup d’organisations n’ont pas réalisée. Les modèles classiques s’exécutent sur votre propre infrastructure avec une surface d’exposition moindre. Les LLM auto-hébergés existent, mais ils changent complètement le calcul des coûts et de l’équipe nécessaire.
3. Calculez le coût réel, pas le coût par token
3.1 Coût par inférence versus coût de maintenance
Le prix par token d’un LLM semble faible jusqu’à ce que vous le multipliiez par des millions de documents et que vous ajoutiez des tentatives, des validations et des tokens de contexte. Un modèle classique a un coût d’inférence presque négligeable, mais il entraîne un coût de maintenance : réentraînements périodiques, gestion des features, dérive du modèle (data drift). La bonne question n’est pas de savoir lequel est le moins cher aujourd’hui, mais lequel le sera dans deux ans avec votre volume projeté.
3.2 Latence et expérience utilisateur
Un classifieur linéaire répond en millisecondes ; un appel à un LLM avec un long contexte peut prendre des secondes. Si la tâche se trouve sur le chemin critique d’une interface (autocomplétion, modération en temps réel, routage de chats), cette différence est décisive. J’ai vu des équipes migrer un classifieur d’intentions vers un LLM et découvrir que le temps de réponse était multiplié par dix sans amélioration perceptible de la précision.
3.3 Coût de l’évaluation
Évaluer un LLM est plus coûteux et plus diffus qu’évaluer un classifieur : vous avez besoin de jeux de référence, de critères de qualité parfois subjectifs et d’une révision humaine. Budgétez cet effort avant de commencer ; selon la documentation du secteur, l’évaluation consomme souvent plus de temps que prévu.
4. Vérifiez la reproductibilité et l’auditabilité
4.1 Devez-vous expliquer chaque décision ?
Dans les secteurs réglementés (assurance, banque, santé, administration publique), il faut souvent justifier pourquoi un système a rejeté une demande. Un modèle de régression avec des coefficients interprétables ou un arbre de décision s’explique relativement facilement. Un LLM génère une justification en langage naturel qui peut sembler convaincante sans correspondre au raisonnement réel. L’explicabilité apparente est un risque, pas un avantage.
4.2 La sortie doit-elle être identique pour la même entrée ?
Les LLM avec échantillonnage stochastique ne le garantissent pas. Vous pouvez fixer la température à zéro, mais cela n’élimine pas toutes les sources de variation (versions du modèle, changements du fournisseur, contexte). Les modèles classiques sont déterministes par conception. Si votre cas d’usage exige un audit reproductible, cela pèse plus que quelques points de précision.
4.3 Versionnage et dépendance vis-à-vis du fournisseur
Un LLM hébergé peut changer de comportement sans préavis lorsque le fournisseur met à jour le modèle. Votre pipeline classique ne change que lorsque vous le changez. Documentez comment vous allez fixer les versions et ce que vous ferez si le fournisseur retire celle que vous utilisez.
5. Évaluez l’effort d’ingénierie et l’équipe
5.1 Avez-vous quelqu’un pour maintenir les prompts ou quelqu’un pour maintenir les features ?
Un LLM déplace le travail de l’ingénierie des caractéristiques vers la conception de prompts, la validation des sorties et les tests de régression. Un modèle classique exige des profils plus orientés données et statistiques. Aucune des deux voies n’est gratuite ; choisissez celle que votre équipe peut soutenir dans le temps.
5.2 Sorties non structurées et validation
Si le LLM renvoie du texte libre, vous aurez besoin de couches de validation, de tentatives et de gestion des erreurs. S’il renvoie du JSON forcé, vous aurez besoin de schémas stricts et d’une tolérance aux erreurs de format. Comptez ces pièces dans la conception ; ce ne sont pas des détails.
5.3 Tests de régression
Avec des modèles classiques, une suite de tests avec des métriques fixes suffit généralement. Avec un LLM, il convient de maintenir un ensemble doré de cas et de comparer les réponses entre versions, en acceptant une certaine variabilité. Si vous n’avez pas cet ensemble, vous n’avez aucun moyen de savoir si une mise à jour a amélioré ou détérioré le système.
6. Passez en revue les limites que personne ne mentionne dans les démos
6.1 Hallucinations dans les tâches d’extraction
Un LLM peut inventer une date qui n’apparaît pas dans le document si le format le suggère. En extraction de données, c’est un échec silencieux et dangereux. Les modèles classiques d’étiquetage de séquences ont leurs propres erreurs, mais ce sont généralement des erreurs d’omission ou de frontière, pas des inventions.
6.2 Dégradation avec des entrées longues ou bruitées
Les performances d’un LLM chutent lorsque le texte est très long, contient des tableaux mal convertis ou mélange les langues. Dans un cas réel de classification d’e-mails de support, le pipeline classique avec un nettoyage spécifique surpassait le LLM sur les messages avec citations imbriquées et signatures, car ces parties perturbaient le modèle génératif. La leçon : le nettoyage préalable compte dans les deux mondes, et souvent plus que le modèle choisi.
6.3 Langues et variantes dialectales
Un LLM multilingue peut fonctionner acceptablement dans de nombreuses langues, mais un modèle classique entraîné avec des données locales peut le surpasser sur une variante spécifique. Si votre corpus est très spécifique, testez avant de supposer que le grand modèle gagne.
6.4 Ce qui ne fonctionne pas bien avec un LLM
Les tâches de très haute précision avec des conséquences juridiques, les décisions qui doivent être identiques et auditables, le traitement massif avec une latence minimale et un budget serré, et la classification d’un vocabulaire très fermé avec des données étiquetées abondantes. Dans ces cas, le LLM ajoute du coût et de l’opacité sans avantage clair.
6.5 Ce qui ne fonctionne pas bien avec les modèles classiques
La génération de texte cohérent, le résumé abstractif, le dialogue ouvert, l’adaptation à de nouvelles instructions sans réentraînement et la compréhension des nuances pragmatiques (ironie, intention implicite). Forcer un modèle classique à faire cela produit des résultats rigides et fragiles.
7. Concevez l’expérience avant de décider
7.1 Ensemble d’évaluation représentatif
Rassemblez des exemples réels, y compris les cas rares et ambigus. Un ensemble d’évaluation biaisé vers des cas faciles favorise le LLM parce qu’il impressionne dans le général ; les cas difficiles sont ceux qui révèlent les différences.
7.2 Métriques alignées sur le métier
La précision, le rappel et le F1 sont le point de départ, mais demandez-vous quelle erreur coûte le plus cher. En modération de contenu, un faux négatif peut être grave ; en classification de leads, un faux positif dérange l’équipe commerciale. La métrique doit refléter cette asymétrie.
7.3 Test hybride
La dichotomie est fausse dans de nombreux cas. Un schéma courant consiste à utiliser un modèle classique pour filtrer 80 % des cas faciles et à réserver le LLM aux cas ambigus. Ou à utiliser des embeddings et la recherche sémantique (héritiers de techniques classiques) avec un LLM pour générer la réponse finale. Documentez cette architecture comme une option supplémentaire, non comme un échec de la comparaison.
8. Checklist finale de décision
- J’ai défini la tâche et je sais si elle est fermée ou ouverte.
- J’ai mesuré l’accord entre annotateurs humains.
- Je connais le volume, le déséquilibre et la qualité de mes données.
- J’ai calculé le coût par inférence et le coût de maintenance sur deux ans.
- J’ai vérifié la latence admissible dans mon cas d’usage.
- Je sais si j’ai besoin d’explicabilité et de reproductibilité strictes.
- J’ai un plan de versionnage et de dépendance vis-à-vis du fournisseur.
- Mon équipe peut soutenir l’approche choisie (prompts ou features).
- J’ai identifié les échecs silencieux dangereux dans mon domaine.
- J’ai testé les deux approches avec un ensemble d’évaluation représentatif.
- J’ai envisagé une architecture hybride avant de l’écarter.
Si vous avez tout coché avec des preuves et non avec intuition, la décision entre LLM et NLP classique cesse d’être un pari pour devenir un choix documenté. Et si vous ne pouvez pas encore cocher une case, c’est votre prochaine tâche, pas le choix du modèle.