Krok présente l'assistant RAG interne qu'elle a construit pour ses données d'entreprise

Krok a expliqué comment elle a construit un assistant RAG interne pour exploiter les connaissances de l'entreprise en environnement fermé. Plutôt qu'un « chat pour le chat », la société a conçu un outil qui réduit le temps nécessaire pour retrouver les bons passages dans les documents, les wikis et les portails internes.

Pourquoi le choix du RAG

L'équipe est partie d'un constat simple : la recherche intégrée existe, en théorie, dans presque tous les grands systèmes d'entreprise, mais elle ne simplifie pas la vie des employés. L'information est dispersée entre plusieurs espaces de stockage, chacun avec ses règles, sa structure et sa logique de résultats. Résultat : les gens se souviennent du sens d'un document, mais pas de sa formulation exacte, du nom du fichier ni de son emplacement. La recherche classique repose sur la correspondance de mots plutôt que sur le contexte, et c'est là qu'elle perd pied.

Le scénario direct avec GPT et téléversement de documents a aussi été testé, mais il ne convenait pas aux gros volumes de données. Plusieurs limites se sont cumulées : la fenêtre de contexte, l'instabilité des réponses et le risque d'exposer des documents sensibles hors du périmètre de l'entreprise. Krok a donc retenu une approche RAG : d'abord trouver les fragments pertinents dans les sources internes, puis seulement les transmettre au modèle de langage pour composer la réponse.

«

Nous n'avions pas besoin d'IA par effet de mode, mais d'un assistant d'entreprise maîtrisable. »

Le RAG a été retenu dans ce projet pour quatre raisons pratiques :

• les documents restent à l'intérieur de l'infrastructure de l'entreprise ;
• le modèle ne reçoit que le contexte utile, et non l'ensemble des données ;
• l'indexation et la restitution peuvent être contrôlées séparément ;
• le risque d'hallucinations est plus faible, car la réponse s'appuie sur de vraies sources.

Comment le système est conçu

La solution repose sur deux circuits distincts. Le premier gère la création des assistants : via la messagerie d'entreprise ou une interface web pilote, l'utilisateur ajoute des fichiers, des liens vers le portail ou des espaces de la base de connaissances. Le système de gestion des assistants vérifie ensuite les droits d'accès, lance les parseurs nécessaires, prépare les données et ne les envoie qu'ensuite au cœur RAG pour indexation. Lorsque l'index est prêt, l'employé reçoit une notification et peut démarrer la conversation.

Le second circuit est celui du dialogue. La requête de l'utilisateur transite par le bus d'entreprise dédié aux LLM, et le moteur RAG sélectionne en amont le contexte pertinent. Les droits d'accès sont vérifiés non pas une seule fois lors du chargement, mais à chaque appel à l'assistant. En raison de la complexité des ACL selon les systèmes, l'équipe a renoncé aux assistants partagés dans certains scénarios pour passer à des assistants personnels. C'est moins pratique, mais cela réduit le risque qu'un employé voie des données auxquelles il n'a pas droit.

Il a aussi fallu développer des connecteurs et un prétraitement pour presque chaque type de source. Le portail d'entreprise, la base de connaissances, les fichiers personnels et les pages wiki étaient trop différents pour être confiés « tels quels » à un seul cœur RAG. Le nettoyage, la normalisation et la préparation des données ont donc été confiés à des services distincts.

Comme point d'entrée principal, l'équipe a choisi une messagerie interne basée sur Express : Telegram semblait pratique au départ, mais pour des informations sensibles, un service externe a été écarté d'emblée.

Où les problèmes sont apparus

Les difficultés les plus pénibles ne se situaient pas dans l'interface, mais dans les données et les processus. Les wikis au balisage complexe ont exigé beaucoup de nettoyage manuel. Les tableaux et les données chiffrées produisaient des réponses instables. Les PDF avec scans et graphiques faisaient échouer le parsing de base. Le modèle comprenait moins bien les structures visuelles, comme les organigrammes, que le texte, et pouvait confondre les liens entre services et responsables. En outre, les utilisateurs attendaient du RAG une recherche exhaustive sur toutes les occurrences, alors que cette approche classe plutôt le contexte le plus probable qu'elle ne garantit une liste complète.

Le travail avec l'éditeur n'a pas été moins douloureux. Krok a testé plusieurs plateformes sur ses propres jeux de documents et des questions types, puis a passé près d'un an à améliorer la solution avec le fournisseur. Les mises à jour ont posé problème, car elles pouvaient modifier brutalement la qualité des réponses : une version a fait chuter une métrique de 85 % à 70 %. Faute de transparence sur le lien entre le RAG et le LLM intégré, l'équipe a demandé une interface distincte entre les deux afin de choisir elle-même le modèle et de piloter la suite du traitement du contexte.

Pour contrôler la qualité, elle a mis en place des benchmarks, des questions de référence, des vérifications régulières et même un LLM distinct faisant office de juge, qui compare la réponse réelle à la réponse attendue.

Ce que cela signifie

Le cas de Krok montre que l'IA d'entreprise consiste aujourd'hui moins à choisir un modèle qu'à faire de l'ingénierie autour des données, des accès et des tests. Le RAG seul ne résout rien sans connecteurs, isolation des collections, contrôle des ACL et métriques de qualité claires. Mais si tout cela est réuni dans un même système, un assistant interne peut effectivement supprimer des heures de recherche routinière et accélérer sensiblement le travail avec les connaissances de l'entreprise.