Qu’est-ce que le RAG, et quand une entreprise a besoin d’un assistant IA

Interrogez un chatbot généraliste sur les procédures de votre entreprise, et l’une de deux choses se produit. Soit il répond qu’il ne sait pas, soit — pire — il produit une réponse assurée qui semble juste et ne l’est pas. Il n’a jamais vu vos documents, alors il comble le vide avec quelque chose de plausible.

Pour une entreprise, toute la difficulté est là. Le savoir qui compte pour vos clients et votre équipe se trouve dans les contrats, les règlements, les grilles tarifaires, les manuels, les décisions et les anciens e-mails. Un modèle entraîné sur l’internet public n’en possède rien, et réentraîner un modèle sur vos fichiers est rarement la bonne réponse.

La génération augmentée par récupération (retrieval-augmented generation) ajoute une étape avant la réponse : d’abord trouver dans vos documents les passages pertinents pour la question, puis les donner au modèle en lui demandant de répondre à partir d’eux.

Une analogie aide. Un chatbot généraliste est une personne cultivée qui répond de mémoire. Un assistant RAG est la même personne avec vos archives sur le bureau, qui vérifie avant de parler — et peut vous dire de quelle page vient la réponse.

L’essentiel du travail se fait avant que quiconque pose une question. Les documents arrivent sous forme de PDF, de scans, de tableurs et de pages web, et ils doivent d’abord devenir un texte propre et lisible. Les pages scannées demandent une reconnaissance de texte ; les tableaux et les titres doivent garder leur sens ; les doublons et les versions obsolètes doivent être supprimés ou signalés.

Le texte est ensuite découpé en passages — un paragraphe, une clause, une courte section. C’est ce qu’on appelle le chunking. Des passages trop longs apportent du bruit dans la réponse ; des passages trop courts perdent leur contexte. Chaque passage garde la trace de son origine : le document, la page, la date.

Chaque passage est ensuite transformé en embedding : une liste de nombres qui représente son sens. Deux passages qui parlent de la même chose avec des mots différents se retrouvent proches l’un de l’autre. C’est ce qui permet de chercher par le sens plutôt que par les mots exacts, et le tout est stocké dans une base de données vectorielle comme pgvector, celle qui fait fonctionner Urbano.

Quand quelqu’un pose une question, celle-ci est elle aussi transformée en embedding, et le système cherche les passages les plus proches. Une bonne recherche s’arrête rarement là : elle peut combiner le sens avec une recherche classique par mots-clés, filtrer par type de document ou par date, et reclasser les résultats avant que quoi que ce soit n’atteigne le modèle.

C’est dans la recherche qu’un système RAG réussit ou échoue. Si le bon passage n’est pas trouvé, le meilleur modèle du monde répondra à partir du mauvais matériau. Dans un assistant sérieux, l’essentiel de l’effort va ici, pas dans la fenêtre de conversation.

Le modèle reçoit la question avec les passages retrouvés et l’instruction de ne répondre qu’à partir d’eux. Un assistant digne de confiance montre ensuite ses sources : quel document, quelle section. La personne qui lit la réponse peut ouvrir l’original et juger par elle-même.

Tout aussi important, l’assistant doit avoir le droit de dire qu’il ne sait pas. Quand les documents ne contiennent pas la réponse, un « je n’ai pas trouvé cela » clair — et un chemin vers une personne — vaut plus qu’une supposition bien tournée.

Urbano est une plateforme citoyenne en ligne pour Banja Luka. Son assistant travaille sur 22 300 documents de la ville et fait partie du même produit que l’application citoyenne, la console d’administration et 143 formulaires administratifs. Le citoyen pose sa question en langage courant ; la réponse est construite à partir des sources de la ville, et la démarche peut se poursuivre dans le service concerné.

Pour le Centre d’innovation de Banja Luka, je construis un assistant pour entrepreneurs, encore en développement. Ici, il s’agit moins de retrouver un fait isolé que de guider une conversation : expliquer les programmes de soutien, accompagner l’immatriculation d’une entreprise et structurer un premier business plan. La recherche reste importante, car les programmes ont des règles que les réponses doivent respecter.

La même idée fonctionne pour les images. Curation Engine, un produit privé que j’ai conçu et développé, lit une archive photographique à travers des embeddings visuels et textuels. Un photographe peut chercher une ambiance ou un sujet avec des mots, trouver des images qui se ressemblent et voir des groupes d’images liées, et les photographies retrouvées deviennent la matière d’une sélection.

La leçon vaut aussi pour les documents d’entreprise : ce qui compte, ce n’est pas la fenêtre de discussion, mais le fait que le système trouve le bon matériau, le montre clairement et laisse la décision à la personne.

Un assistant fait partie d’une interface, il ne la remplace pas. Des questions suggérées montrent aux gens ce qu’ils peuvent demander. Les sources s’ouvrent sur place, si bien que vérifier une réponse ne prend qu’un clic. Quand la réponse mène à une action — un formulaire, un rendez-vous, un signalement — l’étape suivante doit être juste là, comme dans Urbano, où l’information et les 143 formulaires administratifs vivent dans le même produit.

Les solutions de repli font aussi partie de la conception : un message clair quand rien de pertinent n’a été trouvé, une possibilité de reformuler et un moyen de joindre une personne. Ce sont ces détails qui décident si les gens font confiance à l’assistant après la première semaine.

Un assistant doit être testé comme n’importe quelle autre partie d’un produit. Avant le lancement, je rassemble de vraies questions — celles que l’équipe reçoit réellement — avec les réponses et les sources qu’elles devraient produire, et je vérifie la recherche et les réponses par rapport à elles. Quand les documents ou les réglages changent, le même ensemble est relancé.

Après le lancement, les questions que les gens posent vraiment sont le meilleur professeur. Les questions sans réponse révèlent des documents manquants ; les mauvaises réponses signalent généralement un problème de recherche ; les questions répétées montrent ce qui devrait être mieux expliqué sur le site lui-même.

Les documents d’entreprise sont souvent confidentiels. Avant de construire quoi que ce soit, il vaut la peine de décider quels documents l’assistant peut utiliser, qui peut lui demander quoi, et où tournent les données et le modèle. Un assistant interne pour l’équipe et un assistant public pour les clients demandent généralement des ensembles de documents et des droits d’accès différents.

Les données personnelles méritent une attention particulière : ce qui entre dans l’index, combien de temps les conversations sont conservées et qui peut les lire sont des décisions à prendre au départ, pas après le lancement.

L’effort dépend surtout des documents : combien il y en a, à quel point ils sont désordonnés, à quelle fréquence ils changent et s’ils nécessitent une reconnaissance de texte. Il dépend aussi de l’usage de l’assistant — par quelques membres de l’équipe ou par le public — et de ce à quoi il doit se connecter, comme des formulaires, des comptes ou un agenda.

Parfois, la réponse honnête est de ne pas en construire. S’il existe une vingtaine de questions aux réponses stables, une page de réponses bien rédigée est plus rapide, moins chère et plus facile à garder exacte. Un assistant RAG trouve sa place quand les documents sont nombreux, que les mêmes questions reviennent sans cesse et que chercher la réponse à la main prend un temps réel.

Si cela ressemble à votre situation, envoyez-moi le type de documents dont vous disposez, qui poserait les questions et ce que ces personnes devraient pouvoir faire ensuite.