L'IA d'entreprise ne doit pas remplacer les experts : voici pourquoi

Dans la série Enterprise Document Intelligence, l'idée centrale est simple : un système RAG d'entreprise doit amplifier les experts, pas les remplacer. Cette philosophie guide chaque choix technique de l'architecture. Si vous ne retenez qu'une seule chose de cette série, c'est celle-ci. Parce que la plupart des erreurs en production viennent d'avoir oublié ce principe.

UN SYSTÈME QUI AMPLIFIE, PAS QUI REMPLACE

Cette série explique comment construire des systèmes RAG qui amplifient les experts travaillant avec leurs propres documents. Pas comment créer une intelligence documentaire universelle qui les remplace. L'idée semble modeste, mais elle change presque tous les choix architecturaux. Le rôle du système ? Scaler le jugement humain qui existe déjà : l'avocat qui a lu mille contrats, l'assureur qui trouve une clause déductible sans réfléchir, l'agent de conformité qui sait quelle phrase l'auditeur va vérifier. Ces experts sont la source de vérité. Le système, lui, gère le volume, trouve les passages en quelques secondes, compare les documents systématiquement. Il ne prétend pas être l'expert.

Tous les autres arguments de la série découlent de cette thèse. Les bases de vecteurs sont un dernier recours, parce que l'expert connaît déjà les mots-clés. Les dispatchers déterministes battent les agents autonomes, car l'expert a besoin de vérifier ce qui s'est passé. Les dictionnaires d'experts battent les plongements affinés, car le vocabulaire de l'expert est plus riche que toute formule IDF ou espace vectoriel ne pourrait capturer.

LE CLASH ENTRE L'IT ET LES EXPERTS

Du côté de l'IT, on suit les conseils des vendeurs et des conférences : découper chaque document, le pousser dans une base de vecteurs, plonger chaque requête, et faire confiance à la similarité cosinus pour trouver le bon passage. On construit le système, on l'exploite, et si on demande pourquoi un passage précis est revenu, peu de gens savent répondre. L'architecture est opaque, même pour ceux qui l'ont déployée.

Du côté des experts, des décennies de lecture accumulée. Des avocats qui ont lu mille contrats. Des assureurs qui ont évalué dix mille polices. Des agents de conformité qui peuvent citer la clause qu'un auditeur va demander avant même qu'il n'arrive. Demandez-leur comment ils cherchent un document. La réponse honnête est presque toujours la même. Ils ouvrent le PDF, appuient sur Ctrl+F, tapent un mot-clé qu'ils savent fonctionner dans leur corpus, trouvent le passage. Si le mot-clé ne marche pas, ils vont à la table des matières, localisent la bonne section, scannent ligne par ligne. C'est la méthode de Recherche sur laquelle des décennies d'expertise ont convergé.

Le problème n'est pas anodin. Le système de l'IT est opaque, même pour ses créateurs. La méthode de l'expert est précise mais ne scale pas. La solution naturelle de la série ? Les réunir : prendre la méthode que l'expert connaît déjà (recherche par mots-clés ancrée sur un vocabulaire réel, puis navigation dans la table des matières quand les mots-clés échouent) et utiliser le LLM pour la scaler. Les LLM sont désormais assez puissants pour que l'étape de récupération n'ait plus besoin d'être maline pour compenser. Le réflexe de 2022, empiler des astuces de plongements sur un modèle de génération faible, résolvait un problème qui n'existe plus avec la même intensité. La récupération peut rester proche du flux de travail naturel de l'expert sans perdre en qualité de réponse.

DEUX FAÇONS DE RÉPONDRE À UNE QUESTION, DEUX MONDES DIFFÉRENTS

En dessous des deux camps se trouve une distinction à énoncer clairement. Il existe deux façons de répondre à une question, et elles ne sont pas la même opération :

1. Répondre à une question dont la réponse est déjà connue et documentée. Exemple : « Quel est le taux de TVA applicable en France pour les produits électroniques en 2024 ? » La réponse est dans un texte officiel. Le travail consiste à trouver ce texte et à le restituer fidèlement.

