Chez FutureBank, une banque internationale présente sur plusieurs marchés européens, les informations sont disponibles sous différentes formes : documents PDF, procédures RH, vidéos, images, pages internes, espaces partagés, annuaire des collaborateurs… Mais ces informations sont dispersées entre plusieurs outils et parfois plusieurs pays.
Dans une grande entreprise, l’information existe souvent déjà. Le problème est plutôt de la retrouver au bon moment.
Un collaborateur qui cherche une information peut alors passer plusieurs heures à parcourir différents espaces avant de trouver le bon document.
Et le problème se répète.
Demain, un autre collaborateur pourra avoir exactement la même question et devra refaire une partie du même parcours.
Pour un nouveau collaborateur, la situation peut être encore plus frustrante : ne sachant pas forcément où chercher ni qui contacter, il peut rapidement se retrouver face à une masse d’informations difficile à exploiter.
Quelques exemples de questions très simples :
« Quelle est la procédure pour demander un congé ? »
« Quelle est notre politique de télétravail ? »
« Où trouver le dernier rapport financier ? »
« Quelle est la procédure pour onboarder un nouveau collaborateur ? »
« Quels sont les critères de remboursement des frais ? »
Derrière ces questions se cachent surtout des points de friction dans l’accès à l’information.
L’objectif n’est donc pas de créer encore une nouvelle base documentaire, mais de rendre l’information existante plus facilement accessible aux collaborateurs.
À partir de ces observations, nous avons voulu comprendre comment FutureBank pouvait réduire le temps passé à rechercher une information, malgré la diversité des sources disponibles.
L’enjeu peut être résumé simplement :
Comment permettre à un collaborateur de retrouver rapidement une information fiable, personnalisée et issue des sources internes de l’entreprise ?
Plusieurs solutions peuvent répondre à une partie du problème.
1. Un chatbot classique
Un chatbot basé sur des règles ou des scripts prédéfinis pourrait répondre à des questions simples à partir de scénarios et de réponses préparées.
Cette approche peut être efficace pour quelques cas précis, mais elle devient rapidement limitée lorsque les questions deviennent plus complexes ou que le collaborateur change de sujet au cours d’une conversation.
2. Un assistant intelligent
La deuxième approche consiste à utiliser les technologies d’IA disponibles aujourd’hui pour permettre à l’assistant de comprendre le contexte d’une demande, de rechercher l’information pertinente et de générer une réponse adaptée à partir des informations disponibles.
La gestion de la mémoire conversationnelle et la personnalisation selon le profil de l’utilisateur peuvent ensuite être ajoutées en fonction des besoins du cas d’usage.
C’est cette deuxième approche que nous avons retenue pour FutureBank.
L’idée n’est pas simplement de permettre à un collaborateur de « discuter avec une IA ».
L’objectif est plutôt de lui donner un point d’accès unique à l’information interne, qu’il puisse utiliser en langage naturel, dans différentes langues et, à terme, par différents moyens : texte ou vocal.
Nous appelons cet assistant FastInfo.
FastInfo en situation
Pour valider le fonctionnement du prototype, nous avons réalisé plusieurs tests.
L’objectif de ces tests n’est pas encore de reproduire l’ensemble des cas d’usage présentés précédemment, mais de vérifier progressivement les capacités essentielles de l’assistant : comprendre une question en langage naturel, rechercher une information dans une base de connaissances et générer une réponse à partir des informations retrouvées.
Test 1 – Politique de télétravail
Nous commençons par une question dont la réponse se trouve dans notre base de connaissances. FastInfo recherche l’information dans les documents mis à sa disposition et génère une réponse à partir des informations retrouvées.
Figure 1 – FastInfo répond à une question à partir de sa base de connaissances.
Test 2 – Une autre recherche dans les connaissances
Nous testons ensuite un autre sujet présent dans notre documentation. FastInfo doit identifier le document et les informations pertinentes afin de fournir une réponse directement exploitable.
Figure 2 – FastInfo retrouve les informations relatives à une procédure interne.
Test 3 – Des questions hors contexte
Enfin, nous posons à FastInfo des questions qui ne concernent pas les informations présentes dans sa base de connaissances. Ce test permet notamment de vérifier le comportement de l’assistant lorsqu’une question ne concerne pas son domaine de connaissance.
Figure 3 – FastInfo face à des questions ne concernant pas sa base de connaissances.
Ces trois tests permettent ainsi de vérifier à la fois la recherche d’informations internes, la capacité à traiter différents sujets et le comportement de l’assistant lorsqu’une information ne fait pas partie de son périmètre.
Comment nous avons construit FastInfo et comment arrive-t-il à fournir l’information ?
Plusieurs approches étaient possibles pour construire FastInfo.
Nous aurions pu envisager de développer notre propre modèle d’IA, mais cette approche aurait nécessité des ressources importantes en données, en infrastructure et en entraînement.
Une autre possibilité consistait à utiliser des frameworks permettant de construire des applications d’IA autour de modèles de fondation, tout en développant nous-mêmes une partie de l’orchestration et de la gestion des différents composants.
Enfin, notre fournisseur cloud propose une plateforme permettant de développer, déployer et évaluer des applications et des agents d’IA tout en intégrant différents composants nécessaires à leur fonctionnement : modèles, connaissances, outils, évaluation et sécurité.
FutureBank disposant déjà d’une grande partie de ses données et de son infrastructure dans l’écosystème Azure et Microsoft, nous avons choisi Microsoft Foundry pour construire notre prototype FastInfo.
Microsoft Foundry permet de développer, personnaliser, évaluer et déployer des applications et des agents d’IA.
Notre première approche avec Microsoft Foundry
Nous avons commencé par créer un groupe de ressources Azure, qui permet de regrouper les ressources associées à une même solution.
Nous avons ensuite créé une ressource Microsoft Foundry ainsi qu’un projet Foundry permettant de configurer et tester notre cas d’utilisation.
Pour notre prototype, nous avons choisi une approche low-code, qui permet de créer un assistant en configurant notamment ses instructions, ses connaissances et ses outils, sans avoir à développer toute la logique de l’application.
Une approche davantage orientée développement permet également de construire des agents directement avec les outils et frameworks proposés par Microsoft, notamment Microsoft Agent Framework.
Pour cette première expérimentation, nous avons retenu l’approche low-code afin de nous concentrer sur la validation du cas d’usage.
Les composants de FastInfo
Une telle solution nécessite de connecter plusieurs composants.
Un modèle d’IA
Le premier composant est le modèle d’IA, qu’il s’agisse d’un LLM (Large Language Model) ou d’un modèle multimodal capable de traiter différentes modalités de données.
Il peut s’agir d’un modèle développé en interne, d’un modèle de fondation commercialisé ou encore d’un modèle open-weight hébergé en interne.
L’avantage d’un modèle de fondation est de ne pas partir de zéro : il possède déjà des capacités générales de compréhension et de génération de langage.
Dans notre prototype, nous avons choisi GPT-5 mini, notamment pour disposer d’un modèle adapté à notre première expérimentation tout en conservant un compromis intéressant entre capacités, rapidité et coût.
Ce choix pourra être réévalué lors des prochaines phases de test en fonction de la qualité des réponses, de la latence et du coût d’utilisation.
Les instructions
Le modèle doit également recevoir des instructions permettant de définir le rôle et le comportement attendu de FastInfo.
Elles permettent notamment de préciser :
- son rôle ;
- son domaine d’intervention ;
- la manière dont il doit répondre ;
- les informations qu’il doit privilégier ;
- Des exemples de questions et réponses;
- son comportement lorsqu’il ne trouve pas l’information ;
- le ton et le format des réponses.
Les instructions constituent ainsi une première couche permettant de contrôler le comportement de l’assistant.
La base de connaissances
Pour l’instant, notre assistant peut générer une réponse qui semble correcte grâce aux connaissances générales du modèle.
Cependant, il ne connaît pas automatiquement les politiques et procédures spécifiques de FutureBank.
Si nous lui demandons par exemple :
« Quelle est la politique de télétravail de FutureBank ? »
le modèle ne dispose pas nécessairement de la politique interne réelle de l’entreprise.
Il pourrait donc produire une réponse probable mais qui ne correspondrait pas aux règles réellement appliquées par FutureBank.
C’est là qu’intervient la base de connaissances.
Une base de connaissances peut notamment être composée de documents, procédures RH et autres ressources internes provenant des espaces de stockage de l’entreprise.
Ces contenus peuvent être indexés afin de permettre une recherche efficace, notamment grâce à des représentations vectorielles.
Des architectures comme le RAG (Retrieval-Augmented Generation) permettent alors de rechercher les informations les plus pertinentes en fonction de la question de l’utilisateur, puis de fournir ces informations au modèle afin qu’il puisse générer une réponse contextualisée.
Azure AI Search et la récupération des informations
Dans notre prototype, nous avons utilisé Azure AI Search, un service permettant notamment d’effectuer des recherches textuelles et vectorielles sur les contenus indexés.
Dans Microsoft Foundry, nous avons ensuite configuré une connaissance permettant à FastInfo d’exploiter ces informations.
Nous avons notamment défini :
- le nom et la description de la connaissance ;
- le modèle utilisé ;
- l’effort de raisonnement consacré à la récupération, configuré au niveau minimal pour nos premiers tests ;
- le mode de sortie ;
- la manière de mettre en forme les réponses ;
- les instructions de récupération permettant de guider la recherche dans les sources de connaissances.
Pour le mode de sortie, nous avons choisi la synthèse, afin que les informations retrouvées soient transformées en réponses en langage naturel plutôt que simplement retournées sous forme de données brutes.
Pour notre première expérimentation, nous avons fourni à FastInfo un guide interne fictif contenant les informations nécessaires à nos tests.
Figure 4 – Configuration de la connaissance utilisée par FastInfo dans Microsoft Foundry.
Nous avons également choisi un modèle d’embeddings afin de permettre la représentation vectorielle des contenus et des requêtes.
La chaîne de fonctionnement peut ainsi être résumée simplement :
Question de l’utilisateur -> recherche des informations pertinentes -> récupération -> génération de la réponse.
Vers de nouvelles sources de connaissances, les outils
Notre prototype repose actuellement sur une source de connaissance limitée afin de pouvoir tester simplement le fonctionnement de l’assistant.
Dans les versions suivantes, nous pourrons envisager de connecter FastInfo à davantage de sources internes, notamment SharePoint, Microsoft Fabric ou d’autres systèmes utilisés par FutureBank.
Une recherche Web pourra également être étudiée pour certains cas d’usage nécessitant des informations externes et récentes. Elle n’est cependant pas nécessaire lorsque la question porte exclusivement sur les informations internes de l’entreprise.
Nous pourrons également étudier l’utilisation de MCP (Model Context Protocol) lorsque le besoin sera confirmé.
MCP est un protocole permettant à des applications d’IA de se connecter à des outils et à des sources de données externes selon une interface standardisée.
Ces éléments constituent pour l’instant des pistes d’évolution et ne font pas partie du périmètre actuel de notre prototype.
Une architecture modulaire et réutilisable
L’utilisation d’une couche de connaissance permet également de séparer les informations de l’application qui les exploite.
Une même source de connaissance peut ainsi, selon les capacités de la plateforme et les règles d’accès définies, être exploitée par différents agents ou applications.
Cette approche favorise une architecture plus modulaire et réutilisable, puisqu’il n’est pas nécessaire de reconstruire systématiquement toute la logique de recherche documentaire pour chaque nouvelle application.
La mémoire
Une prochaine évolution consistera à étudier l’ajout d’une mémoire conversationnelle.
Elle pourrait permettre à FastInfo de conserver certains éléments pertinents du contexte afin d’améliorer les interactions sur plusieurs échanges.
Par exemple, l’assistant pourrait mieux comprendre une demande faisant référence à une information mentionnée précédemment dans la conversation.
Cette fonctionnalité devra néanmoins être conçue avec attention dans un environnement d’entreprise afin de prendre en compte la confidentialité, la conservation des données et les règles de sécurité.
La sécurité : un élément central
L’enjeu n’est cependant pas de donner accès à toutes les données à l’assistant.
FastInfo doit respecter les droits d’accès du collaborateur.
Un collaborateur ne doit pouvoir obtenir que les informations auxquelles il est autorisé à accéder.
Cette problématique devient particulièrement importante lorsque l’assistant est connecté à plusieurs sources internes contenant des données sensibles ou confidentielles.
Dans notre prototype, la gestion fine des droits d’accès constitue donc un élément qui devra être approfondi et validé avant une utilisation en environnement de production.
Un prototype avant tout
À ce stade, FastInfo reste un prototype.
Les premiers tests permettent déjà d’évaluer plusieurs capacités fondamentales :
- la compréhension des questions en langage naturel ;
- la recherche d’informations dans une base de connaissances ;
- la capacité à traiter différentes formulations ;
- la génération d’une réponse à partir des informations retrouvées ;
- le comportement de l’assistant lorsque l’information recherchée ne fait pas partie de sa connaissance.
Des tests complémentaires devront être réalisés afin d’évaluer :
- la pertinence des réponses ;
- la fiabilité des sources utilisées ;
- la capacité à comprendre différentes formulations ;
- la gestion de plusieurs langues ;
- le respect des droits d’accès ;
- la robustesse face aux questions ambiguës ;
- la gestion des informations inexistantes ;
- la satisfaction des collaborateurs ;
- la latence ;
- le coût d’utilisation ;
- et surtout, le gain de temps réel par rapport à une recherche classique.
L’objectif n’est pas de construire immédiatement un assistant capable de tout faire.
Il s’agit d’abord de tester les usages les plus utiles, mesurer leur valeur et améliorer progressivement la solution avec les collaborateurs.
C’est cette approche qui permettra à FutureBank de converger vers un assistant réellement utile au quotidien, plutôt qu’un simple chatbot.
Laisser un commentaire