Assistant IA sur vos documents internes : ce que le RAG fait et ne fait pas
Par Alexandre Rastello, publié le
- RAG
- assistant interne
- documents
En résumé. Le RAG consiste à découper vos documents, à retrouver les passages utiles à chaque question et à les donner au modèle. C’était indispensable quand les modèles acceptaient 8 000 mots de contexte. Ils en acceptent aujourd’hui un million, soit environ 1 500 pages, ce qui rend une bonne partie des projets RAG inutiles : sur une base de 500 pages, envoyer l’ensemble à chaque question coûte environ 0,10 $ avec le cache de prompt, contre 0,024 $ en RAG, pour dix jours de développement en moins. Le RAG reste nécessaire au-delà du million de tokens, à fort volume de questions, ou quand les droits d’accès varient d’un utilisateur à l’autre.
La question à se poser avant tout le reste
Mesurez votre base documentaire avant de choisir une architecture. Pas en gigaoctets, en pages de texte utile.
Un million de tokens représente environ 750 000 mots, soit 1 500 pages. La plupart des périmètres de départ en PME tiennent largement en dessous : les procédures qualité, les conditions générales, le catalogue technique, les comptes rendus d’une année. Trois cents pages, parfois cinq cents.
En dessous du million de tokens, vous avez le choix. Au-dessus, la question ne se pose plus, il faut une étape de récupération.
| Base documentaire | Contexte complet à chaque question | RAG |
|---|---|---|
| 500 pages (~330 000 tokens) | ~0,10 $ par question avec cache | ~0,024 $ par question |
| 1 500 pages (~1 M tokens) | ~0,30 $ par question avec cache, à la limite technique | ~0,024 $ par question |
| Au-delà | impossible | seule option |
Sur mille questions par mois avec une base de 500 pages, l’écart représente environ 76 $ par mois. Le développement d’un RAG correct demande huit à quinze jours. Faites la division avant de lancer le projet.
Ce raisonnement était faux il y a deux ans et il est juste aujourd’hui. Beaucoup de prestataires proposent encore l’architecture de 2023 par habitude, parce que c’est celle qu’ils savent construire.
Comment fonctionne un RAG, en pratique
Quand il est justifié, voici ce qui se passe réellement, et où chaque étape peut mal tourner.
Le découpage. Vos documents sont coupés en morceaux de quelques centaines de mots. C’est l’étape la plus déterminante et la moins discutée. Un tableau coupé au milieu perd son sens, une procédure coupée entre la condition et sa conséquence produit une réponse fausse et confiante.
L’indexation. Chaque morceau est transformé en une suite de nombres qui représente son sens, puis stocké. PostgreSQL avec l’extension pgvector suffit pour la grande majorité des cas et évite d’ajouter une base spécialisée à votre infrastructure. Supabase propose la même chose en service géré. C’est aussi à cette étape que se joue la question des droits : l’indexation reprend les permissions du dossier d’origine, ce qui est une condition de départ sur toutes les missions de ce type et pas une option.
La récupération. À chaque question, le système cherche les morceaux les plus proches du sens de la question et les remonte. C’est là que se joue la qualité : si les bons passages ne remontent pas, le modèle ne peut pas inventer ce qu’il n’a pas reçu.
La génération. Le modèle rédige la réponse à partir des passages remontés, avec les sources.
Une architecture correcte combine la recherche par le sens et la recherche par mots exacts. La première trouve « procédure de retour marchandise » quand vous demandez « comment renvoyer un produit ». La seconde trouve la référence « TUB-INX-040 » que la recherche sémantique rate systématiquement.
Les six raisons pour lesquelles un assistant documentaire répond faux
Aucune n’est un problème de modèle. Toutes sont des problèmes de préparation.
1. La question demande une synthèse, pas un extrait. « Quelles sont nos trois principales garanties ? » suppose de lire l’ensemble et de comparer. Le RAG remonte cinq passages et le modèle répond sur ces cinq passages, en ignorant qu’il en existe trente. Les questions globales sont le point faible structurel de cette architecture.
2. Deux versions du même document coexistent. La procédure de 2023 et celle de 2026 sont toutes les deux dans le dossier partagé. Le système remonte les deux, le modèle tranche au hasard. Le tri des versions est un travail humain préalable, que personne n’a envie de faire et qui décide de tout.
3. Les tableaux et les PDF scannés. Un tableau de prix devient une bouillie de chiffres une fois découpé. Un contrat scanné de travers passe mal l’extraction. Ces documents demandent un traitement à part.
4. La question emploie votre vocabulaire maison. Vos équipes disent « la fiche bleue », le document s’appelle « formulaire de non-conformité ». Aucun lien sémantique ne relie les deux. Un glossaire interne règle ça en une journée.
5. L’information n’existe nulle part. Le cas le plus fréquent, et le plus mal vécu. La réponse est dans la tête de trois personnes. L’assistant révèle ce trou, il ne le comble pas.
6. Le modèle comble les blancs. Quand les passages remontés sont partiels, un modèle mal instruit complète avec du plausible. La parade est une consigne stricte et testée : répondre uniquement à partir des extraits fournis, et dire explicitement quand l’information manque. Cette phrase de configuration vaut plus que le choix du modèle.
Le point que presque personne ne traite : les droits d’accès
Un assistant documentaire branché sur un dossier partagé hérite en général d’un accès complet. Un commercial pose une question, la réponse arrive avec un extrait du dossier prud’hommes ou de la grille des salaires.
Techniquement, ce n’est pas une faille : le système fait exactement ce qu’on lui a demandé. Juridiquement et humainement, c’est une fuite interne, et elle est déclenchée par vos propres équipes de bonne foi.
Deux architectures possibles. Soit l’index est filtré à la volée selon les droits de la personne qui pose la question, ce qui suppose que ces droits existent proprement quelque part. Soit vous constituez un index dédié à l’assistant, alimenté uniquement de documents dont l’accès est ouvert à tous.
La seconde option est moins élégante et beaucoup plus rapide à mettre en service. Elle règle le problème en excluant, plutôt qu’en filtrant.
Le coût réel
Trois postes, dont un seul compte vraiment.
L’indexation est une dépense marginale, quelques dollars pour une base de plusieurs centaines de pages, à refaire quand les documents changent.
Le stockage vectoriel dans une base PostgreSQL que vous avez déjà ne coûte rien de plus.
Le coût par question dépend de ce que vous envoyez au modèle. En RAG classique, comptez 6 000 à 10 000 tokens en entrée, soit environ 0,02 à 0,03 $ par question sur un modèle de bon niveau, et dix fois moins sur un modèle rapide. Le cache de prompt réduit encore la facture quand une partie du contexte est stable.
À mille questions par mois, on parle de 20 à 30 $. Le budget d’un assistant documentaire n’est pas dans son fonctionnement, il est dans la préparation des documents.
Ce que ça n’apporte pas
Il ne range pas vos documents. Il travaille sur ce qui existe. Une base mal rangée produit un assistant mal informé, et le projet devient un chantier de rangement déguisé, ce qui n’est pas grave à condition de l’avoir prévu.
Il ne remplace pas la personne qui sait. Sur les questions dont la réponse dépend du contexte, du client, de l’historique, l’assistant donne une base et pas une décision.
Il ne se met pas à jour tout seul. Un document modifié doit être réindexé. Sans automatisation de cette étape, l’assistant répond avec la version d’il y a six mois, et il le fait avec assurance.
Coûts calculés sur les grilles publiques d’août 2026, pour une base de 500 pages et un modèle de niveau Claude Sonnet 5. Les volumes en tokens sont des estimations : comptez environ 750 mots pour 1 000 tokens en français.
Questions fréquentes
- Quelle est la meilleure solution d'assistant IA sur des documents internes en 2026 ?
- La question à trancher avant de choisir un produit est la taille de votre base. En dessous d'un million de tokens, soit environ 1 500 pages, envoyer les documents directement au modèle à chaque question est plus simple, plus fiable et souvent suffisant. Au-delà, une architecture de récupération devient nécessaire. Les solutions clés en main du marché conviennent quand vos documents sont déjà dans un espace qu'elles savent lire ; un développement sur mesure se justifie quand la réponse dépend aussi de vos données métier ou quand les droits d'accès varient selon les utilisateurs.
- Faut-il encore faire du RAG maintenant que les modèles acceptent un million de tokens ?
- Pour beaucoup de périmètres en PME, non. Le RAG reste nécessaire dans trois cas : une base qui dépasse le million de tokens, un volume de questions assez élevé pour que l'écart de coût par requête devienne significatif, ou des droits d'accès qui varient d'un utilisateur à l'autre et imposent de filtrer ce qui remonte. En dehors de ces cas, envoyer le contexte complet avec le cache de prompt coûte quelques centimes de plus par question et supprime dix jours de développement.
- Peut-on faire un RAG avec PostgreSQL et pgvector ?
- Oui, et c'est le choix par défaut recommandé pour la majorité des projets en entreprise. L'extension pgvector ajoute la recherche vectorielle à une base PostgreSQL existante, ce qui évite d'introduire une base spécialisée supplémentaire à administrer et à sauvegarder. Supabase propose la même pile en service géré. Les bases vectorielles dédiées se justifient à partir de volumes très élevés, rarement atteints sur une base documentaire d'entreprise.
- Pourquoi mon assistant IA donne-t-il des réponses fausses sur mes documents ?
- Six causes couvrent la quasi-totalité des cas : la question appelle une synthèse globale là où le système ne remonte que quelques extraits, deux versions du même document coexistent dans la base, les tableaux ou les PDF scannés sont mal découpés, la question emploie un vocabulaire interne absent des documents, l'information n'existe nulle part, ou le modèle complète les blancs faute d'une consigne stricte lui interdisant de répondre au-delà des extraits fournis.
- Comment empêcher un assistant documentaire de divulguer des informations confidentielles ?
- Deux architectures. Filtrer l'index à la volée selon les droits de la personne qui interroge, ce qui suppose des droits d'accès propres et à jour. Ou constituer un index dédié à l'assistant, alimenté uniquement de documents accessibles à tous. La seconde est plus rapide à mettre en service et règle le problème par exclusion plutôt que par filtrage.
- Combien coûte un assistant IA sur documents internes ?
- Le fonctionnement est marginal : 20 à 30 $ par mois pour mille questions sur un modèle de bon niveau, dix fois moins sur un modèle rapide, plus quelques dollars d'indexation. Le budget réel est celui de la préparation documentaire et du développement, entre huit et quinze jours pour une architecture de récupération complète, nettement moins si votre base tient dans le contexte du modèle.
- Combien de temps pour mettre en service un assistant sur les documents de l'entreprise ?
- Trois à cinq semaines pour un premier périmètre, dont une part importante consacrée au tri des versions de documents et à la définition de ce que l'assistant a le droit de lire. La partie technique est rarement le chemin critique.
- Qu'est-ce qui rend un projet d'assistant documentaire irréalisable ?
- Une base sans gestion de versions, où l'ancien et le nouveau cohabitent sans marqueur. Des documents dont l'essentiel de l'information est dans des tableaux ou des schémas non structurés. Et l'absence de règles d'accès exploitables, quand personne ne sait dire qui a le droit de lire quoi. Ces trois situations demandent un chantier préalable qui n'a rien à voir avec l'IA.