RAG pour le support client : répondre aux tickets avec des sources, pas des suppositions
Le RAG (génération augmentée par récupération) permet à une équipe support de répondre aux tickets en s'appuyant sur ses articles d'aide, ses CGV et ses politiques internes, avec des passages sourcés à l'appui de chaque réponse. Concrètement, cela se traduit par trois usages : la déflexion en libre-service, l'assistance aux agents pendant la rédaction d'une réponse, et la génération de brouillons pour les cas récurrents. Encore faut-il construire une base de connaissances propre et la garder à jour, sans quoi le système répond vite… mais à côté.
Pourquoi le RAG change la donne par rapport à un chatbot classique
Un chatbot de support « classique » repose souvent sur des scénarios prédéfinis ou une recherche par mots-clés dans une base de FAQ. Dès que la formulation du client s'écarte du script, il tombe à plat. Le RAG fonctionne différemment : à chaque question, le système recherche d'abord les passages les plus pertinents dans vos documents (articles d'aide, politique de remboursement, conditions de garantie, procédures internes), puis les transmet à un modèle de langage chargé de rédiger une réponse appuyée sur ces extraits, avec citation des sources. Résultat : une réponse qui colle à la formulation réelle du client, tout en restant vérifiable. C'est aussi un levier direct pour réduire les hallucinations de l'IA, un point sensible dès qu'on touche à des engagements contractuels (délais de rétractation, garanties, tarifs).
Trois usages concrets dans une équipe support
La déflexion en libre-service
Avant même l'ouverture d'un ticket, un widget alimenté par RAG peut répondre directement sur le site ou dans l'application : statut de commande, procédure de retour, compatibilité d'un produit. L'objectif n'est pas de remplacer un agent sur les cas complexes, mais d'absorber les questions répétitives qui représentent souvent 30 à 50 % du volume entrant, sans faire attendre le client dans une file.
L'assistant agent (agent assist)
Même quand un humain traite le ticket, le RAG reste utile : pendant que l'agent lit le message, le système propose en marge les passages pertinents de la base de connaissances (procédure de remboursement applicable à ce pays, exception contractuelle, script validé par le service juridique). L'agent garde la main sur la réponse finale, mais gagne le temps de recherche dans la documentation interne, souvent éclatée entre plusieurs outils.
Les brouillons de réponse
Sur les tickets à forte récurrence (annulation, facture manquante, délai de livraison dépassé), le système peut générer un brouillon complet que l'agent relit, ajuste et envoie. C'est un gain de temps mesurable, à condition que la base source soit fiable : un brouillon qui cite la mauvaise politique de remboursement coûte plus cher qu'il n'en fait gagner.
Construire la base de connaissances : quels documents, quel découpage
La qualité des réponses dépend directement de ce qu'on met dans la base et de la façon dont on le découpe. Trois catégories de documents sont généralement prioritaires :
- Les articles d'aide existants (centre d'aide, base Zendesk ou Freshdesk exportée en PDF ou Markdown)
- Les politiques internes : conditions générales de vente, politique de remboursement, garanties, délais de rétractation
- Les procédures internes aux agents : scripts validés, exceptions commerciales, escalades à faire vers tel service
Le découpage (chunking) de ces documents a un impact direct sur la pertinence des réponses : un article d'aide trop long découpé n'importe où peut séparer une condition de son exception, et produire une réponse incomplète. Les stratégies de chunking pour le RAG détaillent comment choisir une taille de bloc adaptée et un découpage par structure (titres, sections) plutôt qu'un découpage mécanique au nombre de caractères. Pour la recherche elle-même, combiner mots-clés et vecteurs donne de meilleurs résultats qu'une seule méthode : c'est l'objet de la recherche hybride, particulièrement utile sur du vocabulaire métier ou des références de produits que la recherche purement sémantique a parfois du mal à retrouver exactement.
Commencer petit
Plutôt que d'importer tout le centre d'aide d'un coup, commencez par les 20 à 30 articles qui couvrent 80 % des tickets. Vous validerez plus vite la qualité des réponses, et il sera plus facile de corriger un petit corpus qu'un gros.
Garder le contenu frais : le vrai sujet sur la durée
Une base de connaissances support vieillit vite : une politique de remboursement change, un produit est retiré, un délai de livraison évolue après un changement de transporteur. Un système RAG qui cite une politique périmée est pire qu'un agent qui ne sait pas répondre, parce qu'il le fait avec assurance. Quelques pratiques limitent ce risque :
- Désigner un propriétaire par catégorie de documents (politiques, produits, procédures) chargé de signaler les changements
- Remplacer le document entier plutôt que de corriger un fragment, pour que tout le découpage et l'indexation soient refaits proprement
- Prévoir une revue trimestrielle même sans changement connu, pour repérer les écarts entre ce qui est documenté et ce que les agents appliquent réellement sur le terrain
- Dater visiblement les documents sources, pour que les passages cités affichent une fraîcheur vérifiable
Sur Kopik, remplacer un document revient à le réimporter : la base ré-extrait, redécoupe et réindexe automatiquement le contenu mis à jour, sans script ni ré-ingestion manuelle à gérer côté infrastructure.
Mesurer l'impact : les indicateurs à suivre
Indicateurs pour piloter un déploiement RAG support
| Indicateur | Ce qu'il mesure | Repère utile |
|---|---|---|
| Taux de déflexion | Part des questions résolues sans ouverture de ticket ou sans intervention humaine | À suivre sur les catégories à fort volume, pas en moyenne globale |
| Taux de correction des brouillons | Part des brouillons modifiés avant envoi par l'agent | Un taux élevé et stable signale une base à corriger, pas l'IA |
| Temps de première réponse | Délai entre l'arrivée du ticket et la première réponse envoyée | Baisse attendue dès l'activation de l'agent assist |
| Taux de citation correcte | Part des réponses dont la source citée est effectivement pertinente | À vérifier manuellement sur un échantillon chaque mois |
| CSAT post-réponse IA | Satisfaction client spécifique aux réponses générées | À isoler du CSAT global pour ne pas noyer le signal |
Le taux de correction des brouillons mérite une attention particulière : s'il reste élevé après plusieurs semaines, le problème vient rarement du modèle, mais d'une base de connaissances incomplète ou contradictoire sur certains sujets. La méthode pour vérifier une réponse d'IA avec ses sources s'applique directement à ce contrôle qualité continu.
Intégration technique : widget, API ou agent interne
Trois façons de brancher une base de connaissances sur les outils du support coexistent généralement :
- Un widget ou une recherche sur le site public, pour la déflexion en libre-service
- Une intégration par API REST dans l'outil de ticketing existant (Zendesk, Freshdesk, Intercom), pour afficher les passages suggérés dans l'interface de l'agent
- Un accès via serveur MCP, pour que les agents support utilisent directement un assistant comme Claude ou ChatGPT connecté à la base de connaissances, sans quitter leur environnement de travail
Kopik propose ces trois modes d'accès sur une même base : interrogation directe sur le site, API avec clés pour l'intégrer dans un outil de ticketing, ou connexion via MCP pour les agents qui travaillent depuis Claude, Cursor ou ChatGPT. Le détail de cette dernière option, notamment pour un usage support interne, est expliqué dans connecter Claude, Cursor ou ChatGPT à une base de connaissances.
Risques et bonnes pratiques à ne pas sauter
Trois points méritent une vigilance particulière avant de mettre un dispositif RAG face à des clients réels. D'abord, le mode de réponse : privilégier des réponses avec citation des passages sources plutôt que des réponses « en passages seuls » pour les sujets contractuels, afin que l'agent (ou le client) puisse vérifier d'un coup d'œil d'où vient l'engagement annoncé. Ensuite, le périmètre des données personnelles : si la base de connaissances contient des extraits de tickets passés pour entraîner les réponses, un cadrage RGPD s'impose, avec minimisation des données et durée de conservation définie. La checklist pour créer un chatbot conforme au RGPD couvre ce point en détail. Enfin, la séparation claire entre une base publique de documentation produit et une base privée contenant des procédures internes sensibles : sur une plateforme comme Kopik, cette distinction se fait au moment de la création de la base, et une base privée reste accessible uniquement à son propriétaire et à ses clés API.
Public ou privé ?
Une base d'articles d'aide déjà publics peut être partagée en mode public, et même générer un revenu si des partenaires ou intégrateurs l'interrogent via API. Les politiques internes et scripts d'escalade, eux, doivent rester en base privée.
Testez le RAG sur vos propres documents de support
Importez vos articles d'aide et vos politiques internes, laissez l'indexation hybride se faire automatiquement, et interrogez votre base via le site, l'API ou MCP dès aujourd'hui.
Par où commencer concrètement
Le plus efficace est de partir d'une catégorie de tickets bien identifiée (retours produit, facturation, ou délais de livraison), d'y associer les quelques documents sources qui font autorité, et de mesurer le taux de correction des brouillons pendant deux à trois semaines avant d'étendre à d'autres catégories. Vous pouvez explorer des bases déjà existantes dans le catalogue Kopik pour voir comment d'autres organisations structurent et documentent leurs connaissances avant de vous lancer.
Questions fréquentes
Le RAG peut-il remplacer complètement les agents du support client ?
Non, pas sur l'ensemble des tickets. Le RAG est efficace pour la déflexion sur les questions répétitives et pour accélérer la rédaction des réponses par les agents, mais les cas ambigus, les exceptions commerciales et les situations sensibles nécessitent toujours une validation humaine.
Quelle différence entre un chatbot support classique et un système RAG ?
Un chatbot classique répond via des scénarios prédéfinis ou une recherche par mots-clés exacts. Un système RAG recherche les passages pertinents dans les documents puis génère une réponse rédigée et sourcée, ce qui le rend plus robuste aux reformulations et plus vérifiable.
Comment éviter qu'une réponse cite une politique périmée ?
En remplaçant le document entier dès qu'une politique change, plutôt qu'en le corrigeant partiellement, et en instaurant une revue périodique même en l'absence de changement signalé. Dater visiblement les documents sources aide aussi à repérer les contenus trop anciens.
Faut-il une base publique ou privée pour le support client ?
Les articles d'aide déjà publics peuvent être mis dans une base publique, voire monétisés via l'API si des partenaires l'interrogent. Les procédures internes, scripts d'escalade et documents contenant des données clients doivent rester en base privée, accessible uniquement via vos propres clés.
Comment mesurer si le dispositif fonctionne vraiment ?
Suivez le taux de déflexion par catégorie de tickets, le taux de correction des brouillons avant envoi, et un contrôle manuel mensuel de la pertinence des sources citées. Un taux de correction élevé signale généralement un problème dans la base de connaissances plutôt que dans le modèle.
Le RAG fonctionne-t-il avec les outils de ticketing existants comme Zendesk ou Freshdesk ?
Oui, via une intégration par API REST qui interroge la base de connaissances et affiche les passages ou brouillons suggérés directement dans l'interface de l'agent, sans changer d'outil de ticketing.
Recevez la newsletter Kopik
Nouvelles bases de connaissances, guides sur le RAG et nouveautés du produit. Un mail toutes les une à deux semaines, désinscription en un clic.
En vous abonnant, vous acceptez de recevoir notre newsletter. Votre adresse n'est jamais partagée.