Agent ou base RAG : lequel choisir pour quel cas métier

La question revient à presque chaque premier rendez-vous. Un dirigeant ou un responsable finance a identifié un sujet, une tâche qui mange du temps ou une connaissance que personne ne retrouve, et il veut savoir par quoi commencer. La confusion porte presque toujours sur l'outil, pas sur le besoin. On parle d'IA en général, alors qu'il existe deux objets techniques distincts, avec deux usages distincts : l'agent et la base RAG.

Choisir le mauvais des deux coûte cher. Une base de connaissance là où il fallait un agent, et le travail répétitif reste à faire à la main. Un agent là où il fallait une base interrogeable, et on a automatisé un processus alors qu'on cherchait juste à retrouver une information. La distinction mérite donc qu'on s'y arrête avant de lancer quoi que ce soit.

L'IA ne remplace pas vos équipes, elle leur redonne du temps. C'est la position qui guide nos recommandations. Nous sommes indépendants de tout éditeur, donc nous recommandons ce qui sert vos intérêts, pas ce qui se vend le mieux. Parfois la réponse honnête est un agent, parfois une base RAG, souvent les deux.

Agent ou base RAG

Une base RAG répond à des questions en s'appuyant sur vos documents, avec la source. Un agent va plus loin : il enchaîne des actions, appelle vos outils et exécute une tâche de bout en bout. La plupart des projets combinent les deux.

Pour un comité de direction, la formule tient en quatre mots : la base RAG sait, l'agent fait. La base RAG vous rend une réponse sourcée que vous lisez et que vous tranchez. L'agent prend la main sur une chaîne de tâches, va chercher la donnée, applique vos règles, produit un livrable et vous le présente prêt à valider.

Les deux gardent l'humain dans la boucle. La base RAG ne décide rien : elle documente. L'agent absorbe le répétitif, mais c'est vous qui validez la sortie. Aucun des deux n'est conçu pour vous mettre hors du circuit.

Quand l'agent est la bonne réponse

Un agent se justifie quand le besoin est une tâche récurrente, à étapes claires, qui consomme du temps et touche à plusieurs de vos outils. La règle d'arbitrage est simple : si vous savez décrire la tâche comme une suite d'actions, un agent peut l'absorber. Aller chercher telle donnée dans le CRM, la recouper avec une autre source, appliquer une règle de calcul, rédiger un commentaire, livrer le résultat. La méthode ne change pas : on cadre la mission, on branche l'agent à votre stack (CRM, ERP, GED, messagerie), on orchestre plusieurs agents quand la tâche le demande, et l'humain valide en sortie.

Un point de méthode que nous tenons fermement, parce qu'il sépare un agent fiable d'une démonstration qui se casse en production : le calcul reste déterministe, jamais confié au modèle. Le modèle gère les étapes floues, la lecture, l'extraction, la mise en forme. Dès qu'un chiffre doit être juste, c'est du code qui le produit, pas une génération de texte. Un agent de reporting qui laisse un modèle additionner des montants finit par halluciner un total un lundi sur dix, et la confiance s'effondre.

Trois illustrations tirées de chantiers réels, secteurs anonymisés.

Le reporting récurrent

Une école de langue passait son lundi matin à compiler un tableau de bord à la main. Un agent tire désormais la donnée du CRM et de l'API publicitaire, construit le tableau de bord hebdomadaire et rédige le commentaire analytique chaque lundi matin. L'arbitrage s'est tranché sur un détail : la même métrique pouvait être lue dans le CRM ou dans la console publicitaire, avec des écarts. La règle posée au cadrage désigne le CRM comme source de vérité pour les ventes, la console seulement pour le coût. Sans cette règle, l'agent aurait produit un tableau cohérent en apparence et faux sur le chiffre qui compte.

La veille sur signal réglementaire

