---
term: 'RAG (Retrieval-Augmented Generation)'
seoTitle: 'RAG (Retrieval-Augmented Generation) : pipeline, ACL, vs fine-tuning'
headline: "Qu'est-ce que le RAG (Retrieval-Augmented Generation) ?"
slug: rag
category: ai-modern-stack
shortDefinition: "Le RAG est une technique qui récupère des documents au moment de la requête et les ajoute au prompt, pour qu'un LLM réponde à partir de données, pas de mémoire."
relatedTerms:
  - vector-database-embeddings
  - api-key-security
  - cloud-code-serverless-functions
  - access-control-lists-acl
contrastsWith:
  - vector-database-embeddings
aboutTerms:
  - 'Retrieval-Augmented Generation'
  - 'Chunking'
  - 'Grounding'
faq:
  - question: "Qu'est-ce que le RAG, en termes simples ?"
    answer: "Une technique où votre app cherche les documents pertinents dans une base de connaissances et les colle dans le prompt du LLM, pour que la réponse s'ancre dans des données réelles, actuelles ou privées plutôt que dans la mémoire figée du modèle. C'est l'examen à livre ouvert face à l'examen à livre fermé d'un LLM nu."
  - question: 'Pourquoi utiliser le RAG ?'
    answer: "Il corrige trois manques du LLM d'un coup, sans réentraînement : l'hallucination (en ancrant les réponses dans du texte récupéré), la date de coupure de l'entraînement (en allant chercher les données du jour) et le fait que le modèle n'a jamais vu vos documents privés. Et comme les sources sont connues, la réponse peut les citer."
  - question: 'Comment fonctionne le RAG ?'
    answer: "En deux phases. Offline : charger les documents, les découper en chunks, encoder chaque chunk en un vecteur, stocker le tout dans un index. Online : encoder la question de l'utilisateur, récupérer les chunks les plus similaires, les ajouter au prompt et laisser le modèle générer une réponse ancrée dans ce contexte."
  - question: 'Quelle est la différence entre le RAG et le fine-tuning ?'
    answer: "Ils changent des choses différentes. Le RAG injecte de la connaissance — faits, fraîcheur, documents privés — au moment de la requête. Le fine-tuning change le comportement — style, format, raisonnement métier — figé pendant l'entraînement. Le fine-tuning apprend comment répondre ; le RAG fournit sur quoi répondre ; les assistants spécialisés utilisent souvent les deux."
  - question: 'Les grandes fenêtres de contexte rendent-elles le RAG obsolète ?'
    answer: "Non. Même avec des fenêtres de plusieurs millions de tokens, tout empiler dans le prompt coûte bien plus cher par requête et tourne plus lentement, et les études constatent une précision qui se dégrade bien avant que la fenêtre soit pleine — le « context rot ». La fraîcheur et le contrôle d'accès exigent toujours une récupération. Le standard de 2026 est hybride : récupérer un sous-ensemble pertinent, puis raisonner dessus avec un modèle à contexte long."
  - question: "Qu'est-ce que le chunking et pourquoi est-ce important ?"
    answer: "C'est le découpage des documents en morceaux récupérables — et la qualité de la récupération en dépend fortement. Des chunks trop gros diluent la pertinence et gaspillent le budget de prompt ; trop petits, ils perdent le contexte. Une base courante est de quelques centaines de tokens avec chevauchement, même si un découpage sensible à la structure (par titre, paragraphe ou bloc de code) bat généralement les tailles fixes."
  - question: 'Le RAG élimine-t-il les hallucinations ?'
    answer: "Il les réduit ; il ne les élimine pas. Le modèle peut encore mal lire le contexte récupéré, mélanger des passages périmés et récents, ou répondre avec assurance à partir de mauvaises récupérations. Et la plupart des « hallucinations du RAG » sont des échecs de récupération déguisés — les mauvais chunks ont été ramenés, donc la réponse ancrée s'ancre dans la mauvaise matière."
  - question: "Comment empêcher le RAG de divulguer des documents qu'un utilisateur ne devrait pas voir ?"
    answer: "Filtrez la récupération par permissions, pas seulement par similarité. La recherche vectorielle classe par sens et ne sait rien de qui a le droit de lire quoi : stockez les métadonnées de contrôle d'accès avec chaque chunk et restreignez la requête aux documents que l'utilisateur qui pose la question a le droit de voir — avant la sélection top-k, pas après."
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
  - name: 'Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks (Lewis et al., 2020)'
    url: 'https://arxiv.org/abs/2005.11401'
  - name: 'Retrieval-Augmented Generation for LLMs: A Survey (Gao et al.)'
    url: 'https://arxiv.org/abs/2312.10997'
  - name: 'RAGAS — evaluation metrics'
    url: 'https://docs.ragas.io/en/stable/concepts/metrics/available_metrics/'
  - name: 'Chunking strategies for RAG — Weaviate'
    url: 'https://weaviate.io/blog/chunking-strategies-for-rag'
