Intégrer un LLM dans un produit : quand ça crée de la valeur, quand c'est un piège
Depuis ChatGPT, l'IA est devenue une réponse par défaut avant même que la question soit posée. Voici ce qui distingue un cas d'usage LLM qui apporte de la valeur d'un qui n'est que du marketing.
"Il faudrait mettre de l'IA" n'est pas un besoin, c'est une réponse sans question
Depuis l'arrivée de ChatGPT, peu de kick-offs se passent sans cette phrase. Parfois c'est pertinent. Souvent, c'est une réponse cherchant sa question. Un LLM (Anthropic, DeepSeek) est un outil puissant quand il résout un problème identifié — ajouter de l'IA pour pouvoir l'écrire sur une landing page est du marketing, pas une décision produit.
Ce qu'un LLM fait vraiment bien
Traiter du texte non structuré en masse : résumer, classer, extraire de l'information depuis des documents ou des retours utilisateurs. Automatiser des tâches répétitives qui suivent un schéma reconnaissable, sans être des règles strictement déterministes. Personnaliser une expérience en trouvant des patterns dans des données que des règles écrites à la main ne captureraient pas facilement. Ce sont des cas où le modèle apporte une capacité qu'un algorithme classique n'a pas.
Ce qu'un LLM ne fait pas bien
Remplacer une règle métier claire. Si un processus se décrit entièrement par des conditions précises, un algorithme déterministe fait le travail de façon plus fiable, plus rapide, et surtout plus prévisible qu'un modèle probabiliste.
Fonctionner sans données. Un LLM généraliste peut démarrer sans données propriétaires, mais la valeur différenciante — la personnalisation, la prédiction — a besoin d'un historique réel. Sur un produit qui vient de naître, il n'y a souvent rien à exploiter.
Garantir une fiabilité absolue. Un LLM se trompe, régulièrement, de façon parfois convaincante. Sur un cas d'usage qui exige une fiabilité quasi totale — calcul financier, conformité réglementaire, décision qui engage juridiquement — le modèle peut assister, jamais décider seul sans vérification humaine en sortie.
Les questions qui tranchent, avant de parler d'implémentation
Quel problème précis est résolu — pas "ce serait pertinent d'avoir de l'IA", mais un point de friction identifié et nommé. Les données nécessaires existent-elles déjà, ou faut-il d'abord les collecter avant que le modèle ait quoi que ce soit à exploiter. Le secteur du produit tolère-t-il une décision partiellement automatisée, ou les utilisateurs exigeront-ils de comprendre et contrôler ce que le modèle produit — la finance, la santé et le juridique sont nettement plus exigeants sur ce point que d'autres secteurs. Et le coût par appel est-il intégré au modèle économique dès le départ, pas découvert après le lancement.
Construire sans IA d'abord n'est pas un retard, c'est une séquence
L'ordre qui fonctionne : un produit qui apporte déjà de la valeur sans IA, des utilisateurs réels qui génèrent des points de friction observables, puis une intégration ciblée sur le point de friction le plus net — mesurée, pas généralisée d'un coup à toute l'expérience. L'IA n'est jamais un prérequis de lancement ; elle est une réponse à un problème que seuls de vrais utilisateurs peuvent révéler.
Le piège du produit qui repose entièrement sur l'IA
Le pire scénario est un produit dont la proposition de valeur dépend entièrement du modèle, sans plan pour le moment où il se trompe — et il se trompera. Les intégrations qui tiennent dans le temps gardent le modèle dans un rôle qui assiste et suggère, avec l'utilisateur qui garde la main pour corriger, plutôt qu'une automatisation totale sans filet.