Qu’est-ce que le RAG pour les documents d’entreprise, et quelles sont ses limites ?

Le RAG peut retrouver des passages dans les documents d’une entreprise et préparer des réponses reliées à leurs sources, mais il n’entraîne pas le modèle, ne garantit pas la vérité et ne remplace pas le contrôle des accès.

Un lundi matin, la responsable des ressources humaines demande à l’assistant interne combien de temps les données des candidats doivent être conservées et reçoit une réponse assurée, accompagnée d’un lien vers la politique de l’entreprise ; seul problème : la version retrouvée est caduque depuis huit mois. Qu’est-ce que le RAG a fait dans ce cas ? Sur le plan technique, le système a peut-être exécuté tout ce qu’on lui demandait : trouver un passage sémantiquement proche, l’insérer dans le contexte du modèle et rédiger une réponse fluide ; il n’a toutefois pas vérifié que le fichier était bien la dernière version approuvée si le statut de la version n’était pas indiqué de manière fiable dans l’index.

Le sigle RAG désigne la retrieval-augmented generation, ou génération augmentée par récupération : au moment de répondre, la génération reçoit un contexte externe qui a été retrouvé. Il ne s’agit ni d’intégrer les documents de l’entreprise aux poids du modèle par un entraînement, ni d’ajouter une « couche d’intelligence » qui saurait automatiquement quel document dit vrai ; imaginez plutôt une bibliothèque dotée d’un bibliothécaire très rapide et d’un rédacteur talentueux : le bibliothécaire peut apporter le mauvais volume, mais le rédacteur produira tout de même un paragraphe convaincant. L’article fondateur sur le RAG distingue précisément la mémoire paramétrique du modèle d’une source externe récupérée et non paramétrique.

L’intérêt pratique est réel, à condition d’en nommer honnêtement les limites : le système peut rechercher des passages pertinents dans un corpus documentaire géré, les assembler en un contexte adapté à la question et préparer un brouillon assorti d’une référence vérifiable. La limite de responsabilité doit aussi être visible pour l’utilisateur : l’interface ne doit pas laisser croire que la présence d’une source vaut validation juridique, et signaler une erreur ou une ambiguïté doit être aussi simple que poser une question. Le RAG ne peut ni réparer une documentation de mauvaise qualité, ni garantir l’exactitude factuelle, ni mettre lui-même en place les droits d’accès, ni remplacer un workflow déterministe et une validation humaine lorsqu’une erreur crée un risque juridique, financier, de sécurité ou d’atteinte aux droits des personnes ; cette limite détermine l’architecture comme les mesures pertinentes du pilote.

Pourquoi une ancienne politique peut-elle être retrouvée comme si elle était en vigueur ?

L’incident de l’ancienne politique ne commence pas dans le modèle de langage, mais dans la gestion documentaire : le disque partagé contient « Donnees_personnelles_final.docx », « Donnees_personnelles_final2.docx » et un PDF approuvé, sans date d’entrée en vigueur uniforme, statut ni identifiant de la version remplacée. L’index voit trois candidats au contenu similaire, et la recherche sémantique peut placer l’ancien document très haut parce que sa formulation correspond plus exactement à la question. Le modèle ne connaît pas la décision prise lors d’une réunion de l’organisation si celle-ci ne figure pas dans les données, et « final » dans un nom de fichier n’est pas un mécanisme de gouvernance.

La conséquence est trompeuse, car la réponse peut paraître meilleure qu’un résultat de recherche ordinaire : elle est brève, grammaticalement correcte, renvoie vers un véritable document et donne donc l’impression que la vérification a déjà été faite. Le lien vers la source prouve seulement qu’un fichier donné a été affiché ou rattaché à la réponse ; il ne prouve pas encore que chaque affirmation découle du passage cité, que celui-ci n’a pas été arraché à une section consacrée aux exceptions, ni que le document a qualité pour faire autorité. Le profil GenAI du NIST ne considère pas cette apparence de fiabilité comme un contrôle des risques suffisant et insiste sur une gouvernance couvrant tout le cycle de vie du système.

