LLMs en production : mythes et réalités en 2026

Pourquoi presque tout ce qu’on vous a raconté sur les LLM en production n’est qu’à moitié vrai

J’ai vu des équipes perdre six mois de travail en tenant pour acquises deux idées opposées : qu’un LLM fonctionnait comme un endpoint REST et qu’il suffisait de le lancer, ou qu’il était si imprévisible qu’il ne valait pas la peine de le sortir du laboratoire. Ni l’une ni l’autre ne résiste au contact du trafic réel. Selon la documentation officielle des principaux fournisseurs de modèles, la latence, le coût et la qualité varient de manière non linéaire avec le contexte, la température et la longueur de la réponse, et cela brise bon nombre des promesses qui circulent dans les conférences et les articles.

Cet article passe en revue les mythes qui font le plus de dégâts lorsqu’on met des modèles de langage en production et les confronte à ce qui se passe lorsque le système sert de vrais utilisateurs : nouvelles tentatives, prompts mal formés, données sensibles et pics de charge. Il n’y a pas de garanties de résultats : il y a des schémas qui fonctionnent dans certains contextes et d’autres qui échouent lamentablement.

Mythe 1 : « Le prompt parfait élimine le besoin d’ingénierie »

Le prompt compte, mais il ne remplace pas l’architecture. Une équipe avec laquelle j’ai collaboré a construit un assistant de support qui répondait avec précision lors de tests manuels. En production, le même prompt a échoué dès que les utilisateurs ont commencé à écrire en majuscules, avec des fautes ou en collant des captures d’écran transcrites par un OCR défectueux. Le taux de réponses utiles a chuté sans que le modèle ait changé.

Ce qui fonctionne vraiment

• Validation des entrées : normaliser le texte, limiter la longueur et détecter la langue avant d’appeler le modèle.
• Contrats de sortie : exiger du JSON avec un schéma et le valider avec une bibliothèque ; en cas d’échec, réessayer avec un prompt de correction ciblé.
• Fallback déterministe : pour les requêtes à haute fréquence, un modèle de réponse ou des règles peuvent répondre mieux et moins cher que le modèle.

La réalité, c’est que le prompt est une pièce du système, pas le système. Les équipes matures versionnent les prompts comme du code, les évaluent avec des jeux de cas et mesurent les régressions avant de déployer.

Mythe 2 : « Plus de contexte améliore toujours la réponse »

Une large fenêtre de contexte est utile, mais pas gratuite. Selon la documentation des fournisseurs, le coût et la latence augmentent avec les tokens d’entrée, et en pratique la qualité ne s’améliore pas de façon monotone : insérer dix documents non pertinents dilue le signal et augmente la probabilité que le modèle cite des informations tangentielles.

Exemple concret d’échec

Dans un moteur de recherche interne sur de la documentation technique, passer de 3 à 15 fragments récupérés a amélioré la couverture des réponses correctes sur les questions larges, mais a dégradé les réponses aux questions de détail parce que le bon fragment se retrouvait enterré parmi d’autres similaires. La solution n’a pas été d’élargir le contexte, mais d’améliorer le classement de la récupération et de se limiter aux fragments ayant le meilleur score, avec un seuil de coupure.

Limites qu’il convient de reconnaître

Il n’existe pas de nombre magique de fragments. Cela dépend du domaine, de la qualité de l’index et du type de question. Quiconque affirme « utilisez toujours top-k=5 » simplifie. Il faut le mesurer avec son propre jeu d’évaluation.

Mythe 3 : « Le modèle est déterministe si je mets la température à 0 »

Une température de 0 réduit la variabilité, mais ne l’élimine pas chez tous les fournisseurs ni pour tous les modèles. De plus, le déterminisme apparent masque une autre source de variation : les changements silencieux du modèle hébergé. Un même identifiant peut être mis à jour et modifier les réponses, ce que la documentation de plusieurs fournisseurs signale explicitement.

Conséquences pratiques

• Fixer des versions précises lorsque le fournisseur le permet.
• Maintenir un ensemble de tests de régression exécuté après chaque changement de version.
• Enregistrer la version du modèle avec chaque réponse pour pouvoir auditer.

Si votre produit dépend du fait que la sortie soit identique entre les exécutions, un LLM n’est pas l’outil approprié pour cette partie. Il vaut mieux y recourir à une logique déterministe.

Mythe 4 : « Ça coûte peu parce que le token est bon marché »

Le coût par token semble faible jusqu’à ce qu’on le multiplie par les utilisateurs, les nouvelles tentatives et le contexte. Un schéma que je vois souvent : un chatbot qui inclut l’historique complet de la conversation à chaque appel. Avec des conversations de vingt tours, le coût croît de façon quadratique par rapport au nombre de tours, et non linéaire.

Ce que l’on peut faire

