Du prompt au produit : transformer les LLM en vraies applications
Une méthodologie de terrain pour bâtir des applications LLM : évaluations, garde-fous, budgets de latence et de coût, humain dans la boucle, et savoir ce qu'il ne faut pas automatiser.
Par Vitor Lima
Un prompt qui fonctionne dans un playground est une démo, pas un produit. C'est dans l'écart entre les deux que la plupart des projets d'IA meurent en silence. Construire des applications LLM capables de résister à de vrais utilisateurs tient beaucoup moins au prompting astucieux que les démos ne le laissent croire, et beaucoup plus à une discipline logicielle ordinaire. Nous en avons livré assez — Youp, MadaiOps, et maintenant Linea — pour avoir des opinions sur ce qui comble réellement cet écart. Rien de tout cela n'est glamour.
Le piège, c'est que la première version semble finie. Vous collez un prompt astucieux, le modèle renvoie quelque chose d'impressionnant, et il est tentant de l'emballer dans une interface et d'appeler cela un lancement. Puis de vrais utilisateurs arrivent avec des entrées que vous n'aviez jamais imaginées, le modèle fait quelque chose de faux avec assurance, et vous découvrez que vous n'avez aucun moyen de savoir si votre correctif a amélioré ou empiré les choses. Cet article parle de l'échafaudage qui transforme cette démo impressionnante en quelque chose que vous pouvez faire tourner en production tout en dormant sur vos deux oreilles.
Commencez par les évaluations, pas par les prompts
La chose la plus rentable que vous puissiez construire tôt, c'est un jeu d'évaluation. Pas un benchmark, pas un classement — un dossier d'entrées réelles associées à ce à quoi ressemble une bonne sortie. Vingt exemples valent mieux que zéro, et cinquante exemples soigneusement choisis valent mieux que mille collectés à la volée.
La raison est simple. Une fois que vous avez des évaluations, l'ingénierie de prompts cesse de reposer sur le ressenti. Vous changez une ligne, vous lancez le jeu, vous regardez le chiffre bouger. Sans elles, chaque ajustement relève de la superstition. Nous avons vu des équipes passer une semaine à améliorer un prompt pour finalement régresser sur des cas résolus des mois plus tôt, parce que rien ne mesurait les cas qu'elles ne regardaient pas.
Quelques opinions que nous tenons fermement :
- Notez sur les résultats, pas sur la formulation. Pour tout ce qui est structuré — extraction, classification, routage — vérifiez le résultat analysé, pas la similarité de chaînes. Pour du texte libre, un LLM-juge doté d'un barème serré convient, mais validez d'abord le juge contre une poignée d'étiquettes humaines, sinon vous ne mesurez que le goût d'un seul modèle.
- Tenez un fichier de régressions. Chaque échec en production devient un cas de test permanent. C'est ainsi que votre jeu d'évaluation reste honnête — il grandit exactement dans les directions où la réalité le pousse.
- Versionnez vos évaluations avec vos prompts. Un prompt sans son jeu d'évaluation est une modification de code non testée.
Si vous ne retenez qu'une chose de cet article, construisez cela. Tout le reste en aval dépend de votre capacité à répondre : est-ce que ça a amélioré les choses ?
Les garde-fous coûtent moins cher que les excuses
Les modèles échouent d'une manière qu'un logiciel ordinaire ne connaît pas. Ils inventeront une API qui n'existe pas, abonderont dans le sens d'une prémisse fausse d'un utilisateur, ou produiront un JSON d'apparence valide avec un champ halluciné. Les garde-fous sont la couche qui intercepte cela avant que cela n'atteigne un utilisateur ou, pire, une étape d'exécution.
Pensez en trois positions.
- Les garde-fous d'entrée rejettent ou assainissent avant l'exécution du modèle : filtrage des injections de prompt, expurgation des données personnelles, filtrage des sujets hors contexte.
- Les garde-fous de sortie valident ce qui revient : validation de schéma, vérifications d'ancrage des citations, filtres de conformité.
- Les garde-fous d'action se placent entre le modèle et tout ce qui a des effets de bord.
C'est ce troisième cas qui concentre le vrai risque. Dans Linea, nos agents d'automatisation de flux de travail, le modèle peut proposer des actions — appeler une API, déplacer un enregistrement, envoyer un message. La proposition et l'exécution sont délibérément des étapes distinctes. Chaque action conséquente passe par un contrat typé et une vérification de conformité avant toute exécution, et les actions destructrices ou irréversibles exigent une porte de confirmation explicite. Un agent qui suggère la mauvaise chose est un problème d'expérience utilisateur sur lequel vous pouvez itérer. Un agent qui fait la mauvaise chose est un incident. Gardez ces deux modes de défaillance de part et d'autre d'une frontière stricte.
La version tranchée : validez la sortie structurée contre un schéma et réessayez en cas d'échec plutôt que de faire confiance au modèle pour être cohérent. Et ne laissez jamais la sortie brute d'un modèle déclencher une action irréversible. Interposez toujours une vérification déterministe.
Budgétez la latence et le coût comme des fonctionnalités
La latence et le coût ne sont pas des choses que l'on mesure à la fin. Ce sont des contraintes que vous concevez dès le départ, car elles modifient l'architecture, pas seulement la facture.
Fixez des budgets explicites par action visible par l'utilisateur : une cible de latence p95 et un plafond de coût par appel. Une fois ceux-ci écrits, les décisions de conception deviennent plus faciles. Quelques schémas vers lesquels nous revenons sans cesse :
- Dimensionnez le modèle à chaque étape. La plupart des pipelines comptent une ou deux étapes qui ont réellement besoin du modèle de pointe et plusieurs qu'un modèle plus petit et plus rapide gère très bien. Router une classification simple vers un modèle bon marché et réserver le modèle coûteux à l'étape de raisonnement difficile est l'optimisation la plus rentable disponible, et elle améliore généralement aussi la latence.
- Diffusez le premier jeton. Pour tout ce qui est conversationnel, la latence perçue est dominée par le délai jusqu'au premier jeton. Une réponse diffusée qui prend quatre secondes semble meilleure qu'une réponse bloquante qui en prend deux.
- Mettez en cache de façon agressive. Cache de prompts sur le contexte système stable, cache de résultats ordinaire sur les entrées répétées. Une part significative du trafic de production est quasi dupliquée.
Le compromis à garder en tête : les modèles plus gros réduisent votre effort d'ingénierie mais augmentent votre coût marginal et votre latence pour toujours. Les modèles moins chers reportent le travail sur vous — plus de soin dans les prompts, plus de garde-fous, plus d'évaluations — mais ce travail est un coût unique face à une économie permanente. Pour tout ce qui a du volume, investissez l'ingénierie.
Gardez l'humain dans la boucle, de façon délibérée
« Humain dans la boucle » est répété si souvent que l'expression a cessé de signifier quoi que ce soit. Bien menée, ce n'est pas un recours pour quand l'IA échoue — c'est une division du travail conçue. La question n'est pas s'il faut inclure un humain, mais là où le jugement de l'humain vaut plus que la latence qu'il ajoute.
Le schéma qui nous a le mieux servi est l'escalade conditionnée par la confiance. Le système traite automatiquement la majorité des cas confiants et achemine la minorité incertaine vers une personne, en y joignant le raisonnement du modèle pour que l'humain décide en quelques secondes, pas en quelques minutes. Dans MadaiOps, les opérations sur les ordres dans des paramètres normaux passent au travers ; tout ce qui est anormal remonte à un opérateur avec le contexte plutôt que de s'exécuter en silence. Le relecteur ne fait pas du baby-sitting de la machine. Il consacre son attention uniquement là où elle est rare et précieuse.
Une règle de plus : instrumentez les corrections de l'humain et réinjectez-les dans votre jeu d'évaluation et vos prompts. Un système humain dans la boucle qui n'apprend pas de ses humains ne fait que payer deux fois le même travail.
Sachez ce qu'il ne faut pas automatiser
Le jugement le plus difficile dans cette discipline, c'est la retenue. Toutes les tâches ne devraient pas être confiées à un modèle, et la maturité consiste à savoir lesquelles laisser tranquilles.
Notre test approximatif : automatisez là où le coût d'une erreur est faible, ou là où l'erreur est facile à détecter et à annuler. Rédiger, résumer, extraire, classer, router — de bons candidats. Un brouillon erroné se corrige ; un résumé erroné se repère à la lecture. Soyez bien plus prudent là où les erreurs sont coûteuses, difficiles à détecter, ou irréversibles : tout ce qui déplace de l'argent, envoie une communication irrévocable, ou prend une décision juridique ou médicale. Là, le modèle a sa place dans un rôle d'assistance — présenter des options, rédiger pour relecture — pas aux commandes.
La ligne que nous tenons : si vous ne pouvez pas décrire comment vous détecteriez que le modèle a tort, vous n'êtes pas prêt à automatiser cette étape. La capacité à détecter l'échec est le vrai prérequis, davantage que la précision. Une étape précise à 95 % que vous pouvez pleinement vérifier est plus sûre à livrer qu'une étape précise à 99 % que vous ne pouvez pas vérifier.
La forme du travail
Transformer un prompt en produit, c'est surtout la partie peu glamour : des évaluations pour pouvoir mesurer, des garde-fous pour que les défaillances restent contenues, des budgets pour que ça reste rapide et abordable, des humains placés là où le jugement compte, et la discipline de laisser certaines choses non automatisées. Le modèle représente peut-être vingt pour cent du système. Les quatre-vingts pour cent restants sont l'ingénierie qui rend son éclat occasionnel suffisamment sûr pour qu'on puisse en dépendre.
La bonne nouvelle, c'est que c'est un travail familier. Il récompense les mêmes instincts qui font un bon logiciel de tout type : mesurer avant de changer, contenir son rayon d'impact, respecter le temps de vos utilisateurs. Le modèle est nouveau. L'artisanat, non.