La solution réside dans le statut de publication, la chaîne des versions et les règles de priorité, et non dans un prompt plus long : dans l’index, chaque document doit avoir un propriétaire, une date de début et de fin de validité, un statut, le document qu’il remplace, une section, une classe de confidentialité et une échéance de révision. Le filtre de récupération doit exclure par défaut les brouillons et les versions caduques ; si les sources se contredisent, le système doit montrer le conflit et s’abstenir de feindre une réponse certaine, tandis que le responsable concerné doit recevoir la tâche de remettre le corpus en ordre. Le RAG peut révéler le chaos, mais il ne peut pas transformer le chaos en politique.

Dans cette situation, l’interface de réponse doit afficher non seulement le titre du document, mais aussi sa version, son statut de validité, le passage concerné et un avertissement signalant le conflit. Le journal doit conserver les candidats retrouvés et la raison pour laquelle l’un d’eux a été retenu, afin que l’erreur puisse être reproduite après une modification de l’index. Si le système commence ensuite à donner une autre réponse, l’équipe doit pouvoir déterminer si le document, la segmentation, la configuration de la recherche ou le modèle ont changé ; sans cette traçabilité, un incident de qualité devient une supposition sur le « comportement de l’IA », au lieu de rester un défaut du système que l’on peut corriger.

Qu’est-ce que le RAG et comment fonctionne-t-il sur les documents d’une entreprise ?

Le pipeline RAG commence par l’ingestion des données, et non par la fenêtre de chat : les fichiers sont prélevés dans des espaces de stockage définis, puis le texte, les tableaux et la structure disponible en sont extraits ; les documents numérisés nécessitent une reconnaissance optique de caractères, ou OCR. Le contenu est ensuite divisé en passages cohérents, tout en conservant pour chacun un lien vers le document, la page, la section et les métadonnées de gouvernance. Les recommandations de Microsoft présentent la segmentation comme un choix qui influe sur l’utilité de la recherche : un passage trop court perd l’idée, un passage trop long ramène beaucoup de bruit, tandis qu’un découpage aveugle selon un nombre fixe de caractères peut couper un tableau ou une condition d’exception.

À l’étape de l’indexation, les passages reçoivent une représentation adaptée à la recherche, généralement en combinant une recherche par mots-clés avec une comparaison sémantique fondée sur des vecteurs numériques. Lorsqu’un utilisateur pose une question, le système peut la transformer en plusieurs requêtes de recherche, appliquer des filtres de service, de date et d’accès, récupérer des candidats, puis les reclasser ; alors seulement les passages sélectionnés entrent dans la fenêtre de contexte du modèle avec la consigne suivante : répondre à partir des preuves disponibles, indiquer les sources et dire lorsque ces preuves ne suffisent pas. À ce stade, rien n’est « appris pour toujours » : le contexte ne vaut que pour la requête concernée.

La dernière étape est la génération : un modèle de langage préentraîné transforme les passages en une réponse compréhensible. Il peut donc aussi les reformuler maladroitement, relier des sources incompatibles ou ajouter un détail plausible issu de ses connaissances générales. Le résultat doit conserver le lien entre chaque passage et chaque affirmation, pas seulement ajouter une liste décorative de sources à la fin de la réponse. Si la question exige une action — modifier un prix dans le CRM, par exemple — il ne faut pas laisser le modèle l’exécuter librement : le code de l’application, les droits et une étape de validation contrôlent la demande d’appel d’outil structurée. La récupération aide à trouver les éléments probants ; elle ne donne pas l’autorisation d’agir.

Dans la pratique, une récupération hybride fonctionne bien : le code exact d’un produit ou le numéro d’une politique est recherché comme mot-clé, tandis que le sens de la question fait l’objet d’une recherche sémantique ; un reclassement sélectionne ensuite les passages qui répondent le mieux à la question tout entière. Cette séquence doit être testée avec de vrais sigles, des codes mal orthographiés, des variations grammaticales et des documents multilingues, car la question d’une démonstration est généralement trop propre. Si le passage nécessaire n’apparaît pas parmi les candidats, le modèle génératif ne pourra pas le récupérer par son éloquence : l’erreur de recherche doit être corrigée avant de reformuler le prompt.

Pour quels usages documentaires le RAG est-il adapté ?

