Lorsque j’ai commencé à travailler sur un RAG juridique, je pensais que la difficulté principale serait le benchmark.
Je voulais comparer rapidement embeddings, rerankers, modèles de réponse, qualité des citations et performances, tout en reproduisant les mêmes tests à la demande.
Finalement, le benchmark a été relativement rapide à construire.
Le vrai problème était ailleurs.
Il fallait d’abord savoir ce qu’était une bonne réponse.
Et cela, aucun framework ne pouvait le décider à notre place.
Le benchmark ne vaut que par sa vérité terrain
Pour évaluer sérieusement notre système, nous avions besoin de qrels : des jeux de questions associés aux réponses et documents pertinents servant de vérité terrain.
Les premiers jeux transmis par les experts métier étaient trop peu exigeants.
Les résultats étaient presque trop bons. Plusieurs configurations très différentes obtenaient des scores élevés, au point qu’il devenait difficile de distinguer sérieusement les embeddings, les modèles de langage ou les stratégies de reranking.
Techniquement, notre benchmark fonctionnait.
Mais il mesurait une vérité terrain trop faible pour être vraiment utile.
Lorsque les qrels sont devenus plus précis et plus difficiles, les écarts entre les systèmes sont enfin apparus.
Cette expérience m’a appris quelque chose de simple :
un benchmark parfaitement reproductible peut reproduire parfaitement une mauvaise vérité terrain.
Dans un projet de ce type, l’expert métier n’est donc pas une personne que l’on consulte occasionnellement.
Il est au cœur du produit.
L’expert métier avant le modèle
Si je devais aujourd’hui classer les trois éléments les plus critiques d’un RAG métier, je placerais d’abord les experts métier, puis l’interface utilisateur, et seulement ensuite le benchmark.
Un modèle peut avoir ingéré énormément de droit et produire des réponses impressionnantes, sans posséder l’expérience située des juristes qui l’utiliseront : leurs contraintes, leurs risques et leurs critères de confiance.
Sans eux, nous pouvons fabriquer quelque chose de techniquement réussi et fonctionnellement inutile.
Je considère même qu’une entreprise qui ne peut pas dégager suffisamment de temps à ses experts métier n’est probablement pas encore prête pour son projet IA.
Elle peut avoir le budget, les développeurs et les meilleurs modèles disponibles. Si personne ne peut réellement expliquer ce qu’est une bonne réponse, examiner les erreurs et préciser les cas difficiles, nous automatisons quelque chose que nous n’avons pas suffisamment défini.
L’UI n’est pas la décoration finale
L’autre grande découverte concernait l’interface.
Au départ, j’avais tendance à la considérer comme une couche relativement tardive : une fois le moteur solide, nous déciderions comment présenter les réponses.
C’était une erreur.
Les juristes ne voulaient pas simplement un chatbot affichant quelques textes de loi proches d’une question. Leurs besoins variaient selon leur secteur, leur expérience et leur manière de travailler.
L’interface révélait donc le véritable besoin.
Et lorsque cette réflexion arrivait tard, certaines décisions prises plus bas dans la chaîne devaient parfois être revues.
Quels champs conserver ? Quelles métadonnées extraire ? Comment relier des documents entre eux ? Comment harmoniser des millions de documents issus de sources très différentes ?
Avec du HTML structuré, comme certaines sources de Légifrance, le problème restait maîtrisable. Avec d’autres supports, différents codes ou des textes européens, l’architecture documentaire devenait elle-même une question métier.
Transformer un document en texte n’était donc qu’une petite partie du problème.
La vraie question devenait :
quelles informations devons-nous préserver aujourd’hui pour permettre les usages de demain ?
Savoir construire… puis savoir arrêter
Le projet a finalement connu une conclusion que je considère comme l’un de ses meilleurs enseignements.
Nous avons arrêté de le développer.
Nos clients avaient découvert entre-temps une solution juridique clé en main proposant déjà des fonctionnalités auxquelles ils n’avaient pas pensé au début du projet.
Nous avons alors comparé le développement restant, son coût, le prix des licences et les avantages de notre approche interne.
Le coût du développement était trop élevé face à la solution existante.
Continuer aurait surtout permis de dire que nous avions terminé notre propre RAG.
Ce n’était pas un objectif suffisant.
Je ne considère donc pas cet arrêt comme un échec.
Le meilleur résultat d’un projet technique peut parfois être de décider de ne pas terminer le produit technique.
Ce que je ferais aujourd’hui
Si un client revenait avec un projet similaire, ma première proposition ne serait probablement pas de développer.
Je commencerais par demander suffisamment de disponibilité aux experts métier pour construire une roadmap aussi exhaustive que possible de leurs besoins et de l’usage final attendu.
Ensuite, je testerais les solutions existantes et comparerais leurs capacités et leurs coûts.
Puis j’examinerais les contraintes spécifiques : souveraineté, confidentialité, corpus propriétaires, auditabilité, fonctionnalités particulières, coûts à grande échelle ou exigences de sécurité.
Mon premier livrable serait probablement une étude comparant trois scénarios :
acheter, construire, ou combiner les deux.
Et je demanderais volontiers un forfait uniquement pour ce travail.
Si la meilleure conclusion est d’acheter quelques licences plutôt que de financer plusieurs mois de développement, alors cette mission aura parfaitement rempli son rôle.
Je ne cherche pas à remplir des journées de développement.
Je cherche d’abord une solution satisfaisante pour le client dans la durée.
L’abandon conscient
La question devient encore plus intéressante avec les agents IA.
Imaginons qu’un agent open source puisse demain ingérer les documents, proposer un chunking, créer les embeddings, indexer, reranker, tester plusieurs modèles, produire les citations et générer une interface acceptable.
Je serais ravi de lui abandonner une grande partie de ces tâches.
Mais ce serait un abandon conscient.
Automatiser l’exécution ne signifie pas abandonner le contrôle.
Je conserverais mes propres mesures, mes benchmarks et une traçabilité complète, quitte à confier à d’autres agents une partie de la surveillance.
Puis je chercherais encore où placer l’humain dans la boucle.
Développeurs et experts métier devraient pouvoir reprendre la main lorsqu’un système dérive, qu’un usage change ou qu’une décision engage une responsabilité importante.
La question n’est donc plus seulement :
humain ou IA ?
Elle devient :
quelles tâches pouvons-nous abandonner consciemment à la machine, et où devons-nous conserver une responsabilité humaine ?
Et si je me trompais ?
Il existe évidemment de très bonnes raisons de continuer à construire des RAG sur mesure.
Une organisation peut avoir de fortes contraintes de souveraineté, des données sensibles, un corpus très spécifique ou un besoin d’auditabilité absent des solutions existantes.
Dans ces cas, la maîtrise de la chaîne complète reste précieuse.
Je ne pense donc pas que le RAG soit devenu inutile, ni qu’un agent puisse aujourd’hui remplacer toute l’expertise nécessaire à un système métier critique.
Je pense plutôt que la question économique et technique doit être reposée régulièrement.
Ce qui nécessitait hier plusieurs semaines de développement peut devenir demain une fonctionnalité disponible localement en quelques minutes.
Et lorsqu’une brique devient une commodité, continuer à la reconstruire par habitude n’est pas nécessairement une preuve de maîtrise.
Qui doit juger la machine ?
La même prudence s’applique à l’évaluation automatisée.
Utiliser un LLM pour juger les réponses d’un autre LLM peut être pertinent dans certains contextes.
Pour des tâches peu critiques, cela peut faire gagner énormément de temps.
Dans le juridique, le médical ou d’autres domaines où une erreur peut avoir des conséquences importantes, je suis beaucoup plus réservé.
Même si un jour un système dépasse statistiquement les meilleurs experts humains dans un domaine, cela ne répondra pas automatiquement à cette question :
qui accepte les conséquences lorsque la décision est mauvaise ?
Performance et responsabilité ne sont pas la même chose.
Pour moi, l’IA doit rester un complément de l’humain avant de devenir, par défaut, son remplaçant.
Alors, faut-il encore construire toute la chaîne RAG soi-même ?
Parfois oui.
Parfois non.
Mais je crois aujourd’hui que la meilleure compétence n’est peut-être plus de savoir tout construire.
Elle consiste aussi à savoir quoi automatiser, quoi mesurer, quoi confier à l’humain… et quand décider de ne rien construire du tout.