cta:
  title: "Le RAG, c'est du travail de backend ordinaire"
  text: "Stockez les documents, indexez les vecteurs à côté de vos données, filtrez la récupération par ACL et appelez le modèle depuis Cloud Code avec la clé côté serveur — Back4app fournit chaque pièce, sauf le prompt."
  linkText: 'Commencez gratuitement'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-09-12'
translationKey: retrieval-augmented-generation-rag
---

**Le RAG est une technique qui récupère des documents au moment de la requête et les ajoute au prompt, pour qu'un LLM réponde à partir de données, pas de mémoire.** Introduit par [Lewis et al. en 2020](https://arxiv.org/abs/2005.11401), c'est l'examen à livre ouvert face à l'examen à livre fermé d'un modèle nu : au lieu de s'appuyer sur ce qu'il a mémorisé pendant l'entraînement, le modèle consulte la matière que vous lui fournissez et répond à partir d'elle — ancré, actuel, capable d'exploiter vos données privées et, parce que les sources sont connues, *citable*. Pour un développeur backend, la vérité rassurante sous le hype est que le RAG n'est pas un framework qu'il faut adopter : c'est une boucle `for` que vous savez déjà écrire.

## Points clés

| Question | Réponse |
| --- | --- |
| Le geste | Récupérer les chunks pertinents → les ajouter au prompt → générer une réponse ancrée |
| Les trois manques qu'il comble | Hallucination · date de coupure de l'entraînement · aucun accès à vos données privées |
| vs. fine-tuning | Le RAG fournit la *connaissance* ; le fine-tuning change le *comportement* — souvent les deux |
| L'erreur dominante | Échec de récupération — mauvais chunks en entrée, réponse fausse et assurée en sortie |
| L'obligation en production | Filtrer la récupération par [permissions](/glossary/fr/listes-de-controle-d-acces-acl/), pas par la seule similarité |

## Les deux phases

```text
INGESTION (offline, une fois par document)
  charger → découper en chunks (~quelques centaines de tokens, avec chevauchement)
       → encoder chaque chunk en un vecteur
       → stocker vecteur + texte + métadonnées d'ACL dans un index

REQUÊTE (online, à chaque question)
  encoder la question → recherche par similarité des top-k chunks (souvent 5–10)
       → filtrer selon ce que CET utilisateur a le droit de lire
       → augmenter le prompt avec les chunks
       → le LLM génère une réponse ancrée dans ces chunks (+ citations)
```

Toute la phase online, côté serveur, dans une seule fonction :

**JavaScript:**

```javascript
// JavaScript — Cloud Code (cloud/main.js): RAG is a for-loop, not a framework
Parse.Cloud.define('askDocs', async (req) => {
  // 1 · embed the question (LLM API key stays server-side)
  const qVec = await embed(req.params.question);

  // 2 · retrieve — similarity search, ACL-FILTERED to this user's docs
  const chunks = await vectorSearch('DocChunk', qVec, {
    limit: 6,
    aclUser: req.user, // never retrieve what the asker can't read
  });

  // 3 · augment + generate
  const context = chunks.map((c) => c.get('text')).join('\n---\n');
  return await complete(`Answer using ONLY this context:\n${context}\n\nQ: ${req.params.question}`);
  // Answer cites the retrieved chunks — grounded, and permission-safe.
});
```

