Mettre un LLM en production : ce qui change quand ce n'est plus une démo

La démo a marché du premier coup. Le prototype qualifie les demandes entrantes, résume les documents, répond aux questions du support. Trois semaines plus tard, on décide de le brancher en production. C'est à ce moment précis que la plupart des projets LLM commencent à avoir des problèmes qu'ils n'avaient pas la veille.

La raison tient en une phrase : un appel LLM est un composant non déterministe posé au milieu d'un pipeline déterministe. Tout le reste, le coût, les tests, la gestion d'erreur, la place qu'on laisse à un humain, découle mécaniquement de ce seul fait. Pas besoin d'une liste de dix bonnes pratiques : il suffit de tirer le fil.

La démo qui marche toujours, et pourquoi elle ne suffit pas

Il n'y a pas de mépris à avoir pour une démo qui tourne bien. Elle tourne bien pour trois raisons précises, et aucune des trois ne survit au passage en production.

D'abord, l'input est choisi. On a testé avec des documents propres, des questions bien formées, le cas qu'on avait en tête en écrivant le prompt. En production, l'input est choisi par l'utilisateur, pas par vous : le document scanné de travers, la demande en trois langues, le champ vide que personne n'avait prévu.

Ensuite, un humain lit la sortie. Pendant la démo, c'est vous, ou un collègue convaincu, qui juge si la réponse est bonne. Ce jugement absorbe silencieusement les petites incohérences, complète les trous, pardonne les formulations bancales. En production, la sortie part directement dans un système, une base de données, un email au client, sans ce filtre.

Enfin, on l'a lancée dix fois, pas mille. Un modèle de langage a un taux d'erreur qui n'est jamais nul, juste plus ou moins faible. Sur dix exécutions, il y a de bonnes chances qu'aucune ne tombe sur le cas limite. Sur mille exécutions par mois, ce cas limite arrive, et il arrive régulièrement.

Ces trois facteurs ne remettent pas en cause l'outil, ils délimitent ce que la démo a réellement prouvé : que le modèle sait faire la tâche dans de bonnes conditions. Pas qu'il continuera à bien la faire dans toutes les conditions, à un volume qui n'a plus rien à voir.

Le coût réel, calculé

Prenons un cas fréquent chez nos clients : la qualification automatique de demandes entrantes (leads, tickets, demandes de devis). Un prompt système de 1 500 tokens, un document joint de 3 000 tokens, une sortie structurée de 600 tokens. 500 exécutions par mois, un volume de pilote raisonnable.

Aux tarifs officiels de l'API Claude au moment d'écrire ces lignes¹, le calcul est vite fait :

Même avec le modèle le plus cher des trois, la facture nominale d'un pilote tient dans le budget café de l'équipe. C'est précisément ce qui piège les projets : ce chiffre-là rassure, et personne ne revient dessus une fois en production. Or la facture qui arrive trois mois plus tard ne vient presque jamais du nominal. Elle vient de trois dérives silencieuses, qui se cumulent :

• Les retries. Une sortie JSON mal formée, un timeout, une réponse hors format : sans validation stricte en amont, le réflexe le plus courant est de relancer l'appel. Chaque retry double le coût de l'appel qui a échoué, et personne ne le compte comme une ligne de budget à part.
• Le contexte qu'on empile "au cas où". Un exemple ajouté ici pour cadrer un cas particulier, l'historique de conversation qu'on garde entier plutôt que de le résumer, un extrait de documentation collé "pour être sûr". Chaque ajout est justifiable isolément ; leur somme fait grimper le nombre de tokens d'entrée sans que personne ne décide explicitement de payer plus cher.
• Le gros modèle utilisé par défaut. Réflexe compréhensible : on prend le modèle le plus capable pour ne pas avoir à s'en reposer la question. Sauf que la tâche de tri qu'on lui confie, une classification fermée entre cinq catégories, est aussi bien faite par un modèle cinq fois moins cher.

Voici ce que ça donne à une échelle de production réaliste, 8 000 exécutions par mois, en comparant une configuration qu'on voit passer régulièrement et une configuration maîtrisée sur la même tâche :

Un facteur proche de 11, sur une tâche strictement identique. Aucune de ces deux configurations n'est absurde prise isolément : c'est justement pour ça que la dérive passe inaperçue tant que personne n'a fait le calcul.

