Votre entreprise possède des centaines de documents : procédures internes, fiches produit, contrats types, historique de tickets support. Toute la connaissance est là, mais personne ne la trouve. Résultat : vos équipes posent dix fois les mêmes questions aux mêmes experts, et vos clients attendent des heures une réponse qui figure noir sur blanc dans votre FAQ.
C'est exactement le problème que résout le RAG (Retrieval-Augmented Generation, ou « génération augmentée par la recherche ») : un chatbot qui ne répond pas depuis sa culture générale, mais depuis vos documents, en citant ses sources. C'est aujourd'hui le projet IA que je livre le plus souvent pour des PME, et c'est aussi celui où l'écart entre une démo bluffante et un outil fiable en production est le plus grand.
En une phrase : le RAG consiste à chercher les passages pertinents dans vos documents avant de faire répondre l'IA, qui rédige alors sa réponse uniquement à partir de ces extraits, sources à l'appui. Comptez 8 000 à 25 000 € pour un assistant documentaire sérieux, et quelques dizaines d'euros par mois de coûts d'API pour un usage PME.
Pourquoi ne pas simplement « donner les documents à ChatGPT » ?
Trois raisons. D'abord la volumétrie : même si les modèles récents acceptent de très longs contextes, envoyer 500 documents à chaque question serait lent, coûteux, et dégraderait la qualité des réponses. Ensuite la fraîcheur : vos procédures changent ; le RAG interroge toujours la dernière version, sans réentraîner quoi que ce soit. Enfin la traçabilité : en production, une réponse sans source citée est invérifiable, donc inutilisable pour un usage professionnel.
C'est aussi ce qui distingue le RAG du fine-tuning, qui modifie le modèle lui-même. J'ai comparé les deux approches en détail dans RAG vs fine-tuning ; retenez que pour « répondre depuis mes documents », le RAG gagne dans plus de 90 % des cas.
Le pipeline RAG, étape par étape
Un système RAG se construit comme une chaîne de cinq maillons. La qualité finale est celle du maillon le plus faible , et ce n'est presque jamais le modèle d'IA.
1. L'ingestion : collecter et convertir vos documents
PDF, Word, pages Notion, tickets Zendesk, emails : tout doit être converti en texte propre. C'est l'étape la plus sous-estimée. Un PDF scanné, un tableau complexe ou un document en trois colonnes peuvent produire du texte illisible qui polluera toutes les réponses. Sur mes projets, 30 à 40 % du temps part dans cette plomberie documentaire.
2. Le chunking : découper en morceaux intelligents
On découpe chaque document en « chunks » (morceaux) de quelques centaines de mots. Trop petits, ils perdent leur contexte ; trop grands, ils noient l'information. Le bon découpage suit la structure du document (titres, sections) plutôt qu'un nombre de caractères arbitraire, et chaque morceau garde ses métadonnées : source, date, service concerné.
3. Les embeddings : transformer le texte en coordonnées
Chaque chunk est converti en embedding, une série de nombres qui capture son sens. Deux textes qui parlent de la même chose ont des coordonnées proches, même s'ils n'emploient pas les mêmes mots , c'est ce qui permet de retrouver « délai de rétractation » quand l'utilisateur demande « puis-je annuler ma commande ? ». J'explique le fonctionnement en détail dans mon guide des embeddings. Ces vecteurs sont stockés dans une base dédiée , le choix de l'outil est traité dans quelle base vectorielle choisir.
4. Le retrieval : retrouver les bons passages
Quand un utilisateur pose une question, le système cherche les chunks les plus proches sémantiquement. Les systèmes sérieux combinent cette recherche par sens avec une recherche par mots-clés classique (approche dite « hybride »), puis reclassent les résultats. C'est ici que se joue 80 % de la qualité : si les bons passages ne remontent pas, le meilleur modèle du monde répondra à côté.
5. La génération : rédiger la réponse, avec les sources
Les passages retrouvés sont fournis au modèle avec une consigne stricte : répondre uniquement à partir de ces extraits, citer les documents utilisés, et dire « je ne sais pas » si l'information n'y figure pas. Ce dernier point est contre-intuitif mais essentiel : un assistant qui admet ses limites inspire confiance, un assistant qui invente détruit le projet.
Les cas d'usage qui fonctionnent vraiment
| Cas d'usage | Exemple concret | Gain typique |
|---|---|---|
| Support client niveau 1 | Réponses depuis la FAQ, les guides et l'historique de tickets | 40 à 60 % des tickets résolus sans humain |
| Intranet / RH | « Combien de jours de congés puis-je reporter ? » | Moins de sollicitations des fonctions support |
| Documentation technique | Assistant intégré à la doc produit pour vos utilisateurs | Onboarding plus rapide, moins de tickets |
| Juridique / conformité | Recherche dans les contrats et procédures, avec citation exacte | Des heures de recherche économisées par dossier |
Pour le support client spécifiquement, le RAG n'est qu'une brique d'un dispositif plus large (escalade vers l'humain, ton, mesure de la satisfaction) : j'ai détaillé tout ça dans automatiser votre support client avec un agent IA.
Combien ça coûte ?
Deux budgets à distinguer. Le développement : de 8 000 à 15 000 € pour un assistant interne sur un corpus propre et homogène, de 15 000 à 25 000 € et plus quand il faut gérer des sources multiples, des droits d'accès par service ou une intégration dans un produit existant. Les coûts récurrents ensuite : pour un usage PME (quelques milliers de questions par mois), les appels aux modèles et la base vectorielle représentent en général 20 à 150 € par mois. C'est un poste modeste, mais qui croît avec l'usage : budgétez-le dès le départ.
Et la confidentialité de vos documents ?
C'est la première question de mes clients, et elle est légitime : un RAG envoie des extraits de vos documents internes à un fournisseur de modèles. Trois niveaux de réponse existent. Le plus simple : utiliser les offres professionnelles des grands fournisseurs, qui s'engagent contractuellement à ne pas entraîner leurs modèles sur vos données, idéalement avec un hébergement européen. Le niveau intermédiaire : passer par un cloud souverain ou une instance dédiée. Le niveau maximal : héberger un modèle open-weights sur votre propre infrastructure , pertinent pour des données très sensibles (santé, défense, juridique), mais avec un coût et une complexité sans commune mesure pour une PME.
Dans tous les cas, le sujet se traite dès le cadrage : cartographie des documents sensibles, anonymisation éventuelle à l'ingestion, registre RGPD si des données personnelles transitent, et information des utilisateurs. Un chatbot interne est un traitement de données comme un autre : pas plus effrayant qu'un CRM, mais pas moins encadré.
Combien de temps pour un premier résultat ?
Mon déroulé type pour un pilote RAG en PME tient en quatre semaines. Semaine 1 : cadrage, choix du périmètre documentaire, constitution du jeu de questions de test avec les équipes. Semaines 2 et 3 : ingestion, pipeline, première version interrogeable, itérations sur le chunking et le retrieval en mesurant le taux de bonnes réponses sur le jeu de test. Semaine 4 : interface (souvent un simple widget interne ou une intégration Slack), garde-fous, mise en main auprès d'un groupe restreint d'utilisateurs. À la fin, vous avez des chiffres : taux de réponses correctes, taux de « je ne sais pas » justifiés, retours utilisateurs. La décision d'industrialiser se prend sur ces données, pas sur une impression de démo.
Les pièges qui font échouer les projets RAG
- Un corpus pourri. Documents obsolètes, versions contradictoires, procédures jamais mises à jour : le chatbot exposera vos incohérences au grand jour. Prévoyez un nettoyage documentaire avant, pas après.
- Ignorer les droits d'accès. Si les grilles de salaires sont dans le corpus, le chatbot les récitera à qui les demande. Le filtrage par profil utilisateur doit être conçu dès le premier jour.
- Ne pas mesurer la qualité. Constituez un jeu de 50 à 100 questions réelles avec les réponses attendues, et rejouez-le à chaque modification. Sans ça, vous pilotez à l'aveugle.
- Lancer sans boucle de feedback. Un simple pouce haut/bas sur chaque réponse vous dit où le système échoue et quels documents manquent.
- Viser trop large. Commencez par un périmètre (le support produit, ou les RH), prouvez la valeur, puis étendez.
Dans un projet RAG, l'IA est la partie facile. Ce qui fait la différence entre un gadget et un outil de travail, c'est la qualité de vos documents et l'honnêteté du système quand il ne sait pas.
Et si on branchait l'IA sur vos documents ?
Le meilleur point de départ : un pilote sur un corpus limité, avec un jeu de questions de test et des critères de succès chiffrés, en 3 à 4 semaines. Si les résultats sont là, on industrialise ; sinon, vous avez dépensé le minimum pour le savoir. Réservez un appel découverte pour évaluer votre corpus et cadrer un pilote.
À lire ensuite : intégrer l'IA dans votre SaaS pour la vision d'ensemble côté produit.
