RAG pour mailbots : sources, citations, versioning et confiance

Le RAG : arrêter de débattre “hallucinations” et commencer à brancher la réalité

On a tous vu ce moment :

• le mailbot répond vite,
• le style est correct,
• et il invente… un détail qui change tout.

Le problème n’est pas “l’IA” au sens philosophique. Le problème est plus simple : le modèle n’a pas accès à votre vérité métier.

Et même quand il a été entraîné sur “Internet”, votre vérité n’est pas sur Internet :

• votre procédure de déclaration de sinistre,
• votre grille de garanties,
• votre politique de remboursement,
• votre SLA interne,
• votre base de tickets,
• votre catalogue produit,
• vos exceptions (“oui, ce cas est différent”).

Le RAG, dans un mailbot, consiste à transformer la question “que dois-je répondre ?” en une question plus utile :

“Quelle preuve interne dois-je aller chercher pour répondre ?”

La formulation “Retrieval‑Augmented Generation” a été popularisée dans la littérature (Lewis et al., 2020).¹

Et sur le terrain, ça se traduit par un design banal… donc efficace :

1. récupérer des extraits pertinents (retrieval),
2. écrire en s’appuyant dessus (generation),
3. garder une trace (citations + logs),
4. escalader quand la preuve n’existe pas.

Qu’est-ce qu’un RAG mailbot (et ce que ce n’est pas)

Ce que c’est

Un pipeline où le mailbot :

• extrait l’intention (N1),
• choisit les sources autorisées,
• récupère des passages pertinents,
• répond en citant,
• et versionne la décision (pour audit et replay).

Ce que ce n’est pas

Un “moteur de recherche + un prompt”.

Si votre RAG se contente de :

• chercher un PDF,
• coller 3 paragraphes dans le prompt,
• prier,

… vous aurez :

• des citations qui ne prouvent rien,
• des réponses qui dérivent,
• et une équipe support qui ne fait pas confiance (donc n’utilise pas).

La vraie question : quelles sources le mailbot a le droit d’utiliser ?

Le meilleur moyen de rater un RAG, c’est de commencer par l’embedding.

Commencez par le juridique et l’opérationnel :

• Quelles sources sont “source of truth” ?
• Quelles sources sont “supporting evidence” ?
• Quelles sources sont interdites ?

Une taxonomie simple (qui tient en prod)

Le point clé : tout n’a pas la même autorité.

Un assureur, par exemple, doit traiter les conditions contractuelles comme des textes sacrés (au sens “on cite la version”), alors qu’un playbook interne peut évoluer plus vite.

Retrieval : embeddings, hybride, reranking (et pourquoi “top‑k” est une illusion)

Le retrieval a trois niveaux :

1. candidats (beaucoup, vite),
2. tri (mieux),
3. preuve finale (peu, solide).

Recherche vectorielle : utile, pas magique

Les embeddings sont un outil excellent pour trouver des passages sémantiquement proches. Mais ils ont des limites :

• ils confondent les termes proches (“résiliation” vs “suspension”),
• ils ratent les détails chiffrés,
• ils sont sensibles au chunking,
• ils aiment les textes “génériques”.

Hybride : lexical + vectoriel

En mailbot, l’hybride est souvent le meilleur compromis :

• lexical (BM25 / keyword) pour les identifiants, références, acronymes,
• vectoriel pour l’intention, les paraphrases,
• puis reranking pour choisir les extraits les plus probants.

Reranking : la bonne pièce au bon moment

Le reranker (souvent un modèle plus “précis”) sert à répondre à une question simple :

“Parmi ces 30 candidats, lesquels prouvent vraiment quelque chose ?”

Open source vs commercial :

• open source : rerankers type BGE/Cross‑Encoder (selon vos contraintes GPU),
• commercial : reranking/embeddings gérés (plus simple, mais dépendant).

Chunking : le détail qui décide si votre RAG est fiable (ou juste bavard)

Chunker, c’est découper des documents en morceaux indexables.

Trois erreurs fréquentes :

1. chunks trop courts → contexte perdu, citations vides,
2. chunks trop longs → coûts, dilution, faux positifs,
3. chunks sans structure → vous cassez le sens (titres, tableaux, exceptions).

Pattern “doc-aware”

Pour des documents structurés (conditions générales, procédures), chunker “au hasard” est une mauvaise idée.

Vous voulez :

• découper par sections/titres,
• garder les numéros d’articles,
• conserver les tableaux (ou les transformer proprement),
• et stocker une metadata riche : doc_id, version, section, page, url interne.

Citations : la différence entre “ça sonne vrai” et “c’est prouvé”

Une citation utile doit permettre à un humain de :

• vérifier la source,
• comprendre le contexte,
• et auditer la version.

Trois niveaux de citation (très pragmatiques)

Ce qui est contre‑intuitif : le client n’a pas besoin de voir toute la plomberie.

En revanche, l’organisation doit pouvoir prouver comment la réponse a été produite.

Versioning : ce que personne ne fait en POC, et que tout le monde regrette en prod

Sans versioning, vous aurez ce bug :

• le mailbot répond “comme avant”,
• la policy a changé,
• et personne ne sait pourquoi.