Les meilleurs candidats sont les questions dont la réponse existe déjà dans de nombreux documents gérés, mais dont la recherche prend trop de temps à une personne : procédures internes, manuels de produits, instructions techniques, documentation qualité, explications de modèles de contrats et base de connaissances du support client. Ici, la mission du RAG n’est pas d’inventer une nouvelle décision, mais de retrouver la bonne section, de réunir quelques passages compatibles et de préparer un brouillon. Une bonne question serait « dans quelle instruction cette erreur est-elle décrite et quelles étapes de vérification y sont indiquées ? », plutôt que « comment l’entreprise doit-elle réagir à toute situation d’urgence ? ». Une couche d’exploration documentaire en amont du travail humain peut aussi être utile : un chef de projet peut retrouver des conditions de livraison dans des contrats, un acheteur les mentions d’une exigence et un technicien les solutions apportées autrefois à un équipement similaire. Dans ces cas, la réponse doit ouvrir l’endroit précis de la source pour permettre à l’utilisateur de vérifier le contexte, et le système doit journaliser la requête, les passages retrouvés et la version utilisée. Le RAG devient ainsi un outil de navigation et de rédaction, et non un juge anonyme dont on ne pourrait plus reconstituer le cheminement.

Les mauvais candidats sont les tâches dépourvues de fondement documentaire stable, celles qui exigent une arithmétique exacte ou l’application de règles, et celles où une seule erreur déclenche automatiquement une action irréversible. Le calcul des salaires, l’attribution des accès, l’exécution d’un paiement et le suivi d’un délai légal relèvent du code et de règles métier vérifiables ; le RAG peut retrouver l’explication de la procédure, mais il ne peut remplacer ni le moteur de calcul ni la chaîne d’autorisation. Si l’objectif réel consiste à relier des systèmes et à déplacer des données de manière prévisible, il faut envisager l’automatisation des processus métier, au lieu de placer une réponse générative au centre du processus de décision.

L’adéquation dépend aussi du responsable désigné : chaque corpus documentaire a besoin d’une personne qui approuve les sources, résout les conflits et décide d’un retrait de l’index, tandis que chaque cas d’usage doit avoir une équipe qui examine les erreurs et modifie le jeu de tests. Si personne n’assume ce travail, le pilote devient après quelques mois le miroir de documents périmés, même si le modèle n’a pas changé. Un guide de support techniquement simple mais bien géré constitue donc un meilleur premier projet que le raccordement de tout le disque de l’entreprise en une soirée.

Ce que le RAG peut faire avec les documents de l’entreprise au quotidien

Le RAG peut réduire le temps qu’un salarié passe à deviner le bon dossier et les bons mots-clés, car la recherche sémantique peut retrouver un passage même lorsque les mots de la question ne correspondent pas à la terminologie du document. Il peut réunir dans une réponse plusieurs sources compatibles, expliquer une instruction complexe dans une langue plus simple, préparer le brouillon d’un e-mail ou d’un rapport et montrer de quelles pages provient chaque affirmation importante. La recherche de fichiers d’OpenAI et l’architecture de recherche de Microsoft sont des exemples concrets d’outils, mais le choix du produit ne dispense pas de définir le statut de vos documents, vos filtres et vos contrôles qualité. Le système peut aussi révéler des problèmes de documentation que la navigation ordinaire dans les dossiers dissimule : deux instructions contradictoires sont retrouvées pour une même question, des questions fréquentes restent sans source, ou un service domine les résultats parce que ses fichiers sont mieux structurés. Ces cas n’ont de valeur que s’ils ne sont pas cachés derrière une réponse unique et fluide ; une source introuvable et un conflit doivent devenir des événements mesurables, visibles par le propriétaire du document. Le journal qualité du RAG devient alors aussi une liste de travaux de gestion des connaissances, et non le seul graphique des performances du modèle.

Une autre possibilité réelle consiste à adapter la présentation au rôle et au contexte : un technicien reçoit une instruction détaillée avec les codes, tandis qu’un conseiller clientèle obtient une explication plus courte, à condition que tous deux soient autorisés à consulter les mêmes sources. C’est la présentation qui change, pas la vérité ; chaque rôle doit conserver le même statut de source et la même interdiction d’inventer ce qui manque. Notre travail sur les solutions d’IA pour les entreprises commence par la définition de ce cas d’usage et de ses limites de risque, et non par une démonstration du modèle, car un bon prototype prouve un gain concret sur vos documents tout en montrant les questions auxquelles le système doit répondre « je ne sais pas ».