La conséquence pratique tient en un tableau de routing, qui vaut mieux que dix paragraphes de recommandations générales :

Le gros modèle reste utile, mais comme échappatoire pour les cas difficiles, pas comme réglage par défaut pour tout le pipeline. Chez Novagentic, ce type d'appel LLM est presque toujours un nœud parmi d'autres dans un pipeline plus large ; notre bilan sur les workflows n8n couvre la partie déterministe qui l'entoure.

¹ Tarifs API Claude au 15 août 2026 : Haiku 4.5 à 1 $ / 5 $ par million de tokens (entrée / sortie), Sonnet 5 à 2 $ / 10 $, Opus 5 à 5 $ / 25 $, convertis à un taux indicatif de 1 $ ≈ 0,865 €. Ces tarifs évoluent : à vérifier sur la page officielle avant de budgéter un projet.

Tester ce qui n'est pas reproductible

C'est le nœud technique du sujet, et le point où la plupart des équipes hésitent, parce que les réflexes du test logiciel classique ne s'appliquent pas tels quels. On ne peut pas écrire assertEquals(sortie, "réponse attendue") sur une sortie de LLM : la même entrée peut produire deux formulations différentes, également correctes.

La solution n'est pas de renoncer à tester, c'est de changer ce qu'on teste.

Un jeu de cas figé. Trente à cinquante entrées réelles, représentatives de ce qui arrive en production (y compris les cas limites déjà rencontrés), chacune associée à une sortie attendue ou à des critères de validation. Ce jeu de cas est rejoué avant chaque déploiement d'un nouveau prompt ou d'un changement de modèle, jamais improvisé au moment où on en a besoin.

Des assertions sur des propriétés, pas sur le texte exact. Au lieu de comparer une chaîne de caractères, on vérifie que le champ existe, que le montant tombe dans une fourchette plausible, que la catégorie appartient bien à l'énumération attendue, que la longueur de la réponse reste dans un intervalle raisonnable. Ce sont des invariants qu'une sortie correcte doit respecter, quelle que soit sa formulation exacte.

Le LLM-as-judge, avec ses limites assumées. Pour évaluer une qualité plus subjective (la pertinence d'un résumé, le ton d'une réponse), on peut faire juger la sortie par un autre appel LLM plutôt que par une règle mécanique. C'est utile, à condition de ne pas se mentir sur ce que ça vaut : le juge est lui-même non déterministe, et son jugement doit d'abord être calibré contre des évaluations humaines sur un échantillon, sinon on remplace une incertitude par une autre qu'on croit à tort maîtrisée.

Un seuil de régression avant déploiement. Le jeu de cas figé produit un taux d'accord (le pourcentage de cas qui passent les assertions, ou le score moyen donné par le juge). Ce taux devient la référence : un changement de prompt ou de modèle qui le fait baisser sous un seuil défini à l'avance bloque le déploiement, au même titre qu'un test unitaire rouge bloquerait un merge.

Le message à retenir tient en une phrase : on ne teste pas une égalité, on surveille un taux d'accord dans le temps. C'est un changement de posture, pas seulement d'outillage, et c'est ce qui rend le sujet suivant possible.

La sortie structurée, votre premier levier

Avant d'investir dans des tests élaborés ou une supervision humaine sophistiquée, il y a un levier plus simple et plus rentable : forcer la sortie du modèle dans un schéma structuré (JSON Schema ou équivalent), plutôt que de parser du texte libre a posteriori.

Un point compte plus que les autres, et il est souvent oublié : "je ne sais pas" doit être une valeur de sortie valide. Si le schéma n'autorise que des catégories définies, sans option pour signaler l'incertitude, le modèle est structurellement poussé à choisir la catégorie la plus probable même quand aucune ne convient vraiment. Une bonne partie des hallucinations qu'on observe en production ne viennent pas d'un modèle qui invente délibérément, elles viennent d'un modèle à qui on n'a jamais laissé le droit de s'abstenir.

Ajouter un champ incertain: boolean ou une valeur "non_déterminé" dans l'énumération coûte une ligne de schéma. Ça transforme une hallucination silencieuse en signal explicite, exploitable par tout ce qui suit.

Où placer l'humain

Une fois le signal d'incertitude disponible, reste à décider où un humain intervient. Une matrice simple aide à trancher, croisant le coût d'une erreur et le volume de cas traités :

