Nous en sommes au troisième jour d’une mission auprès d’un courtier d’assurance de taille moyenne, et le responsable des opérations de gestion des sinistres demande un outil de chat capable de répondre rapidement aux gestionnaires de sinistres. Il souhaite que l’outil cite les règles de police les plus récentes, explique les exceptions et indique la page exacte dans le manuel de référence approprié. Lors de la même réunion, le service juridique ajoute une contrainte supplémentaire : l’outil ne doit jamais afficher le contenu d’un contrat client à moins que le gestionnaire ne soit affecté à ce compte.
C’est ici qu’intervient la génération augmentée par récupération (RAG) personnalisée pour le client dans le cadre des déploiements FDE (Forward Deployed Engineering). Le RAG personnalisé est une configuration dans laquelle le système d’IA formule une réponse en extrayant d’abord des faits des sources propres au client, puis en rédigeant la réponse à partir de ces faits. Cette approche est dite « personnalisée » car les sources évoluent avec le temps et parce que c’est le client — et non nous — qui définit ce qui constitue une réponse acceptable.
En pratique, nous ne livrons pas un chatbot générique. Nous livrons un flux de réponse lié à des documents réels, à des autorisations réelles et à des résultats métier concrets. Pour le courtier, une réponse « correcte » est une réponse qui correspond à la version actuelle du manuel, qui la cite et qui respecte les règles d’accès au niveau du compte, même lorsque la question est ambiguë.
L’approche fondamentale du FDE consiste à considérer le RAG comme un système de bout en bout, et non comme une simple fonctionnalité. Si l’on se concentre uniquement sur les prompts du modèle, on néglige les éléments qui garantissent la sécurité et la fiabilité en production. La suite de ce cours s’appuiera sur l’exemple de ce courtier, car chaque décision prise aura un impact direct sur ce que le gestionnaire de sinistres verra au moment où il aura besoin d’une réponse.
Les défaillances du RAG en production sont rarement spectaculaires. Elles sont généralement silencieuses, plausibles et coûteuses. Le gestionnaire reçoit une réponse qui semble correcte, agit en conséquence, et ce n’est que plus tard que l’on s’aperçoit que le sinistre a été traité selon une règle erronée.
Prenons la situation suivante : le courtier téléverse un nouveau bulletin concernant les « exceptions pour dégâts des eaux » le lundi. Le mercredi, l’outil de chat répond toujours en utilisant le manuel du mois précédent, car le pipeline de contenu n’a pas réintégré le nouveau fichier. Aucune erreur ne survient, et le système peut même citer un numéro de page réel. Il s’agit simplement du mauvais numéro de page pour l’ensemble des règles actuelles.
Un autre problème fréquent concerne les limites d’accès. Si l’étape de récupération a accès à un document, le système d’IA peut finir par le résumer, même si l’utilisateur final n’est pas censé y avoir accès. C’est pourquoi la gestion des autorisations ne doit pas être considérée comme un simple détail d’interface utilisateur dans un système RAG. Ils font partie intégrante de la conception du système de recherche d’informations et doivent être appliqués avant que le texte ne soit transmis au modèle.
Les échecs silencieux constituent un autre problème critique. Une question telle que « Peut-on se dispenser de l’inspection si les dommages sont inférieurs à 2 000 $ ? » peut nécessiter la prise en compte d’une clause d’exception spécifique. Si le système de recherche ne parvient pas à la trouver, le modèle cherchera souvent à se montrer utile malgré tout, en comblant le vide par une règle d’apparence générique. En l’absence de mesure, vous ne remarquerez pas cette dérive avant que les équipes métier ne signalent un problème.
Découvrez comment ces défaillances se traduisent concrètement par un impact sur l’activité.
Anticipez la dérive, prouvez la qualité Si vous ne suivez pas l’évolution de la qualité dans le temps, sachez qu’elle change déjà sans que vous puissiez encore le constater.
Ces modes de défaillance soulèvent la véritable question liée au FDE (Foundation Model Development & Evaluation). Quelles décisions devons-nous prendre, et dans quel ordre, pour garantir la fiabilité du système face aux évolutions des documents, des utilisateurs et des règles métier ?
La mise en œuvre d’un système RAG (Retrieval-Augmented Generation) personnalisé pour un client repose sur une chaîne de décisions où chaque maillon conditionne les possibilités du maillon suivant. Si l’on se précipite sur le choix des embeddings ou la taille des segments de texte (chunking), on risque de devoir réécrire le système plus tard lorsqu’une règle métier — qui aurait dû être une exigence fondamentale dès le départ — finit par émerger.
Commencez par définir des exigences suffisamment précises pour être testées. Pour le courtier, nous rédigeons des critères d’acceptation tels que « doit citer la section exacte du manuel » et « doit refuser de répondre si l’utilisateur n’a pas les droits d’accès ». Il ne s’agit pas d’objectifs vagues, mais de critères binaires (succès/échec) que nous pouvons transformer en un jeu de données d’évaluation.
Viennent ensuite les données. Nous cartographions les sources qui alimenteront le système de recherche (retrieval) ainsi que leur dynamique d’évolution : manuels sur SharePoint, bulletins transmis par e-mail, contrats clients issus d’un export CRM. Nous identifions également les droits d’accès de chacun, car ce modèle de permissions déterminera la manière dont les données sont indexées et filtrées au moment de la requête.
Puis vient la conception du système de recherche. Cette étape définit la manière dont le système sélectionne les extraits de documents à présenter au modèle. La décision majeure consiste à déterminer si l’on peut filtrer les résultats selon les permissions au moment de la requête, ou s’il est nécessaire de créer des index distincts par segment pour éviter toute fuite d’information. Dans le cas du courtier, la nature des contrats clients incite souvent à opter pour un filtrage strict, car la moindre erreur constitue un incident grave.
Le grounding (ancrage) consiste à maintenir le modèle étroitement lié au texte récupéré. Il implique généralement des règles telles que « répondre uniquement à partir du contexte fourni » et « inclure des citations ». Il définit aussi le comportement du système en l’absence de contexte pertinent : poser une question de clarification ou répondre par une phrase du type « Je ne trouve pas cette information dans les documents de politique actuels ».
L’évaluation permet de rendre la fiabilité mesurable. Elle repose sur un ensemble reproductible de questions de test associées à des comportements attendus, exécutées avant et après chaque modification. Pour ce courtier, nous accordons une attention particulière à l’exactitude des citations, à la pertinence des refus d’accès pour les documents restreints et à la couverture des scénarios de sinistres à haut risque.
Les décisions de déploiement transforment l’ensemble en un système opérationnel. Nous définissons les modalités d’ingestion des données, la fréquence de mise à jour des index, les méthodes de journalisation sécurisée des requêtes et le processus de déploiement des mises à jour. Le cycle d’itération s’inscrit alors dans un cadre sécurisé : lorsqu’un expert en sinistres signale une erreur, nous déterminons si elle provient d’une lacune dans les données, dans le système de recherche ou dans les instructions, puis nous corrigeons la couche appropriée.
Considérez les étapes comme un système interconnecté de choix.