Au quotidien, le gain le plus important apparaît lorsque la personne voit ce que le système a fait à sa place et ce qu’elle doit encore vérifier. Le brouillon de réponse peut mettre en évidence les affirmations insuffisamment étayées, proposer des documents liés et permettre de signaler en une seule action une mauvaise version ; ce retour est plus utile qu’une simple icône de pouce. La correction doit être rattachée à la question, au passage et au type d’erreur pour que l’équipe distingue une source introuvable d’une formulation maladroite ou d’une règle métier erronée, et choisisse le correctif approprié.

Ce que le RAG ne peut pas faire, aussi convaincante que soit sa réponse

Le RAG ne peut pas garantir la vérité, car l’erreur peut survenir avant, pendant ou après la génération : la source peut contenir un fait erroné, la récupération sélectionner un passage inadapté, le contexte perdre une exception, et le modèle relier incorrectement deux paragraphes exacts. Une citation ne réduit le risque de confiance aveugle que si l’utilisateur peut ouvrir l’emplacement précis et vérifier que l’affirmation en découle réellement ; un lien vers un véritable PDF n’est pas un label de qualité, pas plus qu’une bibliographie dans un rapport erroné ne suffit à rendre sa conclusion juste.

Il ne peut pas instaurer lui-même un contrôle d’accès : si, avant la récupération, la couche de recherche ne filtre pas les documents selon une identité utilisateur vérifiée et les autorisations du document, le contexte du modèle peut recevoir un passage que l’utilisateur n’a pas le droit de voir. Écrire ensuite « ne révèle pas d’informations confidentielles » dans le prompt ne corrige pas cette erreur d’architecture. Les recommandations de Microsoft sur l’accès au niveau des documents prévoient des données d’autorisation et des filtres de sécurité au sein même du parcours de recherche ; un bouton caché dans l’interface utilisateur ne constitue pas une protection si la requête peut être appelée autrement.

Le RAG ne sécurise pas non plus un contenu non fiable : un document, une page web ou un e-mail peut contenir une instruction destinée à réécrire le comportement du système — une injection de prompt —, et l’OWASP en fait un risque distinct qu’une simple interdiction dans le prompt système ne résout pas entièrement. Les contenus externes doivent donc être traités comme des données, pas comme des commandes ; les appels d’outils doivent être étroitement autorisés et validés, tandis qu’une action à haut risque doit rester soumise à une règle déterministe et à une validation humaine. Le modèle peut proposer ; le système accorde les autorisations.

La liste des limites doit aussi inclure la disponibilité et la continuité d’activité : si l’index de recherche est inaccessible, un système sûr ne prétend pas qu’il dispose encore des sources de l’entreprise, mais bascule clairement vers un état d’erreur ou un mode restreint. Sinon, l’utilisateur ne peut pas distinguer une réponse fondée sur les sources d’une libre improvisation du modèle. Il faut également prévoir des plafonds de coûts et de requêtes, un arrêt d’urgence et le rétablissement de la configuration précédente ; un produit RAG est une chaîne de plusieurs services, et chaque défaillance silencieuse peut modifier le sens de la réponse même si la fenêtre de chat continue de fonctionner.

Préparation des documents : OCR, métadonnées et gestion des versions

Le volume d’un dossier documentaire ne mesure pas sa préparation : un contrat numérisé avec une page inclinée, un tableau sans en-tête lisible, un PDF dont le texte suit un ordre incorrect ou une photo faiblement contrastée peuvent sembler compréhensibles à une personne, mais perdre un chiffre, le lien entre les colonnes ou la limite d’un paragraphe dans l’extraction OCR. La documentation de Microsoft sur les limites de l’OCR relie explicitement le résultat à la qualité de la numérisation, à la résolution, au contraste, à l’éclairage, à l’orientation et aux propriétés du texte. Il faut donc contrôler des documents représentatifs après l’extraction en comparant le texte, les tableaux, les renvois aux pages et les champs essentiels avec l’original, au lieu de considérer qu’un fichier « traité avec succès » est nécessairement correct.

Les métadonnées donnent au passage son contexte organisationnel : type de document, unité, produit, langue, propriétaire, approbateur, confidentialité, date d’entrée en vigueur et statut de la version permettent de restreindre la requête avant d’évaluer la similarité sémantique. Sans elles, le moteur de recherche compare des phrases, mais ignore qu’une instruction d’entrepôt ne concerne que la Lituanie ou qu’une nouvelle annexe a remplacé celle d’un contrat. Les champs les plus importants doivent provenir d’un système fiable ou être contrôlés par une personne ; une supposition générée sur le statut d’un document ne doit pas devenir le filtre qui détermine la réponse suivante.