**Flutter:**

```dart
// Flutter / Dart — Back4app Flutter SDK
// The client just asks — retrieval, grounding, and ACLs happen server-side
final answer = await ParseCloudFunction('askDocs')
    .execute(parameters: {'question': 'What is our refund window?'});
print(answer.result); // grounded in the user's own documents, with citations
// No embeddings, no vector math, no LLM key on the device — RAG's backend
// is ordinary backend work: store docs, index vectors, query, call the model.
```

**Swift:**

```swift
// iOS / Swift — Back4app Swift SDK
// The client just asks — retrieval, grounding, and ACLs happen server-side
let answer: String = try await Cloud.run(
    name: "askDocs",
    parameters: ["question": "What is our refund window?"])
print(answer) // grounded in the user's own documents, with citations
// No embeddings, no vector math, no LLM key on the device — RAG's backend
// is ordinary backend work: store docs, index vectors, query, call the model.
```

**Kotlin:**

```kotlin
// Android / Kotlin — Back4app Android SDK
// The client just asks — retrieval, grounding, and ACLs happen server-side
val params = mapOf("question" to "What is our refund window?")
val answer = ParseCloud.callFunction<String>("askDocs", params)
println(answer) // grounded in the user's own documents, with citations
// No embeddings, no vector math, no LLM key on the device — RAG's backend
// is ordinary backend work: store docs, index vectors, query, call the model.
```

```mermaid
flowchart LR
  accTitle: Pipelines d'ingestion et de requête du RAG
  accDescr: Dans la phase d'ingestion, les documents sont chargés, découpés en chunks, encodés en vecteurs et stockés avec des métadonnées de contrôle d'accès dans un index vectoriel. Dans la phase de requête, la question de l'utilisateur est encodée, les chunks similaires sont récupérés puis filtrés selon les permissions de l'utilisateur, le prompt est augmenté avec eux, et le modèle génère une réponse ancrée avec citations.
  subgraph Ingest["Ingestion — offline"]
    D["Documents"] --> CH["Découpage"] --> EM["Encodage"] --> IDX[("Index vectoriel<br/>+ métadonnées d'ACL")]
  end
  subgraph Query["Requête — online"]
    Q["Question"] --> QE["Encodage"] --> R["Récupérer top-k"]
    IDX --> R
    R --> F["Filtrer par l'ACL de l'utilisateur"] --> AUG["Augmenter le prompt"] --> G["Générer une réponse<br/>ancrée"]
  end
```

## Pourquoi le RAG : les trois manques

Un LLM nu a trois faiblesses structurelles, et le RAG les traite toutes sans réentraînement. **L'hallucination** — les modèles répondent avec assurance qu'ils sachent ou non ; ancrer chaque affirmation dans du texte récupéré donne au modèle quelque chose de vrai à dire. **La date de coupure de l'entraînement** — la connaissance d'un modèle se fige au moment de l'entraînement ; la récupération va chercher les données du jour. **Les données privées** — le modèle n'a jamais vu vos documents ; la récupération est la façon dont il les lit au moment de la requête. Le bonus que les modèles à livre fermé ne peuvent pas offrir : parce que les chunks récupérés sont connus, la réponse peut **citer ses sources** comme des notes de bas de page — le plus gros avantage de confiance du RAG.

## Le RAG vs. le fine-tuning

| | RAG | Fine-tuning |
| --- | --- | --- |
| Change | La *connaissance* — ce que le modèle sait | Le *comportement* — comment il répond |
| Vitesse de mise à jour | Immédiate — ajoutez un document | Réentraîner pour changer |
| Fraîcheur | Toujours à jour | Figée à l'entraînement |
| Citations | Oui — les sources sont connues | Non |
| Forme du coût | Récupération + tokens par requête | Entraînement en amont |
| Idéal pour | Faits, documents privés, changement | Style, format, raisonnement métier |