Pour un cabinet de corporate finance spécialisé en restructuring, un pipeline détecte les homologations d'accord de conciliation au titre de l'article L.611-10 du Code de commerce, et qualifie les cibles. La donnée est publique et le signal est précis : c'est un travail de détection et de qualification qui se répète, mieux servi par un agent en continu que par une veille humaine intermittente. Le piège ici n'est pas la détection, c'est le bruit. Sans règle de qualification stricte, un signal réglementaire générique remonte des dizaines de cibles hors cible et noie l'utile.

L'audit forensic en première passe

Dans une démonstration d'audit d'états financiers, un agent forensic ingère des états, recoupe les agrégats et signale anomalies et incohérences avant la revue humaine. L'agent ne remplace pas l'auditeur. Il prépare le terrain et pointe ce qui mérite un regard. La décision reste à l'auditeur : l'agent fait la passe mécanique, vous gardez le jugement.

Le point commun de ces trois cas : une tâche qui se répète, des étapes qu'on peut écrire, des outils à connecter. Dès que ces conditions sont réunies, l'agent est probablement le bon outil.

Quand la base RAG est la bonne réponse

La base RAG répond à un autre besoin : vous avez beaucoup de connaissance, elle est dispersée, et la retrouver coûte du temps ou produit des réponses approximatives. Toute votre connaissance devient interrogeable, sans la sortir de chez vous.

Contrats, mails, données ERP, archives, jurisprudence : tout cela devient une base interrogeable en langage naturel. Vous posez une question comme à un collègue, et le système vous rend une réponse avec la source exacte, à la phrase près. La recherche est hybride, elle combine le lexical (les mots exacts) et le vectoriel (le sens), pour ne pas rater une réponse formulée autrement que la question. Le principe non négociable : aucune hallucination silencieuse. Si l'information n'est pas dans vos documents, le système ne l'invente pas.

La base RAG est donc indiquée quand le besoin se formule comme une question plutôt que comme une tâche. Non pas faire ce travail à ma place, mais retrouver ce que nous savons sur ce sujet et montrer d'où ça vient. Si la valeur recherchée est de répondre vite et juste à des questions sur un corpus que vous possédez, c'est une base RAG, pas un agent.

Ce qui se passe sous le capot d'une base RAG

Savoir comment une réponse sourcée se fabrique est utile, parce que c'est ce qui garantit qu'elle est vérifiable. Le pipeline suit six étapes :

1. ingest : on récupère vos sources, ERP, GED, mails, contrats ;
2. embed : on découpe vos documents en segments cohérents par le sens (chunking sémantique), puis on vectorise chaque segment ;
3. retrieve : on cherche les passages pertinents en mode hybride, tsvector pour le lexical, pgvector pour le vectoriel ;
4. rerank : on reclasse par fusion RRF pour ne garder que les passages les plus pertinents ;
5. generate : un modèle ouvert, servi chez vous, rédige la réponse ;
6. cite : la réponse arrive avec sa source vérifiable.

L'étape qui compte pour la confiance est la dernière. Chaque réponse renvoie à un passage précis de vos documents. Vous ne croyez pas le système sur parole, vous remontez à la source. C'est ce qui rend une base RAG défendable face à un comptable, un associé ou un fonds, qui ne signeront jamais sur une réponse qu'ils ne peuvent pas tracer.

La plupart des projets combinent les deux

Dans la pratique, agent et base RAG ne sont pas concurrents. Ils s'imbriquent. Un agent qui exécute une tâche a souvent besoin de connaissance pour bien la faire, et il interroge alors une base RAG comme source de vérité avant d'agir.

C'est ce que nous appliquons sur notre propre R&D. Toute notre connaissance interne est indexée et interrogeable, en recherche hybride, avec réponses sourcées. Nos agents interrogent cette base avant tout appel externe, ce qui les empêche de partir sur une donnée fausse ou périmée. Cette imbrication agent vers RAG est la forme que prend l'essentiel de nos projets : l'agent pilote la tâche, la base RAG lui fournit le contexte fiable au bon moment.

