Comment connecter un LLM aux données internes d’une entreprise sans tout réindexer

La question est presque toujours mal posée

« Comment on met nos données dans l’IA ? » suppose que le modèle doit posséder la donnée. Il n’en a pas besoin. Un LLM a besoin, au moment où il répond, du bon extrait au bon format, pas d’une copie de votre système d’information.

Cette nuance change tout. Posséder la donnée implique de la copier, de la synchroniser, de rejouer vos règles de permissions dans un second système et d’assumer un décalage permanent avec la source. Y accéder au moment utile n’implique rien de tout cela.

La bonne question est donc : pour chaque type d’information dont le modèle a besoin, existe-t-il déjà un moyen de l’obtenir ? Dans une entreprise qui tourne depuis quelques années, la réponse est oui plus souvent qu’on ne l’imagine.

Trois façons de donner accès à vos données

1. Appel d’outil sur vos APIs existantes

Le modèle appelle une fonction que vous exposez : « chercher un client », « lister les commandes du mois », « lire la fiche produit X ». C’est votre backend qui répond, avec vos règles métier et vos permissions. Aucune copie, aucune latence de synchronisation, et une donnée exacte plutôt qu’approchée.

2. La recherche que vous avez déjà

Un moteur full-text, un index Elasticsearch, la recherche de votre GED ou de votre wiki : si elle donne des résultats corrects à un humain, elle en donne au modèle. On l’expose comme un outil, et on laisse le modèle formuler la requête puis lire les résultats.

3. Un index vectoriel (RAG)

Utile quand l’information est enfermée dans du texte non structuré (PDF, comptes rendus, contrats, documentation) et qu’aucune recherche existante ne la retrouve correctement. C’est la seule option qui implique d’indexer, donc de synchroniser, donc de maintenir.

Ces options se combinent. Un assistant utile en entreprise interroge en général une ou deux APIs métier et un seul index documentaire, pas une base vectorielle contenant tout le patrimoine informationnel.

Quand l’index vectoriel est vraiment nécessaire

Trois conditions doivent être réunies simultanément. Si une seule manque, il existe presque toujours une solution plus simple.

1. L’information n’existe que dans du texte libre : elle n’est ni dans une base, ni exposée par une API.
2. La question posée ne se traduit pas en filtre. « Quelles commandes dépassent 10 000 € ? » est une requête, pas une recherche sémantique.
3. Le vocabulaire des utilisateurs diffère de celui des documents. C’est précisément ce que la recherche vectorielle apporte sur la recherche par mots-clés.

Le test qui tranche : si un collègue trouverait la réponse en trente secondes avec la barre de recherche existante, un index vectoriel ne résout aucun problème. Il en crée un : celui de le maintenir.

Les droits d’accès décident de l’architecture

C’est le point sur lequel les projets échouent le plus tard, donc le plus cher. Vos documents ne sont pas tous lisibles par tout le monde. Un index vectoriel, lui, est plat par nature : il ne connaît ni rôles, ni services, ni exceptions.

Il faut donc décider, avant d’indexer quoi que ce soit, comment les permissions voyagent avec la donnée :

• Filtrage à la récupération : chaque fragment porte les identifiants qui ont le droit de le lire, et la requête filtre dessus. C’est la seule approche qui tienne à l’échelle.
• Index cloisonnés : un index par périmètre de confidentialité. Simple, mais ingérable dès que les périmètres se recoupent.
• Filtrage après génération : on laisse le modèle répondre puis on masque. À proscrire : l’information a déjà fuité dans la réponse.

L’option « appel d’outil » évite entièrement le sujet : c’est votre application qui répond, donc c’est votre modèle d’autorisation qui s’applique, celui que vous maintenez déjà.

La fraîcheur est le coût caché

Un index n’est jamais à jour : il est à jour au dernier passage. Tant que le contenu est de la documentation qui bouge tous les trimestres, personne ne s’en aperçoit. Dès qu’il s’agit de stocks, de tarifs, de disponibilités ou de statuts de commande, le décalage devient une réponse fausse donnée avec assurance.

La règle pratique : plus une donnée change vite, plus elle doit être lue en direct plutôt qu’indexée. Les données transactionnelles passent par l’appel d’outil, les contenus stables peuvent être indexés.

Une architecture de référence

Ce découpage couvre la grande majorité des cas d’usage internes, et il se met en place progressivement.

1. Une couche d’outils exposée au modèle, définie par des contrats explicites : nom, paramètres, format de retour, erreurs possibles.
2. Ces outils appellent vos services existants, avec l’identité de l’utilisateur courant. Jamais la base de données en direct.
3. Un index vectoriel séparé, alimenté uniquement par les contenus non structurés qui le justifient, avec les permissions attachées à chaque fragment.
4. Une étape de composition qui assemble le contexte, cite ses sources, et sait dire qu’elle n’a rien trouvé.
5. De la journalisation : quelle question, quels outils appelés, quels fragments utilisés, quel coût. Sans cela, on ne peut ni améliorer, ni auditer.

Les erreurs qu’on retrouve systématiquement

• Tout indexer « pour voir » : on obtient un index énorme, coûteux, dont personne ne sait ce qu’il contient ni qui a le droit de le lire.
• Donner au modèle un accès direct à la base : on court-circuite dix ans de règles métier écrites dans la couche applicative.
• Traiter les permissions en dernier : c’est la principale cause d’un projet qui ne passe jamais en production.
• Oublier le cas « je ne sais pas ». Un assistant qui invente parce qu’il n’a rien trouvé est pire qu’une recherche vide.
• Ne mesurer que la satisfaction. Sans jeu de questions de référence, on ne sait pas si une modification améliore ou dégrade les réponses.

Par où commencer concrètement

Prenez une seule question que des collègues posent chaque semaine, et suivez le chemin de la donnée : où est-elle, qui a le droit de la voir, à quelle vitesse change-t-elle, existe-t-il déjà un moyen de l’obtenir. Vous saurez alors laquelle des trois options s’applique, et vous aurez une réponse fiable en quelques jours plutôt qu’un chantier d’indexation de plusieurs mois.