Ce ne sont pas des rivaux : le fine-tuning apprend au modèle *comment* répondre, le RAG fournit *sur quoi* répondre, et un assistant métier spécialisé utilise fréquemment les deux — une voix affinée par fine-tuning qui répond depuis une base de connaissances récupérée.

## Le RAG est-il mort ? La question du contexte long, tranchée

Le traitement honnête que les pages génériques évitent. Les fenêtres de contexte atteignent désormais plusieurs millions de tokens, ce qui alimente l'argument récurrent du « mettez tout dans le prompt ». Trois faits maintiennent la récupération en vie. **Coût et latence :** payer le traitement d'un contexte géant à *chaque* requête est radicalement plus cher et plus lent que d'aller chercher la tranche pertinente — des ordres de grandeur, à l'échelle. **Context rot :** les études menées jusqu'en 2025 ont constaté une précision des modèles qui se dégrade bien avant que la fenêtre soit pleine — les faits pertinents enfouis dans un contexte énorme passent à la trappe, donc une fenêtre plus grande n'est pas une meilleure réponse de façon fiable. **Fraîcheur et contrôle d'accès :** un méga-prompt statique est périmé à l'instant où les données changent, et aveugle à qui a le droit de lire quoi. Le consensus de 2026 n'est pas « RAG ou contexte long » mais *les deux* — récupérer un sous-ensemble généreux, pertinent et filtré par permissions, puis raisonner dessus avec un modèle à contexte long. Le contexte long pur ne convient qu'aux corpus petits, stables et non sensibles.

## C'est dans la récupération que le RAG échoue