La mise à jour fait elle aussi partie du produit ; ce n’est pas une importation ponctuelle. Il faut savoir sous quel délai une modification approuvée atteint l’index, comment un passage retiré est supprimé, ce qui arrive lorsqu’une adresse de fichier change et si le système continue d’afficher l’ancienne version en cas d’échec. Les recommandations de Microsoft sur les index distinguent les mises à jour incrémentielles de la réindexation : chaque source a donc besoin d’une méthode documentée de synchronisation et de contrôle des erreurs. Avant un projet RAG, il vaut la peine de remettre en ordre un flux documentaire faisant autorité ; sinon, une récupération rapide ne fait qu’accélérer les conséquences d’une gouvernance ambiguë.

Avant la première indexation, un échantillon de préparation documentaire est utile : choisissez des fichiers de types, d’âges, de langues, de tableaux, de numérisations et de classes d’accès différents, puis vérifiez pour chacun le texte extrait, les limites des passages, les métadonnées et le lien vers la source. Le taux d’erreur ne doit pas être ramené à une seule moyenne, car la perte d’une virgule dans une instruction et celle d’un montant dans un contrat n’ont pas le même coût. Cet échantillon permet de décider quels formats peuvent être acceptés automatiquement, lesquels exigent un contrôle humain et lesquels ne doivent pas encore être indexés ; ce travail apporte souvent une amélioration de qualité plus importante que le choix d’un autre modèle de langage.

Droits d’accès, confidentialité et choix de l’environnement d’hébergement

Une architecture sûre commence par l’identité : qui pose la question, à quelle organisation et à quel service cette personne appartient-elle, quelles classes de documents peut-elle consulter et ces droits sont-ils vérifiés à chaque requête de récupération ? Le filtre d’autorisation doit agir avant que les passages n’atteignent le contexte du modèle, tandis que les journaux doivent éviter de copier inutilement les questions, réponses et passages sensibles dans leur intégralité. Il faut aussi tester les cas limites : un salarié change de rôle, un document devient restreint, un accès est retiré, ou un client tente de retrouver le contenu d’un autre client. « Le chat exige une connexion » n’est pas un critère d’acceptation suffisant.

Il n’existe pas de réponse universelle et honnête à la question « mes données serviront-elles à entraîner le modèle ? » sans nommer le fournisseur, le produit, le compte et les paramètres. Les informations d’OpenAI sur ses produits professionnels et son API indiquent que, par défaut, les données des produits professionnels concernés ne servent pas à entraîner les modèles, tandis que la documentation sur le contrôle des données de l’API traite séparément la conservation, la surveillance des abus et les exceptions propres aux différents endpoints. Anthropic distingue de même le traitement dans les produits commerciaux, le consentement explicite à l’amélioration et les modalités de conservation. Le contrat et la conception technique doivent donc vérifier le service précis au lieu de se fier à l’expression « API professionnelle ».

Un hébergement dans une région de l’UE ou sur votre propre infrastructure peut aider à répondre à certaines exigences de localisation des données, de contrôle ou d’intégration, mais il ne démontre pas à lui seul la sécurité ni la conformité au RGPD. Il reste nécessaire de définir la finalité et la base juridique du traitement, la minimisation des données, les durées de conservation, les sous-traitants, l’effacement, le processus de gestion des incidents et l’audit des accès. Les principes du RGPD s’appliquent à toute la chaîne, et pas seulement au pays où se trouve le serveur du modèle. La bonne décision consiste parfois à exclure entièrement certains documents du RAG ou à supprimer avant leur indexation les champs inutiles à la réponse.

Le modèle de menace ne doit pas seulement tester un salarié curieux, mais aussi une synchronisation de groupes erronée, un lien partagé, un rôle d’administrateur, un cache conservé et un document contenant une instruction malveillante. Les utilisateurs de test doivent couvrir chaque rôle et chaque combinaison de rôles interdite, et essayer des questions directes, des synonymes et des demandes indirectes de synthèse. Le résultat ne doit dévoiler ni passage, ni titre de document, ni détail confidentiel que l’on pourrait déduire de la réponse. Le test doit être répété après une modification des droits, car le filtre sûr d’hier peut être resté en cache. Ces contrôles sont des critères d’acceptation, pas la décoration d’un futur audit de sécurité.

Comment mesurer la récupération, l’ancrage dans les sources et l’exactitude ?