• Résumer l’historique ancien et ne conserver que les derniers tours pertinents.
• Mettre en cache les réponses aux questions répétées, si le domaine le permet.
• Router les requêtes simples vers de petits modèles et réserver les grands aux cas complexes.
• Fixer des limites de dépenses par utilisateur ou par session.

Il n’existe pas de formule universelle d’économie. Tout chiffre partagé sans contexte de trafic et de longueur de contexte est anecdotique. Ce qui est en revanche constant : sans observabilité des tokens d’entrée et de sortie, le coût devient incontrôlable.

Mythe 5 : « Si ça fonctionne en démo, c’est prêt pour la production »

La démo montre le chemin heureux. La production, c’est le chemin malheureux : entrées vides, tentatives d’injection de prompts, utilisateurs qui demandent des choses hors périmètre, pannes du fournisseur et temps d’attente. Selon des études du secteur sur la fiabilité des services, les défaillances de dépendances externes sont une cause fréquente d’incidents, et un LLM est une dépendance externe de plus.

Checklist minimale avant de l’exposer aux utilisateurs

1. Timeouts et nouvelles tentatives avec backoff exponentiel, avec un nombre limité de tentatives.
2. Circuit breaker pour ne pas marteler le fournisseur lorsqu’il est en panne.
3. Messages de dégradation clairs lorsque le modèle n’est pas disponible.
4. Filtres d’entrée et de sortie pour les données personnelles et le contenu nuisible.
5. Journalisation des traces avec prompt, réponse, latence et coût, avec une durée de conservation définie.

Rien de tout cela n’est glamour, mais c’est ce qui sépare un prototype d’un service qui tient bon un lundi matin.

Mythe 6 : « L’évaluation se règle avec de bonnes métriques automatiques »

Les métriques automatiques comme BLEU ou ROUGE ont une faible corrélation avec l’utilité perçue dans les tâches ouvertes. Pour un système d’extraction de données à schéma fixe, une métrique d’exactitude fonctionne. Pour un assistant conversationnel, non.

Ce qui fonctionne en pratique

• Un ensemble d’évaluation petit mais représentatif, revu par des personnes du domaine.
• Une évaluation par les pairs ou des grilles d’évaluation pour les tâches subjectives.
• Un échantillonnage périodique des réponses réelles pour détecter la dérive.

Je reconnais une limite : construire et maintenir cet ensemble prend du temps et ne passe pas à l’échelle aussi bien qu’un script automatique. Mais sans lui, toute affirmation sur la qualité du système n’est qu’une opinion.

Mythe 7 : « La confidentialité se règle avec une mention légale »

Envoyer des données d’utilisateurs à un fournisseur externe a des implications qu’une mention ne résout pas. Il faut savoir ce qui est envoyé, combien de temps c’est conservé et dans quelle juridiction c’est traité. Certaines équipes découvrent tard qu’elles incluaient des e-mails et des numéros de téléphone dans les prompts parce que le formulaire d’origine les collectait sans filtrage.

Mesures concrètes

• Pseudonymiser les identifiants avant de construire le prompt.
• Définir quels champs ne sortent jamais du système.
• Examiner les conditions de conservation du fournisseur et, si nécessaire, utiliser des déploiements qui ne stockent pas les données.

Ceci n’est pas un conseil juridique, et il convient de consulter qui de droit. Mais techniquement, filtrer avant d’envoyer coûte moins cher que de remédier après.

Mythe 8 : « Un LLM remplace l’équipe de support ou l’équipe de contenu »

Il peut réduire la charge sur les tâches répétitives, mais il introduit un coût de supervision. Un modèle qui répond avec assurance sur des sujets qu’il ne maîtrise pas génère plus de travail qu’il n’en économise. Dans les projets de service client, la révision humaine des réponses à faible confiance reste nécessaire pour éviter des erreurs coûteuses.

La réalité est plus ennuyeuse : le LLM est un outil au sein d’un flux, avec des humains aux points de risque. Les cas où il fonctionne sans supervision sont ceux à schéma fermé et à faibles conséquences en cas d’erreur, comme classer des tickets ou résumer des textes internes.

Ce qu’il convient d’assumer avant de commencer

• Vous aurez besoin d’observabilité dès le premier jour, pas après.
• Le coût réel se comprend lorsqu’il y a du trafic, pas au laboratoire.
• La qualité se mesure avec ses propres données, pas avec des benchmarks publics.
• Il y aura des changements chez le fournisseur qui affecteront votre produit sans que vous touchiez à rien.
• Certaines tâches ne devraient pas être résolues avec un LLM : calculs exacts, conformité réglementaire stricte ou décisions aux conséquences irréversibles.

Implémenter des LLM en production, c’est moins de la magie et plus de la discipline d’ingénierie : versionnage, évaluation, limites et dégradation contrôlée. Les mythes vendent des raccourcis ; la réalité exige de mesurer avant de promettre.