> For the complete documentation index, see [llms.txt](https://guides.ia.numerique.gouv.fr/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://guides.ia.numerique.gouv.fr/guides/guide-de-construction-dun-assistant-conversationnel-base-sur-du-rag/faire-du-rag-deux-realites-tres-differentes.md).
# « Faire du RAG » : deux réalités très différentes
Aujourd'hui, de nombreuses solutions permettent de "faire du RAG" en quelques clics : importer ses documents dans un outil clé en main, poser une question, et obtenir une réponse fondée sur ces documents.
Pour un certain nombre de cas d'usage, cette approche fonctionne et suffit.
Pour d'autres, elle ne suffira pas et c'est précisément là que commence le travail décrit dans ce guide.
## **Quand une solution clé en main peut suffire**
Une approche simple et "naïve" du RAG donne généralement des résultats satisfaisants lorsque plusieurs conditions sont réunies.
* Le **corpus est restreint et stable** : quelques dizaines de documents qui ne changent pas souvent (une documentation interne, un guide de procédures, une FAQ).
* Les **documents sont bien structurés et principalement textuels**, sans tableaux complexes, sans annexes graphiques, sans renvois croisés entre articles.
* Les questions attendues sont relativement prévisibles et portent sur des informations explicitement présentes dans les textes.
* La **tolérance à l'erreur est raisonnable** : une imprécision dans la réponse n'a pas de conséquence juridique, financière ou réputationnelle grave.
* L'équipe ne dispose pas de profils techniques dédiés pour maintenir un pipeline sur mesure.
**Dans ce cas, un assistant généraliste est le bon choix. Il permet de tester rapidement la valeur d'un assistant conversationnel sans mobiliser de ressources techniques lourdes.**
## **Quand le travail technique doit être approfondi**
En revanche, dès que l'on s'éloigne de ces conditions, les limites apparaissent. C'est le cas notamment lorsque :
* le **corpus est volumineux et hétérogène**, plusieurs centaines ou milliers de documents de formats variés (arrêtés, notes, règlements, tableaux, images, cartes). Les outils clé en main n'offrent généralement pas de contrôle sur la manière dont ces documents sont découpés, indexés et recherchés;
* le **vocabulaire est très spécialisé ou technique** (codes de zone, références juridiques, nomenclatures métier), la recherche purement sémantique peut passer à côté de correspondances exactes pourtant essentielles;
* les **documents évoluent fréquemment** et qu'il faut garantir que le système répond toujours sur la version en vigueur, pas sur un texte obsolète;
* la **précision factuelle est critique** : un montant erroné, une date incorrecte, une zone géographique confondue peuvent avoir des conséquences réelles pour l'usager ou l'agent qui s'appuie sur la réponse;
* on a besoin de filtrer finement les résultats par métadonnées (type de texte, zone géographique, date de validité) pour éviter que le système remonte des documents hors contexte.
Dans ces situations, il ne s'agit plus simplement d'alimenter un outil avec des fichiers. Il faut comprendre et maîtriser chaque étape du pipeline, du parsing au chunking, du choix du modèle d'embedding à la stratégie de recherche, de la conception du prompt à l'évaluation des réponses.
C'est un **travail d'ingénierie itératif, qui nécessite des compétences techniques**, une collaboration étroite avec les métiers, et une capacité de mesure dès le départ.
**Ce guide s'adresse à cette seconde situation. Il accompagne les équipes qui ont identifié un cas d'usage où la qualité des réponses est un enjeu fort, et où un pipeline RAG maîtrisé est nécessaire pour atteindre le niveau de fiabilité attendu. Il ne s'oppose pas aux solutions clé en main, il commence là où elles s'arrêtent.**
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://guides.ia.numerique.gouv.fr/guides/guide-de-construction-dun-assistant-conversationnel-base-sur-du-rag/faire-du-rag-deux-realites-tres-differentes.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.