Nous avons construit un assistant de recherche documentaire qui répond aux questions de gouvernance directement dans Microsoft Teams, en s’appuyant strictement sur les documents sources et en citant le paragraphe exact d’où provient la réponse. Voici l’architecture, les choix de conception et l’ingénierie qui rendent une réponse suffisamment fiable pour qu’on puisse s’y fier.
Toute organisation dotée d’une fonction conformité connaît la même inefficacité silencieuse. Les politiques, les normes et les procédures sont complètes et bien rédigées, et presque personne ne les lit en entier. À la place, les équipes posent sans cesse les mêmes quelques questions, et ces questions atterrissent chez la personne qui gère les documents plutôt que d’être traitées à partir des documents eux-mêmes. L’expert devient un service de consultation, et le savoir qui devrait être en libre-service reste bloqué dans l’agenda d’une personne.
La solution n’est pas un énième portail ni un meilleur moteur de recherche. C’est un assistant qui lit la documentation source à votre place et répond en langage clair, dans l’outil où vos équipes travaillent déjà. C’est exactement ce que nous avons construit : un assistant de conformité dans Microsoft Teams qui répond à une question en quelques secondes, tire sa réponse uniquement des documents approuvés, et affiche la citation pour que le lecteur puisse la vérifier. Cet article explique comment il fonctionne et pourquoi chaque décision a été prise ainsi, écrit pour être utile que vous validiez le budget ou que vous écriviez le code.
Posez une question dans Teams. L’assistant récupère les passages les plus pertinents de votre bibliothèque de gouvernance, compose une réponse strictement fondée sur ce texte, et cite le document source. Si la réponse ne figure pas dans le corpus, il le dit plutôt que d’en inventer une.
L’idée, pour tout le monde
Un chatbot généraliste est un généraliste sûr de lui. Il répondra à une question de politique interne par quelque chose qui sonne juste, assemblé à partir du web ouvert et de ses données d’entraînement. En conformité, c’est précisément le mauvais comportement. Une réponse plausible mais non traçable jusqu’à votre politique réelle est pire que pas de réponse du tout, car quelqu’un agira en conséquence.
La génération augmentée par récupération, ou RAG, change la donne. Plutôt que de répondre de mémoire, le modèle reçoit les passages précis de vos documents qui concernent la question, avec la consigne de répondre uniquement à partir de ces passages. L’intelligence réside dans la récupération et la rigueur, pas dans les opinions du modèle. Résultat : un assistant dont les réponses sont auditables, car chacune renvoie au paragraphe dont elle provient.
L’architecture
Le système comporte deux moitiés qui s’exécutent rarement en même temps. L’ingestion est la tâche ponctuelle qui transforme les documents en une base de connaissances interrogeable, répétée uniquement lorsqu’un document change. Le chemin de requête, lui, s’exécute à chaque question, et c’est là que la rapidité, le contrôle d’accès et l’ancrage doivent tous tenir ensemble.
Figure 1. Les deux pipelines. L’ingestion convertit une fois les documents sources en vecteurs. Le chemin de requête s’exécute à chaque question, avec le contrôle d’accès placé avant toute récupération, de sorte qu’une requête non autorisée n’atteint jamais la base de connaissances.
À l’ingestion, les documents sources sont chargés depuis le stockage blob et découpés en passages qui se chevauchent d’environ 500 caractères, avec 50 caractères de chevauchement pour qu’une phrase ne soit jamais coupée net à une frontière. Chaque passage est converti en un vecteur numérique qui capture son sens, un embedding de 1536 dimensions produit par le modèle text-embedding-ada-002 d’OpenAI, puis stocké dans une base vectorielle Chroma, étiqueté avec son document source et une référence pour la citation. Le chevauchement et l’étiquetage ne sont pas des détails anodins. Le chevauchement préserve l’intégrité d’une réponse à cheval sur deux passages, et l’étiquette est ce qui permet à l’assistant d’indiquer au lecteur d’où vient une réponse.
À chaque question, le flux est délibéré : Teams transmet le message au service de bot, qui l’achemine vers l’API, laquelle vérifie d’abord si l’utilisateur a le droit de poser la question. Ce n’est qu’ensuite que le système vectorise la question, récupère les passages les plus proches, et les transmet au modèle pour composer une réponse ancrée et citée. L’ordre a son importance, et c’est le point suivant qui mérite qu’on s’y attarde.
Le contrôle d’accès par conception
La manière la plus courante de greffer l’autorisation sur un système RAG consiste à filtrer les résultats après la récupération, ou à tronquer la réponse avant de la renvoyer. Les deux sont plus fragiles qu’il n’y paraît, car à ce stade la requête a déjà touché la base de connaissances et le modèle. Nous plaçons le point de contrôle d’accès en tête de la couche API, avant qu’un seul passage ne soit récupéré. Si une requête n’est pas autorisée, elle n’atteint jamais la base vectorielle ni le modèle.
Figure 2. Le point de contrôle d’accès se situe en amont de la récupération. Une requête non autorisée est refusée avant de pouvoir toucher la base de connaissances ou le modèle, ce qui est plus propre, plus économique et plus auditable qu’un filtrage a posteriori.
C’est plus propre, plus économique et plus facile à auditer. Plus propre, car le chemin des données sensibles n’a qu’une entrée et un seul gardien. Plus économique, car les requêtes refusées ne coûtent rien en récupération ni en appels au modèle. Plus auditable, car la décision d’autoriser ou de refuser est un événement unique et journalisé, en un point unique, plutôt qu’une propriété émergente de plusieurs filtres en aval. Quand un audit de sécurité demande comment vous empêchez les accès non autorisés, la réponse est un emplacement sur un schéma, pas un paragraphe de réserves.
Le prompt d’ancrage
L’ancrage est imposé par les instructions que le modèle reçoit avec chaque question. Le prompt est volontairement strict, et deux de ses règles sont déterminantes. Le reste du prompt relève de l’intendance, mais ces deux règles font toute la différence entre un outil qu’une équipe conformité utilisera en confiance et un outil qu’elle délaissera discrètement.
Rules:
– Answer concisely and accurately.
– Use context even if not labelled exactly as asked.
– Do not add examples not explicitly stated in the context.
– Always cite the source document.
– Fall back only if the context has nothing relevant.
Le prompt système reste en anglais, la langue dans laquelle le modèle a été réglé.
Utiliser le contexte même s’il n’est pas formulé exactement comme la question. Sans cette règle, le modèle écarte un passage parfaitement pertinent parce que sa formulation ne correspond pas mot pour mot à la question. Les questions transverses à plusieurs documents, où la réponse se trouve sous une terminologie différente de celle employée par l’utilisateur, en sont les premières victimes. Cette règle garde l’assistant utile sur un corpus réel, et pas seulement sur des questions formulées comme les documents se trouvent l’être.
Ne pas ajouter d’exemples qui ne figurent pas explicitement dans le contexte. C’est le garde-fou contre les hallucinations. Sans contrôle, un modèle inventera volontiers un détail de politique plausible qui n’apparaît dans aucun de vos documents, et cela se lira exactement comme une bonne réponse. C’est ce qui le rend dangereux. Cette seule instruction referme le mode de défaillance le plus dommageable pour un assistant de conformité.
Un dernier réglage sous-tend l’ensemble. La température du modèle est fixée à zéro, si bien que la même question renvoie toujours la même réponse, et non une formulation différente à chaque exécution. En conformité, la reproductibilité n’est pas un luxe. C’est ce qui vous permet d’assumer une réponse une deuxième fois.
Un assistant de conformité doit être évalué sur la confiance qu’on peut lui accorder, pas sur son intelligence. Chaque choix de conception ici échange un peu de portée contre beaucoup de fiabilité, et dans ce domaine, c’est le bon compromis.
L’évaluation
Un assistant qu’on ne peut pas mesurer ne peut être ni amélioré ni défendu. Nous évaluons sur un jeu fixe de questions de test à l’aide de six métriques, et nous optimisons celle qui reflète la confiance plutôt que celle qui flatte la démo. Une vérification manuelle par sondage passera à côté des défaillances qui comptent ; un harnais d’évaluation automatisé les fait remonter systématiquement, à chaque modification.
Figure 3. Scores d’évaluation de cette version. La fidélité (faithfulness) est la métrique que nous optimisons. Le rappel à cinq est délibérément mesuré à la profondeur de récupération utilisée en production, plutôt que gonflé à un k plus élevé.
La fidélité (faithfulness), à 0,98, est la métrique que nous optimisons. Elle mesure si la réponse est entièrement étayée par le contexte récupéré, autrement dit si l’assistant invente quoi que ce soit. En conformité, une réponse qui n’invente rien vaut mieux qu’une réponse qui récupère chaque phrase potentiellement pertinente. Le rang réciproque moyen (MRR) compte aussi, car il récompense le passage le plus pertinent lorsqu’il se place en haut du contexte plutôt qu’enfoui au milieu, là où les modèles lui prêtent régulièrement moins d’attention.
Le rappel à cinq, à 0,41 pour un objectif de 0,70, paraît faible, et c’est honnête, pas cassé. Le rappel à cinq mesure combien de passages pertinents figurent parmi les cinq premiers résultats récupérés. Lorsqu’une seule question peut compter une douzaine de passages pertinents, voire plus, dans le corpus, un rappel parfait à cinq est arithmétiquement impossible. Mesurer à un k plus élevé pour améliorer le chiffre flatterait la métrique sans améliorer le produit, car cinq est la profondeur à laquelle l’assistant lit réellement. Nous fixons l’objectif par rapport au k utilisé en production et le rapportons tel quel. Une équipe qui gonfle le rappel optimise la diapositive, pas l’assistant.
Les quatre modes de défaillance contre lesquels nous concevons
Faire passer un système RAG d’un prototype fonctionnel à un déploiement Teams fiable sur Azure fait apparaître un petit ensemble de modes de défaillance, faciles à manquer et rapides à corriger une fois qu’on les reconnaît. Nous instrumentons les quatre avant le premier déploiement, de sorte qu’un déploiement défectueux se signale de lui-même en moins d’une minute, plutôt qu’après un après-midi de tâtonnements.
Figure 4. Quatre modes de défaillance et leurs corrections. Le fil conducteur est l’instrumentation : journaliser le nombre d’éléments de la collection, le locataire d’authentification et la réponse de l’API Graph au démarrage vous indique immédiatement où un déploiement a dérapé.
Des quatre, la base de connaissances vide est le plus insidieux, car rien ne semble cassé. L’application tourne, répond à chaque question et ne lève aucune erreur ; seul le contenu derrière elle manque, si bien que la défaillance se cache en pleine vue. C’est pourquoi l’instrumentation compte plus que n’importe quel correctif isolé. Journalisez le nombre de passages, le locataire d’authentification et la réponse Graph au démarrage, et une défaillance silencieuse se signale en une ligne plutôt que de coûter un après-midi de tâtonnements.
La feuille de route
Les principes ci-dessous ont façonné cette version et façonneront la suivante. Ils résument tout ce qui précède.
Le question-réponse est la version un, pas la destination. La même fondation de récupération qui répond à la demande peut aussi agir de façon proactive : rappels d’audits à venir, suivi des non-conformités, et alertes sur les dates de revue qui approchent, remontés dans Teams sans que personne ait à demander. La couche de récupération construite aujourd’hui pose les bases d’une fonction conformité qui va au-devant des besoins au lieu d’attendre qu’on l’interroge. C’est le tournant qu’il vaut la peine d’anticiper, et il commence par bien poser les fondations, ennuyeuses mais fiables.
Nous concevons et construisons des assistants sur lesquels vos équipes peuvent réellement compter, ancrés dans votre propre documentation et évalués sur les métriques qui comptent. Si vous avez un processus à forte densité documentaire qui repose sur des personnes répondant sans cesse aux mêmes questions, il en existe une version pour vous.
Nous recueillons des informations sur vos besoins et les objectifs de vos applications. Vous n’êtes pas sûr de l’application dont vous avez besoin ? Nous évaluerons soigneusement vos principaux défis et vous fournirons des conseils d’experts sur la solution parfaitement adaptée à votre réussite.
Nous créons des maquettes et un prototype interactif pour visualiser le design et les fonctionnalités de votre application et apporter des modifications en fonction de vos commentaires.
Estimation du projet en termes de ressources, de délais de livraison et de coûts impliqués.
Présentation du POC aux parties prenantes concernées en illustrant les fonctionnalités et le potentiel de l’application pour atteindre les objectifs de l’entreprise.
