RAG patterns

Une IA seule peut inventer. Le RAG lui donne d’abord vos vrais documents — procédures, contrats, FAQ — puis elle répond à partir de ça. On cite les sources, on vérifie la qualité : pas de magie.

On veut des réponses qui s’appuient sur vos textes, qu’on peut vérifier — pas un chatbot qui improvise. Les recettes existent ; on les applique sans sur-promettre.

RAG veut dire : avant que l’IA réponde, on lui met sous le nez les bons extraits de vos documents. Sans ça, elle répond avec ce qu’elle a appris une fois pour toutes — et elle peut inventer. Avec le RAG, elle cherche d’abord dans votre base (contrats, procédures, FAQ interne…), puis elle rédige une réponse ancrée dans ces passages — idéalement en disant d’où ça vient.

Exemple concret : un collaborateur demande « Quelle est notre politique de remboursement ? ». Sans RAG, l’IA généralise ou invente. Avec RAG, le système retrouve la page de la politique, puis répond à partir de ce texte. C’est ça le job : vos docs + une IA, sous contrôle.

« Patterns », ce n’est pas un logiciel magique à acheter. Ce sont les bonnes façons de le faire : découper les documents, retrouver le bon passage, obliger les citations, mesurer si les réponses tiennent la route. Dans le socle Innovation Digitale, c’est une méthode qu’on assume en production — qu’on documente, qu’on teste, et qu’on peut transmettre à une autre équipe. Pas une case à cocher sur une slide.

On veut des réponses sourcées et contrôlables. La doc des recettes existe ; on l’applique sans promettre que « l’IA sait tout ».

Le critère n°1, c’est la fiabilité opérationnelle. Un assistant documentaire qui invente des articles de règlement, c’est pire qu’un moteur de recherche. On journalise ce qui a été retrouvé, on peut auditer, on sait quoi corriger quand une réponse rate.

Le critère n°2, c’est la transmissibilité. Ce n’est pas un prompt secret dans la tête d’un prestataire : découpage, index, règles de citation et tests de qualité vivent dans le dépôt. Une autre équipe peut reprendre.

Le critère n°3, c’est la maîtrise des données. Vos documents restent chez vous (ou chez l’hébergeur que vous choisissez — Scaleway, OVHcloud…). On encapsule derrière des ports quand c’est utile, pour pouvoir changer de modèle d’IA sans réécrire le métier.

Sur un Brief ou un audit build, on part du problème métier — pas du buzzword. Le RAG entre en scène seulement si le besoin est clair : « nos équipes (ou nos clients) posent des questions sur un corpus qu’on possède, et on veut des réponses vérifiables ». Exemple typique : une app Symfony + React, une base PostgreSQL, et un corpus documentaire indexé à côté — pas une IA plaquée sur tout le SI.

Concrètement : on définit quelles sources sont autorisées, qui a le droit d’y accéder, comment on met à jour l’index quand un document change, et ce qu’on fait quand on ne trouve rien de pertinent (mieux vaut « je ne sais pas » qu’une invention). Le domaine métier reste au centre ; l’IA est un adaptateur, pas le cœur du système.

La qualité n’est pas un chapitre à part. Dès qu’un parcours RAG touche le code, on le branche dans la CI : jeux de questions/réponses attendues, contrôles sur les citations. Vert = on peut livrer. Rouge = on arrête avant la casse.

Pour les startups comme pour les PME/ETI, le même standard s’applique. On ne « fait pas du RAG pour faire du RAG ». On l’utilise pour retirer un contournement coûteux — chercher à la main dans dix dossiers, relancer le juridique pour la même question — sans remplacer le jugement humain là où le risque l’exige.

Le RAG est un bon choix quand vous avez un corpus réel (docs internes, base produit, procédures) et que les gens perdent du temps à chercher — ou à se tromper. FAQ assistée, aide au support, lecture guidée de dossiers : c’est son terrain.

On passe son tour quand il n’y a pas assez de documents fiables, quand le besoin est une action métier (valider une facture, déclencher un workflow) plutôt qu’une question sur un texte, ou quand une règle explicite dans le code suffit. L’honnêteté du discours fait partie de la méthode.

On évite aussi les empilements « parce que c’est moderne ». Ajouter du RAG doit résoudre un goulot : temps perdu, erreurs, charge support. Si le seul argument est le buzzword, ce n’est pas un argument.

Le RAG n’est pas un produit jetable d’un éditeur : c’est une approche largement documentée (guides, retours d’expérience, patterns ouverts). On s’appuie là-dessus pour ne pas réinventer la roue à chaque mission.

Ce qui compte pour un dirigeant : pouvoir expliquer le système, le faire auditer, le faire reprendre. Pas une boîte noire « on a branché ChatGPT sur le Drive ».

Côté souveraineté made in France / Europe : selon le projet, on privilégie des modèles et un hébergement UE (Mistral, Scaleway, OVHcloud) quand la data ou la politique l’exige. Le site vitrine iD peut tourner sur Netlify ; vos apps métier, elles, choisissent l’hébergeur adapté.

En résumé : RAG patterns dans le socle iD, c’est la garantie qu’une IA qui parle de vos documents le fait avec méthode — sources, contrôles, code à vous. Pas une démo qui impressionne une semaine.

Si vous hésitez entre « chatbot générique » et « assistant sur notre corpus », le Brief 45 min sert exactement à ça : clarifier le problème, le risque, le périmètre, puis proposer un audit build si le sujet tient la route.

Pour aller plus loin : les liens ci-dessous, les autres fiches du socle (OpenAI, Anthropic, Mistral…), et les réalisations — notamment là où l’automatisation documentaire a un vrai livrable métier.