2. Répondre à une question dont la réponse dépend du jugement d'un expert sur des documents spécifiques. Exemple : « Cette clause dans ce contrat de 2020 est-elle valable face à la nouvelle réglementation européenne ? » Ici, la réponse dépend de l'interprétation de l'expert. Le système doit l'aider à trouver les passages pertinents, mais pas décider à sa place.

Le travail d'entreprise relève du deuxième cas. Et le reste de la série garde ces deux phases séparées.

Copier la méthode de l'expert de si près n'est pas une question de style. L'enjeu n'est pas que les bases de vecteurs sont toujours fausses. L'enjeu est qu'adopter une méthode que l'expert ne reconnaît pas, sur des documents qu'il connaît par cœur, est le moyen le plus rapide de perdre sa confiance. Sans confiance, le système n'est pas utilisé. Et un système qui n'est pas utilisé n'a aucune valeur, peu importe à quel point ses benchmarks semblent impressionnants.

LE RÉFLEXE DE COPIER LES MODÈLES GÉNÉRIQUES EST DANGEREUX

Ce qui a fonctionné dans le ML d'entreprise, c'était le travail spécifique au domaine. Prévision actuarielle adaptée à l'assurance. Classification de documents calibrée sur le vocabulaire interne. Scoring de risque exploitant les variables que les experts du domaine avaient déjà identifiées comme prédictives. Les systèmes qui ont apporté de la valeur étaient ceux qui s'appuyaient sur l'expertise existante, pas ceux qui tentaient de l'apprendre de zéro.

Le RAG répète ce schéma exact. Les entreprises copient OpenAI, injectent leurs données dans des produits RAG gérés génériques, vectorisent tout par défaut. Les modes d'échec sont les mêmes que pour le ML : trop de généralité, pas assez d'ancrage dans le domaine, aucune réponse pour les cas que les benchmarks n'ont pas couverts. L'alternative est la même que celle qui a fonctionné il y a dix ans : le RAG spécifique au domaine. Codifier l'expertise qui existe déjà. Utiliser la structure des documents que l'équipe connaît déjà. Amplifier l'expert au lieu de le contourner.

Ce parallèle compte pour deux raisons. Il donne à l'argument une profondeur historique (« on a déjà vu ce film »). Et il offre un cadre constructif (« on n'est pas contre OpenAI ; on dit que la trajectoire est connue et que l'alternative est de construire pour notre contexte, pas pour le leur »).

QUATRE CONDITIONS POUR QUE LA THÈSE S'APPLIQUE

Ces quatre conditions sont remplies dans la plupart des travaux d'intelligence documentaire d'entreprise. Courtiers en assurance, cabinets d'avocats, hôpitaux, banques, agences gouvernementales, toute organisation où des experts travaillent avec des documents structurés sous surveillance réglementaire.

Là où ça ne fonctionne pas ? La recherche ouverte sur le web, les chats grand public, l'exploration d'un corpus où aucun expert n'existe, les contextes où les questions sont illimitées. Là, la récupération généraliste et les agents autonomes ont plus de sens. Le compromis change : on sacrifie l'audit et la reproductibilité, mais on n'a pas non plus d'expert qui en aurait besoin. Ce sont des problèmes différents, et l'architecture doit être différente. La position de la série est défendable précisément parce qu'elle admet où elle ne s'applique pas.

TROIS DISCIPLINES POUR TRANSFORMER LA PHILOSOPHIE EN CODE

Ces trois éléments ne sont pas des fonctionnalités. Ce sont la discipline qui rend les choix architecturaux spécifiques de la série défendables sur de nombreuses années et avec de nombreux contributeurs.

Les quatre briques (analyse, analyse de question, récupération, génération) sont communes à la plupart des architectures RAG. Ce qui est spécifique ici, c'est que chacune d'elles reflète quelque chose que l'expert fait mentalement et l'amplifie sur les axes qu'un flux de travail manuel ne peut pas atteindre. Chaque article suivant de la série développe une de ces quatre idées en code.

L'ANALYSE : COPIER LE PREMIER SCAN DE L'EXPERT

