Le moteur qui avait six pôles — Le mythe des dix lignes de code

Enquête en six parties sur les raisons pour lesquelles le chatbot documentaire qu'on vous a vendu continue d'inventer — et sur la direction différente que certains ont commencée à prendre début 2026.

Enquête en six parties sur les raisons pour lesquelles le chatbot documentaire qu'on vous a vendu continue d'inventer — et sur la direction différente que certains ont commencée à prendre début 2026.

Introduction — Le moteur qui avait huit pôles (mais en avait six)

Milan, mars 2026. Un manager ouvre le chatbot d'entreprise interne, de ceux montés « en deux semaines » par le service informatique avec grand enthousiasme et peu de méfiance. Question très simple : « Combien de pôles a le moteur CMP40M ? ». Le chatbot répond avec toute la confiance que les grands modèles linguistiques savent afficher : « Le moteur CMP40M a huit pôles. »

Faux. Il en a six. La bonne réponse ne se trouvait pas dans le catalogue de 422 pages que quelqu'un, des mois auparavant, avait confié avec la plus grande confiance à une base de données vectorielle, convaincu qu'à partir de là, le système "saurait tout". Cette donnée n'était tout simplement pas présente dans le catalogue. Elle se trouvait dans un PDF joint à un e-mail des techniciens SEW, archivé dans un dossier que personne n'avait pris la peine d'indexer.

Cette scène, avec des variations sectorielles et dialectales, se répète dans des centaines de bureaux italiens. La promesse était simple et séduisante : donnez tous les documents de votre entreprise à votre assistant IA, et il pourra répondre à n'importe quelle question à leur sujet. La réalité est bien plus prosaïque : le chatbot lit mais ne comprend pas, cherche mais ne trouve pas, et quand il ne trouve pas — au lieu de le dire — invente. Il invente avec fluidité, avec une grammaire parfaite, avec des chiffres plausibles. Ce qui est bien pire que de ne pas répondre.

Entre la fin de 2024 et le début de 2026, nous avons passé des mois à faire l'autopsie de ces échecs. Non pas pour alimenter les polémiques, mais pour comprendre une chose : pourquoi une idée aussi linéaire — "donnez-lui les documents et ensuite posez-lui des questions" — devienne si difficile lorsqu'elle quitte la scène de la démo et entre dans la salle des serveurs réels.

Cette enquête en six chapitres raconte ce que nous avons découvert : des bugs silencieux qui effaçaient des catalogues entiers, des rerankers cloud avec des scores incorrects, des hallucinations nées non pas du modèle mais de données contaminées des années auparavant, des factures sortantes qui rendaient chaque requête plus coûteuse que sa valeur, et des frameworks "populaires" qui promettent tout en dix lignes de code à condition de ne pas leur demander trop. Et dans le dernier chapitre, la direction différente que quelqu'un, en silence, a commencé à prendre début 2026 — une architecture dans laquelle la stratégie de recherche cesse d'être du code et devient un document que quiconque, en entreprise, peut lire et modifier.

Chaque chapitre tient debout seul. Si vous voulez commencer par l'histoire des 342 tables disparues, ou par celle du reranker menteur, vous êtes libre de le faire. Mais le récit dans son ensemble a une morale qui n'émerge qu'à la fin : le RAG d'entreprise — cet acronyme technique qui signifie Retrieval-Augmented Generation, c'est-à-dire "générer des réponses en se basant sur des documents que vous récupérez avant" — n'est pas encore un produit fini. C'est une frontière. Et comme toutes les frontières, jusqu'à présent, elle a été racontée surtout par les vendeurs. Il est temps d'écouter aussi ceux qui y ont vécu de l'intérieur.

Chapitre 1 — Le mythe des dix lignes de code

La diapositive est identique à chaque conférence sur l'IA depuis 2023 : "Votre assistant documentaire d'entreprise en 10 lignes de code." Sous le titre, un bloc de Python aux couleurs pastel qui montre une bibliothèque open source — typiquement l'une de ces célèbres américaines, dont le nom évoque des chaînes d'arbres ou des lamas tibétains — qui charge des PDF, les découpe, les colle dans une base de données vectorielle et les interroge avec un modèle linguistique. En cinq minutes, vous avez un chatbot. En cinq minutes, les applaudissements. En cinq minutes, une entreprise italienne de taille moyenne se convainc que le problème est résolu et que son service informatique peut y parvenir en deux semaines.

Le problème — celui que la diapositive ne dit pas — est que la démo est construite avec trois PDF bien formatés, une question cousue sur mesure pour correspondre au contenu, une scène sans latences réelles et un présentateur qui a tout essayé vingt-sept fois avant de monter sur scène. Dans la réalité, les documents d'entreprise sont un désastre géologique : des scans de scans, des tableaux qui se superposent au texte, des notes de bas de page qui s'infiltrent dans les paragraphes, des codes alphanumériques de type "RH1M" que le découpeur coupe en deux en les prenant pour des mots, des images qui contiennent soixante-dix pour cent des informations utiles mais que personne n'extrait réellement, et des mises en page si créatives qu'elles nécessitent un archéologue plutôt qu'un analyseur syntaxique.

Le RAG — c'est l'idée sous le capot — est une excellente idée. Prenez la question de l'utilisateur, recherchez dans vos archives les documents les plus pertinents, transmettez-les au modèle linguistique et obtenez une réponse basée sur ces documents. En théorie, cela résout élégamment le problème de l'hallucination : le modèle n'a plus besoin de "savoir" la réponse, il doit simplement la "lire" dans les extraits que vous lui avez fournis. En pratique, chaque maillon de la chaîne — le découpage, l'intégration, la récupération, le re-classement, la génération finale — a ses propres façons de casser, et la rupture ne se manifeste que rarement comme une erreur visible. Elle se manifeste par une réponse légèrement incorrecte. Puis par une réponse complètement incorrecte. Puis par un responsable qui se demande pourquoi il paie pour un système qui en sait moins qu'un stagiaire.

Les frameworks open source qui ont popularisé le RAG sont conçus pour démontrer, pas pour produire. Ce sont des concaténations élégantes d'abstractions dans lesquelles chaque couche cache une hypothèse non dite : que vos PDF aient une OCR décente, que vos photos aient déjà été décrites, que vos tableaux suivent une convention, que le modèle d'embedding parle réellement votre langue (spoiler : beaucoup ne parlent bien que l'anglais), que votre archive ait déjà été nettoyée des doublons. Lorsque l'une de ces hypothèses saute – et au moins une saute toujours, souvent même trois – le système ne cesse pas de fonctionner. Pire : il cesse de bien fonctionner, mais continue de donner des réponses. Des réponses fluides, assurées, et souvent déconnectées de la vérité.

Il y a une phrase qui circule parmi ceux qui construisent ces systèmes par métier, et que vous ne lirez jamais dans les tutoriels : "Le RAG est facile à faire, et difficile à bien faire." Entre la première démo et le service en production, il y a un abîme qui ne se comble pas en ajoutant des GPU ou en changeant de modèle. Il se comble en comprenant une chose inconfortable : lorsque vous construisez un RAG d'entreprise, vous n'écrivez pas du code. Vous concevez un petit moteur de recherche obstiné, sur mesure pour vos documents, avec toutes les décisions éditoriales que cela implique — ce qui est du bruit, ce qui est du signal, ce qui doit être indexé deux fois, ce qui doit être jeté. Seulement, dans les tutoriels en dix lignes, ces choix sont pris à votre place, une fois pour toutes, par quelqu'un qui n'a jamais vu vos documents. Et ils sont presque toujours les mauvais pour votre cas.