Une seule mesure globale de « précision » pour un système RAG ressemble à une seule note moyenne pour un hôpital : le chiffre peut sembler bon alors qu’une catégorie d’erreurs critiques reste cachée. Mesurez d’abord la récupération séparément : le passage nécessaire est-il apparu parmi un nombre défini de premiers résultats, et des passages inutiles l’en ont-ils évincé ? Mesurez ensuite la pertinence du contexte pour la question, l’ancrage de la réponse dans les passages fournis, l’exactitude factuelle par rapport à une référence approuvée, la capacité de chaque citation à étayer l’affirmation précise et l’aptitude du système à s’abstenir de répondre lorsqu’une source manque ou que les sources se contredisent.

La documentation de Microsoft sur les évaluateurs RAG distingue ces dimensions, et les travaux de recherche ARES séparent de façon comparable la pertinence du contexte, l’ancrage de la réponse et la pertinence de la réponse. Dans un jeu de tests pratique, chaque question réelle demande donc plus que la « bonne réponse » : elle doit aussi avoir une source obligatoire, des formulations autorisées, des affirmations interdites, un rôle, une version du document et un comportement attendu lorsque les preuves sont insuffisantes. Certains exemples doivent provenir des questions courantes, d’autres d’exceptions coûteuses et de pièges délibérés.

Le seuil d’acceptation doit être fixé pour chaque dimension et chaque catégorie de risque avant que les résultats ne soient connus. Sinon, après la démonstration, l’équipe choisira l’indicateur qui paraît le plus flatteur. Les mesures du pilote doivent aussi conserver la répartition des erreurs par type de document, service, langue et type de question, car la moyenne globale peut dissimuler de bons résultats sur les manuels et de mauvais résultats sur les tableaux des contrats. Un évaluateur automatique fondé sur un modèle permet de tester à plus grande échelle, mais un échantillon doit être examiné par une personne, et les réponses critiques comparées à une source faisant autorité, pas au degré d’assurance d’un autre modèle.

Après la mise en ligne, les mêmes dimensions doivent être mesurées sur un échantillon contrôlé de la production, avec des journaux respectueux de la confidentialité. Une modification du corpus documentaire, de l’algorithme de segmentation, du modèle d’embedding, du reclassement ou du modèle génératif peut améliorer un groupe de questions et en dégrader un autre. Chaque version a donc besoin d’un test de régression et d’une base de référence comparable, avec des règles d’évaluation inchangées pour tout le jeu de tests. Une alerte ne doit pas se déclencher uniquement quand le score global baisse, mais aussi lorsqu’apparaît une erreur critique, comme un passage non autorisé ou une réponse inventée là où le système devait s’abstenir.

RAG, recherche, contexte long, fine-tuning et agents

La recherche plein texte ordinaire est préférable lorsque l’utilisateur connaît le nom, le code ou l’expression exacts et a besoin d’un document plutôt que d’une réponse composée : elle coûte moins cher, est plus prévisible et se prête mieux à l’audit. La recherche sémantique aide avec les synonymes et les questions imprécises, mais la génération ne doit être ajoutée que lorsqu’une synthèse apporte une véritable valeur. Le RAG n’est pas obligatoire dans chaque outil de recherche d’entreprise : le bon produit est parfois une bonne page de recherche avec des filtres, un aperçu du passage et le statut de la version, car l’utilisateur peut tirer lui-même sa conclusion du document complet.

Placer tout un document dans une longue fenêtre de contexte peut être simple pour un volume réduit et stable, mais, dans un vaste corpus, cela augmente le coût, le bruit et le risque qu’un paragraphe important se perde parmi des contenus sans pertinence. Le fine-tuning du modèle peut quant à lui renforcer un format, un style ou le comportement propre à une tâche, mais ce n’est pas un moyen pratique de stocker des prix, des politiques et des instructions qui changent souvent, car leur mise à jour et la citation de leurs sources deviennent moins transparentes. Le RAG permet de modifier le corpus documentaire indépendamment de l’entraînement des poids du modèle, mais cette souplesse exige de gérer l’index, les versions et la qualité de la récupération.

