19 juin 2026
Ce que j'ai appris en déployant des LLM pour de vrais clients
Leçons honnêtes de déploiement LLM chez de vrais clients : ce qui casse entre la démo et la production, comment gérer latence, prompt, coût, adoption, et ce qui fait vraiment tenir une IA en production.
La démo ment toujours un peu
J'ai rarement vu un déploiement LLM échouer parce que le modèle de langage était incapable de produire une bonne réponse dans une démo. La démo est presque toujours convaincante : un jeu de données propre, un scénario bien choisi, un utilisateur patient, et une sortie qui donne l'impression que le futur est déjà là. La production, elle, arrive avec des documents incomplets, des exceptions métier, des utilisateurs pressés et des cas que personne n'avait écrits dans le script.
C'est la première leçon que j'ai apprise chez de vrais clients, dans les médias, l'assurance, l'éducation ou le cinéma : un déploiement LLM ne se juge pas sur son meilleur exemple. Il se juge sur le mercredi matin où le système reçoit une demande ambiguë, une donnée périmée, un fichier mal nommé, puis doit quand même aider quelqu'un à faire son travail. L'écart entre prototype et production n'est pas cosmétique. C'est le sujet central.
La latence change le produit
Sur le papier, quelques secondes de latence semblent acceptables. Dans un comité de pilotage, personne ne panique pour trois secondes. Dans un vrai workflow, ces trois secondes deviennent vite une rupture d'attention. Un journaliste qui explore des archives, un gestionnaire qui traite un dossier d'assurance, un enseignant qui prépare un contenu, ou une équipe de production cinéma qui cherche un asset ne vivent pas la latence comme une métrique technique. Ils la vivent comme une interruption.
Comme ingénieur IA, j'ai donc appris à traiter la latence comme une contrainte produit, pas comme un détail d'infrastructure. Il faut parfois router vers un modèle plus petit, pré-calculer une partie du contexte, streamer tôt, cacher les appels coûteux, ou accepter une réponse moins ambitieuse mais plus rapide. L'IA en production n'est pas la recherche de la meilleure réponse abstraite. C'est la recherche de la meilleure réponse utile dans le temps disponible.
Le prompt est nécessaire, mais il ne sauve pas un système fragile
Le prompt compte. J'en écris, j'en versionne, j'en teste, et je continue de penser qu'un bon prompt peut transformer la fiabilité d'un système. Mais une partie du discours autour du prompt engineering donne une impression dangereuse : si le comportement est mauvais, il suffirait d'une meilleure formulation. Dans les projets réels, ce n'est presque jamais suffisant. Le prompt révèle surtout les problèmes de contexte, de données, d'architecture et de responsabilité.
Quand un assistant confond deux règles d'assurance, invente une hiérarchie de sources, ou donne une réponse trop confiante sur un corpus pédagogique incomplet, le problème n'est pas seulement syntaxique. Il faut clarifier les sources autorisées, les priorités entre documents, les conditions de refus, les formats de sortie, les logs et les tests de régression. Un prompt robuste ressemble moins à une formule magique qu'à un contrat entre le modèle, le produit et le métier.
Le coût ne se découvre pas après le lancement
Le coût d'un modèle de langage est facile à sous-estimer tant que l'usage reste faible. Une démo consomme peu, un pilote contrôlé aussi. Puis viennent les vrais utilisateurs, les documents longs, les retries, les appels d'outils, les embeddings, les evals, les logs, et les cas où le système appelle trois fois le modèle parce qu'une étape intermédiaire a échoué. À ce moment-là, le coût n'est plus une ligne dans une hypothèse. Il devient une contrainte d'exploitation.
Les meilleurs projets que j'ai vus ne découvrent pas ce sujet à la facture du premier mois. Ils définissent tôt des budgets par usage, des limites de contexte, des stratégies de cache, des modèles de secours, et des métriques de valeur par action. La bonne question n'est pas seulement combien coûte un appel. C'est combien coûte une tâche résolue, combien coûte une erreur évitée, et combien de confiance utilisateur on gagne ou on perd à chaque arbitrage.
L'adoption dépend moins de la magie que de l'intégration
La surprise la plus constante est peut-être celle-ci : les utilisateurs n'adoptent pas un système parce qu'il est impressionnant. Ils l'adoptent parce qu'il s'insère dans leur journée sans leur demander de devenir opérateur IA. Dans une rédaction, une école, une équipe assurance ou un studio, les gens ont déjà des outils, des deadlines, des habitudes et des critères de qualité. Si le système demande trop d'explications, trop de copier-coller ou trop de vérification, il restera une curiosité.
Ce qui fait tenir un déploiement LLM dans la durée est souvent moins spectaculaire : un périmètre clair, une interface proche du workflow, un humain dans la boucle là où le risque est réel, des evals simples, une mesure de la latence, une mesure du coût, et une équipe qui sait qui maintient quoi. La production récompense la discipline. Les clients ne paient pas pour voir un modèle briller. Ils paient pour qu'un problème disparaisse sans créer trois nouveaux problèmes autour.