Une IA généraliste peut expliquer un concept public, mais elle ne connaît pas forcément la documentation interne d'une entreprise, les conventions d'un projet ou les décisions d'architecture passées. C'est là que le RAG devient intéressant.
RAG signifie Retrieval-Augmented Generation. L'idée est simple : avant de générer une réponse, le système recherche les documents pertinents, puis les fournit comme contexte au modèle.
Pourquoi le RAG intéresse les équipes dev
Les équipes techniques accumulent beaucoup de connaissances :
- README ;
- ADR ;
- documentation API ;
- tickets ;
- specs produit ;
- runbooks ;
- incidents passés ;
- guides d'installation ;
- conventions de code.
Le problème n'est pas seulement de stocker cette connaissance. C'est de la retrouver au bon moment.
Un assistant RAG peut aider un développeur à répondre à des questions comme :
- comment déployer ce service ?
- quelle convention utiliser pour les migrations ?
- pourquoi ce choix d'architecture a été fait ?
- où se trouve l'API de facturation ?
- quels incidents ont déjà touché ce module ?
Architecture simplifiée
Un système RAG contient généralement cinq briques.
La première brique est la source documentaire : fichiers Markdown, wiki, base Notion, Git, documentation HTML, tickets.
La deuxième est l'indexation : découper les documents en passages exploitables.
La troisième est la recherche : retrouver les passages les plus pertinents selon la question.
La quatrième est le modèle IA : générer une réponse à partir des passages retrouvés.
La cinquième est la citation : indiquer d'où viennent les informations.
Sans citation, le RAG perd une grande partie de sa valeur.
Le piège de la documentation sale
Un RAG ne rend pas une mauvaise documentation fiable. Si les sources sont obsolètes, contradictoires ou incomplètes, l'IA peut répondre avec assurance à partir d'un mauvais contexte.
Avant de construire un assistant, il faut nettoyer :
- documents dupliqués ;
- pages obsolètes ;
- noms incohérents ;
- guides jamais mis à jour ;
- décisions non datées ;
- exemples de code cassés.
La qualité du RAG dépend directement de la qualité documentaire.
Bonnes pratiques d'indexation
Le découpage des documents est important. Si les morceaux sont trop petits, le contexte manque. S'ils sont trop gros, la recherche devient imprécise.
Pour une documentation technique, il est utile de conserver :
- le titre de la page ;
- la section ;
- la date de mise à jour ;
- le dépôt ou produit concerné ;
- le niveau de fiabilité ;
- l'URL source.
Ces métadonnées aident l'IA à répondre avec plus de prudence.
Répondre "je ne sais pas"
Un bon assistant RAG doit pouvoir refuser de répondre quand les sources ne suffisent pas. C'est essentiel.
Prompt système typique :
Réponds uniquement à partir des sources fournies.
Si les sources ne contiennent pas la réponse, dis que l'information n'est pas disponible.
Cite les documents utilisés.
Cette contrainte réduit les hallucinations.
RAG et MCP : complémentarité
MCP et RAG ne sont pas la même chose, mais ils peuvent se compléter. MCP peut exposer un outil de recherche documentaire à un agent IA. Le RAG peut être le moteur derrière cet outil.
Exemple : un agent de code utilise MCP pour appeler une recherche dans la documentation interne. Cette recherche repose sur un index RAG. L'agent reçoit ensuite les passages pertinents et peut mieux modifier le projet.
Cas d'usage concrets
Un RAG documentaire peut servir à :
- onboarding développeur ;
- support interne ;
- analyse d'incident ;
- aide à la migration ;
- génération de documentation ;
- recherche de décisions d'architecture ;
- assistance aux équipes produit ;
- support client technique.
Le meilleur premier cas d'usage est souvent l'onboarding. Les nouveaux arrivants posent beaucoup de questions répétitives, et les réponses doivent être sourcées.
Mesurer la qualité
Un RAG doit être évalué. Quelques questions utiles :
- les sources citées sont-elles pertinentes ?
- la réponse est-elle complète ?
- l'assistant refuse-t-il quand il ne sait pas ?
- les documents obsolètes remontent-ils trop souvent ?
- les utilisateurs gagnent-ils du temps ?
Il faut tester avec de vraies questions, pas seulement des exemples faciles.
Conclusion
Le RAG peut rendre une IA beaucoup plus utile pour les développeurs, parce qu'il connecte le modèle à la connaissance réelle de l'organisation. Mais la technique ne suffit pas : il faut des sources propres, des citations, des refus quand l'information manque et une évaluation régulière.
Un bon RAG n'est pas une machine à répondre à tout. C'est un assistant qui sait retrouver, citer et expliquer la connaissance technique disponible.
FAQ
Le RAG remplace-t-il la documentation ?
Non. Il rend la documentation plus accessible, mais il dépend de sa qualité.
Faut-il une base vectorielle pour faire du RAG ?
Souvent oui, mais ce n'est pas le seul élément important. Le découpage, les métadonnées et l'évaluation comptent autant.
Comment éviter les hallucinations ?
Demande au modèle de répondre uniquement avec les sources fournies et d'indiquer quand l'information manque.
Sources et lectures utiles
- MCP docs : Documentation MCP : introduction au protocole
- OpenAI code generation : Documentation OpenAI : génération de code
- Google contenu utile : Google Search Central : créer du contenu utile et fiable