• Coût d'erreur élevé, volume faible : validation systématique. Chaque sortie passe devant un humain avant action. C'est le régime le plus lent, réservé aux décisions qui engagent (montant important, impact client direct).
• Coût d'erreur moyen, volume moyen à élevé : validation par échantillon. Un pourcentage fixe des sorties est audité a posteriori, pour surveiller la dérive sans ralentir le flux.
• Coût d'erreur faible, volume élevé : validation par exception. La grande majorité des sorties partent directement en production ; seules celles marquées comme incertaines par le modèle remontent vers un humain.

Le troisième régime est le plus efficace, et le plus mal implémenté. Il repose entièrement sur une hypothèse qu'on vérifie rarement : que le modèle sait signaler son incertitude, et que ce signal a été calibré sur le jeu de cas figé de la section précédente. Un score de confiance qui n'a jamais été confronté à des cas dont on connaît la bonne réponse n'est pas un score de confiance, c'est un nombre qui rassure sans le mériter. Sans cette calibration, la validation par exception n'est pas un filet de sécurité : c'est du théâtre qui donne l'illusion d'un contrôle qui n'existe pas.

Observer, ou déboguer à l'aveugle

Un pipeline déterministe se débogue avec des logs et un débogueur pas à pas. Un appel LLM ne se rejoue jamais à l'identique, donc si on n'a pas capturé ce qui s'est passé au moment où c'est arrivé, ça ne se reconstitue pas après coup.

Il n'y a pas de version courte ici : il faut logger systématiquement, pour chaque appel, l'entrée complète, la sortie complète, le modèle utilisé (y compris sa version exacte), le nombre de tokens et la latence. Pas en échantillon, pas "quand ça semble utile" : sur 100 % du trafic, avec une politique de rétention qui tient compte des données sensibles qui transitent.

Sans ça, "le workflow a mal répondu la semaine dernière" est une phrase indébuggable. Avec ça, c'est une requête sur un log.

La dérive : le sol qui bouge sous vos pieds

Dernier point, souvent découvert trop tard : le modèle qu'on appelle aujourd'hui n'est pas figé. Le fournisseur le met à jour, en discret ou en grande pompe, et le comportement change sans qu'on ait touché une ligne de son propre code.

C'est là que le jeu de cas figé de la section 3 cesse d'être une bonne pratique méthodologique pour devenir un outil de mesure concret : quand le fournisseur change de modèle, on rejoue le même jeu de cas, et le taux d'accord dit précisément combien on a perdu, ou gagné, sur sa propre tâche. Sans ce jeu de cas, une mise à jour de modèle est une expérience non contrôlée qu'on subit en silence, découverte des semaines plus tard via une plainte client ou une anomalie dans un tableau de bord.

Un pipeline déterministe casse de façon visible. Un LLM qui dérive casse en douceur, une sortie plausible après l'autre, jusqu'à ce que quelqu'un remarque que le taux d'erreur a doublé sans qu'aucun déploiement ne l'explique.

Checklist avant de déployer

1. Un jeu de cas figé (30 à 50 entrées réelles) existe et est rejoué avant chaque changement de prompt ou de modèle.
2. La sortie est structurée par un schéma, avec une valeur explicite pour l'incertitude.
3. Si la validation humaine se fait par exception, le score de confiance a été calibré sur le jeu de cas figé, pas seulement déclaré dans le prompt.
4. Chaque appel est loggé (entrée, sortie, modèle, tokens, latence), sur tout le trafic.
5. Le modèle est choisi tâche par tâche, pas fixé une fois pour toutes sur le plus gros disponible.

En résumé

Un appel LLM est un composant non déterministe au milieu d'un pipeline qui, lui, ne l'est pas. Cette seule caractéristique explique pourquoi le coût dérive (retries, contexte qui gonfle, modèle surdimensionné), pourquoi les tests changent de nature (on surveille un taux d'accord, pas une égalité), pourquoi la sortie structurée devient un levier de fiabilité plutôt qu'un détail de format, et pourquoi la place de l'humain doit être décidée avec la même rigueur qu'une architecture, pas laissée au hasard d'un prototype qui a bien marché. Le meilleur signe qu'un projet LLM est prêt pour la production n'est pas qu'il fonctionne dans la démo : c'est qu'on sait déjà ce qui va casser au bout de trois mois, et qu'on a un moyen de le mesurer avant que le client ne le fasse à notre place.