L’illusion du « tout est facile » avec un gros modèle IA
Il y a une promesse qu’on entend partout : « branchez vos données, choisissez un gros modèle, et vous avez une IA qui marche ».
En démo, ça fonctionne souvent. En production, c’est rarement aussi simple.
Le piège, c’est que l’IA donne une impression de standardisation : un chat, des documents, une base, un modèle, et “ça répond”. Sauf qu’en entreprise, le besoin réel n’est pas “obtenir une réponse plausible”. Le besoin, c’est généralement :
- une réponse juste (pas seulement convaincante)
- des éléments vérifiables (sources, date, version)
- le respect strict des droits d’accès,
- une qualité stable dans le temps
- et une capacité à expliquer pourquoi telle réponse a été donnée
Et c’est là que l’on découvre une vérité contre-intuitive : un modèle plus gros ne résout pas ces sujets. Il peut même les masquer. Il répond “mieux” en surface, donc on met plus de temps à voir que le système est fragile en dessous : récupération de mauvais passages, mélange de versions, absence de filtrage, incohérences, etc.
Quand le cas d'usage n'est pas adapté
Beaucoup de projets partent d’une intention saine (“on veut gagner du temps”), puis se traduisent en demande trop vague (“on veut un assistant intelligent”). Or certains besoins ne se prêtent pas bien à une approche conversationnelle si on ne fait pas le travail de fond :
- des processus qui exigent une précision importante (juridique, conformité, finance) sans corpus propre, versionné et gouverné
- des sujets où l’entreprise ne tolère pas l’approximation, mais ne veut pas investir dans la traçabilité
- des besoins qui ressemblent à de la recherche documentaire, alors que la vraie valeur est dans la structuration (référentiels, règles, workflow)
Dans ces cas-là, l’assistant devient un écran de fumée : on discute avec quelque chose qui “répond”, mais qui ne tient pas les exigences réelles du métier.
Le risque des “solutions startup” qui font surtout de la cosmétique
Le risque des “solutions startup” qui font surtout de la cosmétique
Autre piège fréquent : acheter une solution qui met une belle interface et quelques fonctionnalités visibles au-dessus d’une chaîne technique standard. Ça peut être très utile pour accélérer l’adoption mais c’est dangereux si la valeur est surtout cosmétique.
Et le vrai révélateur, ce n’est pas la démo. C’est la volumétrie.
Tant que tu as quelques documents et quelques utilisateurs, tu peux “tenir” avec une approche qui fait surtout de l’orchestration : multiples appels API, relectures successives, résumés à la volée, re-questions au modèle, bricolage de contexte, etc. Ça donne l’impression que ça marche. En réalité, ça fait souvent office de cache-misère : on compense l’absence de récupération robuste par du calcul… et par de la latence.
Là où ça devient critique, c’est quand la promesse implicite devient : « ce qu’il y a dessous est standard, donc interchangeable, donc plug-and-play ». Sauf que dès que la volumétrie monte (plus de documents, plus de versions, plus de requêtes, plus de cas bizarres), cette “solution” devient mécaniquement fragile et coûteuse : plus d’appels, plus de tokens, plus de temps de réponse, plus d’incohérences. Et tu ne peux plus te permettre de “tout relire” à chaque question.
En réalité, le jour où tu veux sortir du “chat sur des documents”, tu découvres que rien n’est si standard. Et ce point de bascule arrive vite avec un cas d’usage qui paraît anodin… mais qui change tout : le multimodal. Dès que tu demandes au système de gérer des PDF complexes, des tableaux, des scans, des schémas, des images, des annexes, ou simplement des documents “humains” (mise en page incohérente, colonnes, titres mal structurés, pages scannées), l’illusion s’effondre.
Parce qu’à ce moment-là, un gros modèle + un prompting bien pensé ne suffisent plus. Ce n’est plus seulement “comment je pose la question”. C’est “est-ce que j’extrais correctement”, “est-ce que je segmente correctement”, “est-ce que je relie les bons éléments”, “est-ce que je filtre”, “est-ce que je privilégie le bon passage, au bon niveau de granularité”. Et surtout : “est-ce que je peux le faire à grande échelle, sans exploser en coût et en instabilité”.
Autrement dit : à ce stade, l’IA n’est plus un produit plug-and-play. C’est une chaîne. Et si tu ne maîtrises pas la chaîne, tu obtiens un assistant qui répond à côté. C’est exactement ce qui nous amène au cœur du sujet : le RAG. Pas le RAG “monté en une heure”, mais celui qui tient en production, avec de la preuve, de la stabilité, et des documents réels.
Daniel Albagnac, associé fondateur et expert IA & Solutions chez Nextra.
Pour en savoir plus sur le sujet, n’hésitez pas à le contacter.