L’automatisation exécute des étapes prédéfinies, tandis qu’un agent d’IA peut choisir un outil et l’étape suivante ; cette liberté impose donc des limites plus strictes en matière de pouvoirs, de validation et d’arrêt. Le RAG peut fournir des informations à un agent, pas lui accorder des droits : même si le modèle retrouve la politique de congés, il ne doit pas pouvoir approuver lui-même une absence ou modifier le système de paie. Un appel de fonction structuré n’est qu’une proposition adressée à l’application, qui contrôle le schéma, l’identité, l’action permise, le montant ou les autres limites et la validation humaine nécessaire. La comparaison des technologies commence par le risque du processus, pas par l’envie d’utiliser le terme le plus récent.

Le choix peut se résumer par un test simple : si vous devez trouver et ouvrir un fichier, commencez par la recherche ; si vous devez synthétiser quelques sources changeantes et fournir des références, envisagez le RAG ; si vous devez maintenir un format stable ou un comportement de classification précis, le fine-tuning peut convenir ; si vous devez exécuter une suite prévisible d’actions, construisez une automatisation. N’ajoutez un agent que lorsque l’étape suivante ne peut pas être programmée de façon sûre et que le gain compense le risque supplémentaire. Ces approches peuvent être combinées, mais chaque couche doit avoir sa propre mission, sa propre mesure et sa propre limite d’arrêt. Sinon, la cause d’une erreur disparaît derrière le mot « IA ».

Comment construire un pilote limité à partir de vraies questions ?

Un pilote commence par un corpus documentaire, un groupe d’utilisateurs et une limite décisionnelle, par exemple les manuels du support technique, où le système se contente de retrouver des sources et de préparer un brouillon de réponse. Avant le développement, l’équipe recueille de vraies questions issues des journaux de recherche, des e-mails et d’entretiens avec les salariés, ajoute les bonnes sources et inclut délibérément des cas impossibles à traiter, périmés, contradictoires et non autorisés. Pour chaque cas, elle définit ce qui est acceptable : le passage nécessaire est retrouvé, l’affirmation s’appuie sur la source, la citation mène au bon endroit, la réponse est factuellement exacte et le système n’invente pas ce qui manque.

Les seuils sont fixés avant la démonstration et répartis selon le risque : un brouillon que l’on peut corriger peut convenir à une question d’information courante, tandis qu’une question portant sur des données à caractère personnel, un contrat, la sécurité ou un paiement exige un contrôle plus strict et une validation humaine. Le pilote doit également mesurer le temps de réponse, le coût par requête, le fonctionnement des filtres d’accès, le délai de mise à jour de l’index et la fréquence à laquelle un salarié ouvre la source ou corrige la réponse. Si le système améliore uniquement les exemples de la démonstration, sans être à la hauteur sur un jeu de tests auparavant caché, aucun résultat produit n’est démontré ; seule la capacité de l’équipe à préparer une démonstration l’est.

Le développement de nos solutions d’IA pour les entreprises débute à 3 500 € et prend généralement 3–8 semaines, tandis qu’un pilote fonctionnel sur vos propres données peut être livré en 2–3 semaines ; ces chiffres décrivent le prix de départ du service et son calendrier général, et non une offre forfaitaire pour un périmètre inconnu. À l’issue du pilote, le livrable ne doit pas se limiter à une fenêtre de chat : il doit comprendre un corpus documentaire versionné, des questions de test, des mesures de qualité distinctes, un journal des erreurs, des contrôles d’accès et une décision sur ce que la solution ne doit pas faire. Les besoins d’intégration ultérieurs doivent être consignés aussi clairement que dans tout autre projet numérique, conformément au principe décrit dans notre article sur les 10 erreurs à éviter lors de la création d’un site web : les critères d’acceptation et les responsables doivent être définis avant le déploiement complet, pas après le premier écran impressionnant.

Le pilote ne doit se poursuivre que s’il atteint les seuils définis à l’avance sur une partie inédite du jeu de tests, traite de manière sûre les questions non autorisées ou sans réponse et produit un gain mesurable dans le travail humain. Si la récupération ne retrouve systématiquement pas la bonne source, il faut d’abord corriger les documents, les métadonnées et l’index. Si la source est la bonne, mais que la génération la déforme, il faut modifier le contexte, le prompt ou le modèle. Si l’erreur ne survient que dans des décisions à haut risque, ces décisions doivent être laissées à un système déterministe et à une personne. Un pilote interrompu n’est pas un échec : c’est une preuve obtenue à faible coût que, dans ce processus précis, les limites du RAG importent davantage que l’effet produit par sa démonstration.