L'analyse reflète la façon dont l'expert scanne un document à la première lecture : saisir le sujet, trouver la liste des sections, repérer où vivent les chiffres. L'analyseur effectue ce scan une fois et conserve le résultat. Tout ce qui est manqué ici ne peut pas être récupéré en aval. C'est pourquoi l'analyse est le choix le plus important dans le pipeline.

L'ANALYSE DE QUESTION : COPIER LE REFLEXE CTRL+F

L'analyse de question reflète le réflexe Ctrl+F : l'expert commence par taper deux ou trois mots-clés. Cette brique conserve cela et l'amplifie sur deux axes que Ctrl+F ne peut pas atteindre (co-occurrence et expansion par dictionnaire d'expert), puis divise la question en un brief de récupération et un brief de génération que les briques en aval consomment séparément.

LA RÉCUPÉRATION : COPIER LE TRIAGE DE L'EXPERT

La récupération reflète le triage que l'expert fait après que Ctrl+F ait retourné trente résultats : éliminer ceux qui sont hors sujet, garder les quelques-uns qui méritent un deuxième regard. Cette brique le fait à l'échelle et conserve trois choses séparément que « top-k chunks » fusionne : l'ancrage (où la correspondance atterrit), la portée (ce qui va à la génération), et le contexte (ce que l'expert lit par réflexe). Le critère est « l'ensemble qui mérite un deuxième passage humain », pas « top-k par similarité cosinus ».

LA GÉNÉRATION : ÉVITER LA FABRICATION

La génération est là où vit la discipline contre la fabrication : une reformulation fidèle de ce que dit la portée récupérée, plus la citation pour la vérifier, jamais une paraphrase qui dérive. Le LLM remplit un schéma Pydantic typé (réponse, citations de lignes, réponse_trouvée, confiance, avertissements) que l'expert contrôle en écrivant le schéma et l'invite.

Chaque brique respecte la même discipline : entrée structurée, sortie structurée, pas de « soupe de chaînes » à aucune jonction. Cela rend le système interrogeable, auditable, rejouable, et connectable sur des années de questions et réponses accumulées. La partie IV (articles 14, 15, 16, 17) montre ce que deviennent ces quatre mêmes briques à l'échelle du corpus, avec un corpus_index en forme de SQL, une ontologie dans cinq tables relationnelles, et une QA au niveau du corpus. La partie V (articles 18 à 22) rend l'architecture opérationnelle sur des années.

SIX PRINCIPES QUI DÉCOULENT DE LA THÈSE

L'objectif de cet article est de montrer que ces positions ne sont pas indépendantes. Elles forment un seul argument avec six conséquences visibles.

Cette épilogue est l'ancrage philosophique de la série. L'idée de considérer le jugement expert comme une ressource renouvelable vient de Tetlock et Gardner (Superforecasting, 2015). La philosophie de l'outil comme amplificateur, directement applicable à l'architecture RAG, vient de Norman (The Design of Everyday Things, 1988). Le document d'Anthropic Building Effective Agents (décembre 2024) est le cadre industriel de quand les flux de travail battent les agents. L'article fondateur derrière le « critère de l'expert à amplifier » est celui de Bainbridge, Ironies of Automation (1983) : plus l'automatisation est avancée, plus la contribution humaine compte.

Les patterns d'agents où l'agent utilise encore les briques auditées que l'expert a curatées sont des travaux suivants.

UNE AUTRE APPROCHE POUR LES BASES DE VECTEURS : STRUCTURE ET RAISONNEMENT

Une nouvelle façon de construire un RAG vectoriel — conscient de la structure et capable de raisonnement. Open source. Installation en 5 minutes. Essayez-le vous-même.

Construire une base de connaissances pour les modèles d'IA n'est pas une tâche ponctuelle mais un processus itératif…

La plupart des systèmes d'évaluation de LLM reposent sur des scores vagues et des jugements humains déguisés en métriques. Je…

La plupart des systèmes RAG sont optimisés pour la qualité des réponses, pas pour le coût — et cet angle mort devient coûteux…

De l'installation d'Ollama au lancement d'OpenCode avec un modèle local, étape par étape.