Le cadrage qui réorganise votre façon de déboguer un système RAG : **du déchet récupéré, c'est du déchet généré avec assurance.** La plupart des échecs imputés au modèle sont des échecs de récupération déguisés en génération — les mauvais chunks ont été ramenés, donc une réponse parfaitement fidèle s'ancre dans la mauvaise matière. Deux variables font donc réellement bouger la qualité. **Le chunking :** des morceaux trop gros diluent la pertinence et brûlent le budget de prompt ; trop petits, ils perdent le contexte qui leur donnait du sens — un découpage sensible à la structure (par titre, paragraphe, bloc de code) bat généralement les tailles fixes ([les stratégies comptent](https://weaviate.io/blog/chunking-strategies-for-rag)). **La récupération hybride :** combinez la recherche par mots-clés (termes exacts, noms, identifiants) et la recherche vectorielle (le sens), puis *re-classez* les candidats fusionnés avec un modèle de pertinence plus fort avant de construire le prompt — le rappel des deux côtés, la précision du re-ranker. Et mesurez les deux moitiés séparément, dans le vocabulaire de [RAGAS](https://docs.ragas.io/en/stable/concepts/metrics/available_metrics/) : les métriques de récupération (a-t-on ramené les bons chunks ?) face à la fidélité (chaque affirmation est-elle étayée par ce qu'on a ramené ?) — parce qu'elles échouent indépendamment et se corrigent différemment.

## La faille de sécurité que personne ne mentionne

La similarité vectorielle classe par sens et ne sait *rien* des permissions — ce qui fait d'un RAG naïf une machine à fuites de données. Encodez les documents d'une entreprise dans un index unique sans métadonnées d'accès, et la question de n'importe quel utilisateur peut récupérer n'importe quel document, parce que le rapport financier et la question du stagiaire ne sont que des points voisins dans l'espace vectoriel. Filtrer après la récupération n'est pas non plus la solution : écarter les chunks interdits après la sélection top-k divulgue leur existence et casse le contrat du top-k (vous en avez demandé six et vous en recevez deux). Le bon schéma : **stocker les métadonnées d'[ACL](/glossary/fr/listes-de-controle-d-acces-acl/) avec chaque chunk et restreindre la récupération à l'ensemble autorisé de l'utilisateur qui pose la question *avant* le classement par similarité** — une récupération filtrée par permissions, pas un affichage filtré par permissions. Le paramètre `aclUser` des onglets de code est exactement cela, et c'est la différence entre une démo et un système que vous pouvez mettre en production.

## Cas d'usage courants

- **Chat de support et de connaissance** — répondre depuis la documentation réelle de l'entreprise, avec citations, à jour à la dernière ingestion.
- **Recherche sur des corpus privés** — juridique, médical, wikis internes : la récupération par le sens que le champ de recherche par mots-clés ne vous a jamais donnée.
- **Assistants cadrés par client** — les données propres à chaque utilisateur, filtrées par ACL pour que la récupération ne franchisse jamais une frontière de tenant.
- **Analytique ancrée** — des réponses tirées d'enregistrements vivants plutôt que de la supposition périmée d'un modèle.
- **Documentation et onboarding** — un modèle qui cite le manuel au lieu de l'improviser.

## Avez-vous vraiment besoin du RAG ? Matrice de décision

| Situation | Choisissez |
| --- | --- |
| La connaissance est publique, stable, déjà dans le modèle | Le prompt nu — aucun pipeline |
| Le corpus tient dans le prompt et change rarement | Collez-le dans le prompt (avec le prompt caching) |
| Connaissance volumineuse, privée ou changeante | Le RAG — son terrain |
| Le modèle doit *se comporter* autrement | Le fine-tuning (peut-être avec du RAG) |
| Les réponses doivent citer leurs sources | Le RAG — les citations viennent gratuitement |
| Données multi-utilisateurs avec permissions | Le RAG avec récupération filtrée par ACL — obligatoire |

## Limites et trade-offs

- **Le RAG réduit l'hallucination ; il ne la supprime pas.** La fidélité doit se mesurer, pas se présumer — le modèle peut encore mal lire un bon contexte.
- **La qualité vit dans la récupération.** L'essentiel de l'effort d'ingénierie — chunking, recherche hybride, re-ranking — se situe en amont du modèle, là où sont les gains.
- **Les embeddings ont une version.** Changez de modèle d'embedding et chaque vecteur stocké doit être régénéré ; ré-encoder un grand corpus est une vraie migration.
- **Cela ajoute des pièces mobiles.** Pipelines d'ingestion, un index à maintenir, des tokens et une latence supplémentaires par requête — un coût réel qu'un corpus petit et stable peut ne pas justifier.
- **Les permissions ne sont pas gratuites.** La récupération filtrée par ACL est le travail de sécurité porteur, et c'est la partie que les démos sautent et que les incidents redécouvrent.

## Le RAG sur Back4app

Back4app est une plateforme open-source de Backend as a Service (BaaS) qui combine une base de données gérée, des API REST et GraphQL générées automatiquement, l'authentification, le stockage de fichiers et des fonctions serverless avec Cloud Code. L'affirmation « le RAG est une boucle `for` » est ici littérale : les documents sont des objets ordinaires, avec le [stockage de fichiers](/glossary/fr/api/) pour les originaux ; les vecteurs des chunks vivent à côté d'eux dans des champs de type tableau, [indexés](/glossary/fr/index-de-base-de-donnees/) pour la [recherche par similarité](/glossary/fr/base-de-donnees-vectorielle/) ; les [ACL](/glossary/fr/listes-de-controle-d-acces-acl/) qui gouvernent déjà chaque requête deviennent *gratuitement* le filtre de permissions de la récupération — la même règle qui empêche un utilisateur de lire les enregistrements d'un autre empêche le retriever de les ramener ; et l'orchestration — encoder, récupérer, augmenter, générer — est une [fonction Cloud Code](/glossary/fr/cloud-code-fonctions-serverless/) qui appelle l'[API du modèle avec la clé gardée côté serveur](/glossary/fr/securite-des-cles-d-api/), exactement comme le montrent les onglets de code. Pas de framework, pas de service vectoriel séparé à sécuriser, pas de clé de LLM sur l'appareil — le RAG cesse d'être un projet d'IA pour devenir de l'ingénierie backend que vous savez déjà faire.