Versioner quoi ?

• les documents (KB/policies),
• l’index (embeddings),
• les prompts/templates,
• les règles (policies),
• et les modèles (LLM, OCR, reranker).

Et pour chaque réponse, vous stockez une “carte d’identité” :

{
  "message_id": "…",
  "sources": [
    { "doc_id": "policy-claim", "version": "2026-01-15", "section": "3.2", "chunk_id": "…" }
  ],
  "retrieval": { "k": 30, "reranker": "bge-reranker", "final": 4 },
  "model": { "llm": "gpt-4o-mini", "provider": "OpenAI" },
  "decision": { "risk": "medium", "hitl": false }
}

Vous n’êtes pas obligé d’utiliser exactement ces champs. L’idée est simple : rejouer.

Aliases vs snapshots : le détail qui sauve votre audit

Dans les docs, vous verrez souvent deux formes de noms :

• un alias (“le modèle par défaut”, “latest”) : pratique, mais mouvant ;
• un snapshot daté : moins sexy, mais stable.

Pour un mailbot, c’est simple : les actions sensibles (N2/backoffice) méritent des snapshots.
Pourquoi ? Parce que le jour où un client dit “vous m’avez dit X”, vous voulez pouvoir répondre : “voici la version du modèle, de la KB, et du template qui a produit la phrase”.

Ça n’empêche pas d’utiliser des aliases en N1 (triage, accusés de réception). Mais dès que vous entrez dans le monde “contractuel”, la stabilité paie.

Modèles 2026 : oui, c’est important — mais ce n’est pas l’endroit où commencer

Un bon RAG peut rendre un modèle “moyen” très utile.

Un mauvais RAG peut rendre un modèle “excellent” dangereux.

Cela dit, côté modèles 2026, vous avez deux mondes :

• commerciaux (OpenAI, Anthropic, Google, Mistral) pour la vitesse d’exécution et la qualité perçue,²³⁴⁵
• open weights (Llama 4 et autres) pour souveraineté et contrôle (au prix de l’ops).⁶

Et dans un mailbot RAG, il faut aussi penser :

• embeddings / rerankers (open source ou gérés),
• OCR (cloud ou open source) si vos sources passent par des pièces jointes,
• et politiques de coûts/quota (sinon l’indexation devient une fuite).

Pièces jointes : RAG “éphémère” et vérité locale

Le RAG ne sert pas seulement sur une base “globale”.

Très souvent, l’information vit dans la pièce jointe du mail :

• facture,
• constat,
• photo,
• formulaire.

Le pattern utile : RAG éphémère.

1. OCR / extraction (selon le format),
2. index rapide “par conversation”,
3. réponse avec citations “document joint, page X”,
4. TTL court (privacy + coût).

Confiance : que faire quand la preuve manque ?

Un RAG sérieux doit savoir gérer quatre situations :

1. preuve claire,
2. preuves contradictoires,
3. aucune preuve,
4. preuve “hors scope” (le mail demande autre chose).

Évaluer un RAG mailbot : retrieval, génération, et “résolution”

On peut évaluer un RAG à trois niveaux :

• retrieval : est-ce qu’on récupère la bonne preuve ?
• génération : est-ce que la réponse suit la preuve ?
• produit : est-ce que ça résout plus vite (ou ça escalade mieux) ?

Retrieval : métriques utiles

• recall@k (la bonne source est-elle dans le top‑k ?),
• MRR / nDCG (le bon extrait est-il bien ranké ?),
• “citation correctness” (l’extrait cité prouve-t-il la phrase ?).

Génération : le piège du style

Un mailbot peut être :

• très bien écrit,
• parfaitement faux.

Donc l’évaluation doit mesurer :

• conformité aux sources,
• absence de claims non prouvés,
• et comportement “I don’t know / escalade”.

Cas d’usage : assurance (RAG qui réduit vraiment le temps de traitement)

En assurance, un RAG mailbot utile sait :

• citer la procédure exacte,
• lister les pièces manquantes,
• vérifier des statuts read-only,
• et escalader les cas sensibles.

Exemple : “je veux savoir si ce sinistre est couvert”.

Sans RAG : réponses génériques et dangereuses.

Avec RAG : “selon la garantie X (doc Y, section 3.2), voici les conditions, voici ce qu’il manque, voici le next step”.

Le RAG ne fait pas “plus intelligent”. Il fait “plus défendable”.

Conclusion : le RAG, c’est une discipline de preuve

Si vous voulez un mailbot qui inspire confiance :

• choisissez des sources de vérité,
• construisez un retrieval hybride + reranking,
• chunker avec structure,
• citer pour le conseiller et pour l’audit,
• versionner et rejouer,
• et escalader quand la preuve manque.

Le modèle 2026 est important. Mais la confiance se joue sur votre gouvernance.

Checklist “RAG ready”

• Sources classées (truth vs supporting vs interdites)
• Chunking doc-aware + metadata riche
• Retrieval hybride + reranking
• Citations 3 niveaux (client / conseiller / audit)
• Versioning (docs, index, prompts, modèles)
• RAG éphémère sur pièces jointes + TTL
• Évals retrieval + conformité + “I don’t know”

FAQ