La conséquence pratique : la bonne question n'est pas toujours agent ou RAG, mais par lequel commencer et comment les articuler ensuite. On démarre souvent par la brique qui débloque le plus de valeur tout de suite, puis on ajoute l'autre. C'est ce qu'on tranche au cadrage.

Comment trancher en pratique

Trois questions, dans l'ordre, suffisent à orienter le choix.

Est-ce une tâche récurrente, à étapes claires, qui touche plusieurs outils ? Si oui, c'est un agent. Reporting, veille sur signal, première passe d'audit entrent dans cette case.

Est-ce un besoin de retrouver et restituer de la connaissance que vous possédez, avec la source ? Si oui, c'est une base RAG. Contrats, archives, jurisprudence, documentation interne entrent dans cette case.

Les deux à la fois ? C'est le cas le plus fréquent. On définit alors la séquence : par quelle brique on commence, et où l'une appelle l'autre.

Vous n'avez pas à trancher seul. Notre méthode commence par un diagnostic gratuit de trente minutes en visio, où l'on qualifie le besoin et où l'on vous dit honnêtement lequel des deux outils sert votre cas, ou si c'est une combinaison. Vient ensuite le cadrage (1 900 euros, livrable écrit, déductible du build si le projet continue), qui pose l'architecture et le périmètre. Puis le build sur devis, puis le run mensuel avec SLA. Vous savez ce que vous payez à chaque étape, et vous décidez d'avancer à chaque palier.

Pourquoi notre conseil est neutre sur ce choix

Nous ne vendons pas de licence. Nous n'avons donc aucun intérêt à vous pousser vers un agent plutôt qu'une base RAG, ou l'inverse : notre revenu vient du système livré, pas d'un abonnement à reconduire.

Concrètement, vos données restent chez vous, en UE. Nous livrons des agents en production et des bases interrogeables, pas des recommandations sur papier. Les modèles sont ouverts et servis chez vous, donc pas de lock-in, et le coût se décompose en un setup puis un run prévisible. Cette structure est ce qui nous permet de vous dire, sans arrière-pensée commerciale, si votre besoin appelle un agent, une base RAG, ou les deux.

Questions fréquentes

Quelle différence entre un agent et une base RAG ?

Une base RAG répond à des questions en s'appuyant sur vos documents, avec la source. Un agent va plus loin : il enchaîne des actions, appelle vos outils et exécute une tâche de bout en bout. La plupart des projets combinent les deux.

Comment savoir lequel correspond à mon besoin ?

Décrivez votre besoin à voix haute. S'il sort comme un verbe d'action sur plusieurs outils, qu'on peut répéter chaque semaine, c'est un agent : reporting, veille, première passe d'audit. S'il sort comme une question dont la réponse vit déjà dans vos documents, c'est une base RAG : interroger des contrats, des archives, une jurisprudence. Quand les deux apparaissent, le cadrage fixe par quelle brique démarrer.

Mes données quittent-elles l'entreprise ?

Non. La base RAG rend votre connaissance interrogeable sans la sortir de chez vous, et les modèles ouverts sont servis chez vous, donc vos données restent en UE. Ce paramètre se traite à l'architecture, au cadrage, avant l'implémentation, parce qu'il est coûteux à corriger une fois le système en place.

Un agent ou une base RAG va-t-il remplacer mes équipes ?

Non, ce n'est pas l'objectif. L'agent absorbe le répétitif et la base RAG fournit la connaissance sourcée, mais le jugement et la décision restent à vos équipes. L'IA leur redonne du temps sur le travail à valeur, elle ne les sort pas du circuit.

Par quoi commence-t-on concrètement ?

Par un diagnostic gratuit de trente minutes en visio, où l'on qualifie votre besoin et où l'on vous dit lequel des deux outils sert votre cas. Si la piste est confirmée, on passe au cadrage (1 900 euros, livrable écrit, déductible du build si le projet continue) qui pose l'architecture. Viennent ensuite le build sur devis puis le run mensuel avec SLA. Vous décidez d'avancer à chaque étape.