Onyx : une solution sérieuse pour déployer du RAG en entreprise ?

Onyx, le RAG en entreprise passe un cap

Le sujet du RAG en entreprise revient de plus en plus dans les comités de direction. Et c’est logique. Les collaborateurs utilisent déjà l’IA pour écrire, résumer, comparer ou produire des idées. Mais dès qu’ils veulent interroger les vraies données internes, les choses se compliquent.

Où est la bonne procédure ? Quelle version du contrat fait foi ? Quel ticket Jira explique cette décision ? Quelle note commerciale parle de ce client ? Quel document SharePoint répond vraiment à la question ?

C’est précisément là que le RAG prend de la valeur.

Le RAG, pour Retrieval-Augmented Generation, permet à un assistant IA de chercher dans les documents de l’entreprise avant de répondre. Au lieu de se baser seulement sur sa connaissance générale, le modèle s’appuie sur des sources internes. Il peut donc produire une réponse plus utile, plus contextualisée et plus facile à vérifier.

Pour une DSI, le sujet n’est pas seulement technique. Il touche à la sécurité, aux droits d’accès, à la qualité de la donnée, à l’expérience utilisateur, au coût des modèles, à la supervision et à la conduite du changement.

Dans ce paysage, Onyx mérite clairement d’être regardé.

Onyx se présente comme un chat IA open source connecté aux documents, applications et personnes de l’entreprise. La plateforme met en avant des fonctions de RAG avancé, de recherche hybride, de recherche contextuelle, de connecteurs métiers et de contrôle des accès.

Dit plus simplement : Onyx veut devenir l’interface IA interne qui permet aux équipes de retrouver, comprendre et exploiter la connaissance dispersée dans les outils de l’entreprise.

Pourquoi les DSI s’intéressent au RAG en entreprise

Le problème de départ est rarement “nous avons besoin d’un chatbot”.

Le vrai problème ressemble plutôt à ceci : l’information existe, mais elle est éparpillée partout.

Elle est dans Google Drive, SharePoint, Confluence, Notion, Slack, Jira, GitHub, Salesforce, HubSpot, Gmail, les tickets support, les PDF, les notes de réunion ou les bases de connaissance métier. Les équipes passent donc trop de temps à chercher. Elles sollicitent toujours les mêmes experts. Elles recréent parfois des documents qui existent déjà. Et elles prennent des décisions avec une vue partielle de l’information.

Le RAG en entreprise répond à ce problème en ajoutant une couche intelligente entre les utilisateurs et les données internes.

Un collaborateur ne cherche plus seulement par mot-clé. Il pose une question en langage naturel. Le système identifie les sources pertinentes, extrait les passages utiles, puis demande au LLM de formuler une réponse claire. Quand le système est bien conçu, la réponse cite ses sources et respecte les droits de l’utilisateur.

C’est ce dernier point qui change tout pour une DSI.

Un RAG de démonstration peut fonctionner avec dix PDF déposés dans une interface. Un RAG en entreprise doit fonctionner avec des droits, des groupes, des documents sensibles, des sources qui changent, des doublons, des versions contradictoires et des utilisateurs qui n’ont pas tous accès aux mêmes informations.

C’est là que la différence se fait entre un simple prototype IA et une vraie architecture RAG.

Pour approfondir ce sujet, Scroll a publié un guide complet sur le RAG en entreprise, avec les enjeux d’architecture, de coûts, de conformité et de cadrage.

Onyx, c’est quoi exactement ?

Onyx est une plateforme IA open source pensée pour connecter les LLM aux connaissances internes d’une organisation. Son objectif est de proposer une interface unique pour discuter avec l’IA, rechercher dans les données de l’entreprise, lancer des recherches approfondies et créer des agents adaptés à certains usages métier.

Sur son dépôt GitHub, Onyx décrit la plateforme comme une couche applicative pour LLM. Elle inclut des capacités comme le RAG, la recherche web, l’exécution de code, la création de fichiers, la recherche approfondie et les agents personnalisés.

C’est important, car Onyx n’est pas seulement une interface de chat. C’est aussi une couche de recherche et d’orchestration. Pour un DSI, cela veut dire que l’outil peut s’inscrire dans une stratégie plus large d’IA en entreprise.

La plateforme propose notamment :

Une interface de chat IA pour les utilisateurs internes.

Des connecteurs vers les outils de l’entreprise.

Une couche de recherche documentaire et de RAG.

Des options de déploiement self-hosted.

Des contrôles d’accès sur les sources.

La possibilité de connecter différents modèles LLM.

Des agents avec actions et intégrations MCP.

Onyx indique aussi que sa Community Edition est disponible sous licence MIT et couvre les fonctionnalités clés de chat, RAG, agents et actions. L’Enterprise Edition ajoute des fonctions plutôt destinées aux grandes organisations.

Pour une DSI, le point fort est donc clair : Onyx permet de démarrer avec une base open source tout en gardant une trajectoire possible vers des usages plus avancés.

Ce qu’Onyx apporte au RAG en entreprise

La promesse d’Onyx repose sur un point simple : connecter l’IA aux outils que les équipes utilisent déjà.

Onyx ne demande pas seulement d’importer des fichiers à la main. La documentation mentionne des connecteurs conçus pour créer un pont entre les sources de données de l’organisation et les fonctions d’IA générative de la plateforme. Ces connecteurs peuvent synchroniser les changements depuis les sources.

C’est un point majeur pour le RAG en entreprise. Une base documentaire n’est jamais figée. Les procédures changent. Les pages Confluence évoluent. Les tickets Jira se ferment. Les dossiers SharePoint sont déplacés. Les documents commerciaux sont mis à jour. Un bon système RAG doit donc suivre cette réalité.

Onyx liste des connecteurs pour des outils comme Confluence, SharePoint, Notion, Google Drive, Jira, Zendesk, Airtable, Slack, Microsoft Teams, Gmail, Salesforce, HubSpot, Gong, GitHub, GitLab, Bitbucket et d’autres sources.

Cela place Onyx sur un terrain très concret pour les DSI : la donnée n’est pas seulement dans un dossier documentaire propre. Elle vit dans les applications métiers.

C’est souvent la grande limite des premiers projets IA. L’équipe teste un assistant sur un corpus propre. Le résultat est bon. Puis elle essaie de passer à l’échelle et découvre que la connaissance utile est fragmentée dans dix outils. Sans connecteurs, sans stratégie d’indexation et sans gestion des droits, le projet reste bloqué au stade du POC.

Onyx répond en partie à ce problème avec une approche orientée connecteurs, recherche et contrôle.

Le sujet clé : les permissions

Pour un DSI, le RAG n’est pas seulement une question de pertinence. C’est aussi une question d’accès.

Un assistant IA connecté aux données internes peut devenir très utile. Mais il peut aussi devenir risqué s’il révèle une information à la mauvaise personne.

Un commercial ne doit pas forcément lire tous les documents RH. Un collaborateur ne doit pas accéder à un dossier juridique sensible. Un manager ne doit pas voir des données qui relèvent d’une autre entité. Et un assistant IA ne doit jamais devenir un raccourci pour contourner les permissions existantes.

Onyx met en avant une logique “permission-aware”. Sa documentation indique que certains connecteurs peuvent synchroniser les permissions depuis les sources, afin que les utilisateurs ne voient que les données auxquelles ils ont accès. Cette synchronisation est disponible notamment pour Confluence, Jira, Google Drive, Gmail, Slack, Salesforce, GitHub et SharePoint, avec des conditions selon les connecteurs.

C’est un vrai sujet d’architecture. La recherche sémantique seule ne suffit pas. Un résultat peut être pertinent, mais interdit. Le système doit donc filtrer la donnée avant ou pendant la récupération des documents.

C’est aussi une raison pour laquelle un projet RAG en entreprise doit être cadré avec la DSI dès le départ. Les permissions ne se “rajoutent” pas proprement à la fin. Elles doivent guider le choix des sources, des connecteurs, des comptes de service, des groupes utilisateurs, des logs et des règles de refus.

Onyx vs OpenWebUI : deux visions proches, mais pas le même usage

OpenWebUI est souvent cité dans les discussions sur l’IA self-hosted. Et à juste titre.

OpenWebUI est une interface IA auto-hébergée, orientée usage local ou souverain, qui permet de connecter des modèles comme Ollama, OpenAI-compatible API, Anthropic, vLLM et d’autres fournisseurs. Sa documentation met en avant le RAG, les bases vectorielles, la recherche hybride et plusieurs moteurs d’extraction documentaire.

Dans un article dédié, Scroll présente OpenWebUI comme une interface self-hosted qui apporte une expérience proche de ChatGPT, mais sur ses propres modèles et sa propre infrastructure : lire l’article sur OpenWebUI.

La comparaison avec Onyx est intéressante, car les deux outils parlent à des organisations qui veulent reprendre le contrôle de leur IA. Mais ils ne partent pas du même centre de gravité.

OpenWebUI est excellent pour proposer une interface IA self-hosted, tester des modèles, brancher Ollama, centraliser plusieurs fournisseurs LLM et donner aux équipes une expérience de chat interne.

Onyx semble plus orienté “recherche d’entreprise” et RAG connecté aux sources métier. Son intérêt est plus fort quand la priorité est de brancher l’IA aux données internes, avec des connecteurs, des droits et une logique de recherche documentaire plus structurée.

Le choix dépend donc de l’objectif.

Si votre enjeu principal est de donner une interface simple à vos équipes pour utiliser des modèles locaux ou des API LLM, OpenWebUI peut être très pertinent.

Si votre enjeu principal est de créer un assistant IA connecté aux données internes, avec recherche dans les outils métier, synchronisation et gestion des permissions, Onyx mérite une étude plus poussée.

Dans beaucoup d’entreprises, la vraie question n’est pas “Onyx ou OpenWebUI ?”. La vraie question est : quel niveau de RAG voulons-nous déployer, pour quels utilisateurs, avec quelles données, et sous quel niveau de contrôle ?

Les cas d’usage Onyx les plus crédibles pour une DSI

Le premier cas d’usage est le moteur de recherche interne augmenté. C’est souvent le plus simple à comprendre. Les collaborateurs posent une question et Onyx cherche dans les sources connectées. Pour une DSI, ce cas permet de mesurer vite la valeur : temps gagné, baisse des sollicitations aux experts, meilleure réutilisation de la connaissance.

Le deuxième cas est l’assistant support. Dans une équipe support, la connaissance utile se trouve dans les tickets passés, les bases de connaissance, les fiches produit, les procédures d’escalade et les conversations internes. Un RAG en entreprise bien conçu peut suggérer une réponse, citer les sources et aider l’agent à traiter plus vite une demande.

Le troisième cas est l’assistant IT. Les équipes internes peuvent interroger la documentation technique, les procédures de sécurité, les runbooks, les tickets Jira, les dépôts GitHub ou GitLab, et les historiques d’incidents. Pour une DSI, c’est un terrain naturel, car la donnée technique est souvent riche mais difficile à parcourir.

Le quatrième cas est l’assistant commercial. Les équipes sales cherchent souvent des argumentaires, des cas clients, des réponses à objections, des fiches offres ou des éléments de proposition. Un assistant IA connecté aux données internes peut réduire le temps de préparation et homogénéiser les réponses.

Le cinquième cas est l’onboarding. Un nouveau collaborateur peut poser ses questions à un assistant relié aux documents internes validés. Cela réduit la charge sur les managers et accélère la montée en compétence.

Ces usages sont proches de ceux que Scroll détaille dans son approche des assistants IA connectés à vos données. L’enjeu n’est pas seulement de “faire un chatbot”. L’enjeu est de construire un assistant utile, sourcé, contrôlé et mesurable.

Les points de vigilance avant de choisir Onyx

Onyx est une option intéressante, mais ce n’est pas une baguette magique.

Le premier point à regarder est la qualité documentaire. Si les documents sont vieux, contradictoires ou mal nommés, le RAG produira des réponses moyennes. Un assistant IA ne sait pas deviner quel document fait foi si l’entreprise elle-même ne le sait pas.

Le deuxième point est la stratégie de connecteurs. Connecter toutes les sources dès le début est tentant, mais rarement utile. Mieux vaut partir d’un périmètre clair : une équipe, un corpus, un usage, quelques sources bien choisies. C’est plus facile à évaluer et plus simple à sécuriser.

Le troisième point est la gestion des droits. Il faut vérifier comment les permissions sont synchronisées, quelles sources supportent cette synchronisation, quels comptes de service sont utilisés, quels groupes sont créés et quels logs sont disponibles.

Le quatrième point est le choix des modèles. Onyx est compatible avec plusieurs approches, mais le choix du LLM reste structurant. Un modèle propriétaire peut offrir une très bonne qualité. Un modèle open source self-hosted peut mieux répondre à des contraintes de souveraineté. Une DSI doit arbitrer sur des critères concrets : qualité des réponses, coût par requête, latence, confidentialité, supervision et maintenabilité.

Le cinquième point est l’évaluation. Un RAG en entreprise ne se juge pas avec une démo. Il se juge avec un jeu de questions réelles, des réponses attendues, des sources validées et des utilisateurs métier. Scroll recommande souvent de benchmarker plusieurs modèles et plusieurs réglages sur le corpus réel, avec des métriques comme le taux de bonnes réponses, les sources citées, les hallucinations, le coût par requête et les retours utilisateurs. Cette approche fait partie de la méthode IA présentée sur la page Scroll dédiée aux assistants connectés aux données.

Architecture type avec Onyx

Une architecture Onyx pour le RAG en entreprise peut rester assez lisible.

Au centre, Onyx joue le rôle d’interface et de couche de recherche. Il se connecte aux sources internes grâce aux connecteurs. Les documents sont indexés, découpés, enrichis et stockés pour permettre la recherche sémantique ou hybride. Quand un utilisateur pose une question, Onyx récupère les passages utiles, vérifie les droits, puis transmet le contexte au modèle LLM.

Autour de cette base, la DSI doit cadrer plusieurs briques.

L’identité et les accès : SSO, groupes, rôles, permissions par source.

Les sources : SharePoint, Drive, Confluence, Jira, Slack, GitHub, CRM, bases documentaires.

Les modèles : OpenAI, Anthropic, Mistral, modèles open source via Ollama ou vLLM selon la stratégie.

L’infrastructure : cloud managé, self-hosted, réseau interne, Kubernetes ou Docker selon le contexte.

La sécurité : logs, audit, règles de refus, filtrage des données sensibles, politique de conservation.

L’évaluation : jeu de tests, revue humaine, mesure des hallucinations, suivi de la satisfaction.

Le support : documentation, formation, gouvernance, processus de remontée des erreurs.

Ce schéma paraît simple. En pratique, la difficulté est dans les détails : droits hérités, doublons, fichiers obsolètes, documents confidentiels, prompts trop larges, coûts tokens, latence, adoption utilisateur.

C’est pour cela qu’un projet RAG en entreprise doit être traité comme un projet SI, pas comme une expérimentation isolée dans un coin.

Quand Onyx est un bon choix

Onyx est probablement un bon candidat si votre entreprise coche plusieurs cases.

Vous avez beaucoup de connaissance dispersée dans des outils internes. Vous voulez une recherche plus intelligente que la recherche classique par mots-clés. Vous avez besoin d’un assistant IA connecté aux données internes. Vous voulez garder une option open source. Vous avez des exigences de sécurité et de gestion des droits. Vous voulez connecter plusieurs modèles LLM. Vous cherchez une plateforme plus structurée qu’un simple chat IA.

Pour une DSI, Onyx peut aussi être intéressant si l’objectif est de créer une “porte d’entrée IA” officielle dans l’entreprise.

C’est un enjeu de gouvernance. Si les équipes utilisent chacune leur propre outil IA, les données partent dans tous les sens. Les pratiques deviennent difficiles à contrôler. Les coûts sont flous. Les risques de confidentialité augmentent.

Une plateforme interne comme Onyx peut aider à canaliser les usages. Elle ne règle pas tout, mais elle donne un cadre : une interface, des sources connues, des modèles maîtrisés, des règles d’accès et des métriques.

Quand Onyx n’est pas forcément le bon choix

Onyx n’est pas toujours nécessaire.

Si vous voulez simplement tester un modèle local sur un poste de travail, OpenWebUI sera souvent plus simple.

Si votre besoin est une automatisation métier structurée, par exemple remplir un CRM, relancer un client ou router un ticket, un workflow n8n ou une application métier sera parfois plus adapté qu’un RAG.

Si vos données sont très mal rangées, non fiables ou obsolètes, le premier chantier n’est pas Onyx. Le premier chantier est la gouvernance documentaire.

Si vous avez seulement besoin d’un chatbot marketing ou d’une FAQ publique, une solution plus légère peut suffire.

Enfin, si votre besoin demande des garanties absolues, par exemple dans un contexte juridique, médical, financier ou réglementaire, le RAG doit rester assisté par des contrôles humains et des règles strictes. Il peut aider à retrouver et synthétiser l’information. Il ne remplace pas une validation critique.

Comment cadrer un POC Onyx sans perdre du temps

Un bon POC Onyx doit être court, mais sérieux.

Le piège classique consiste à connecter trop de sources et à tester des questions trop vagues. Le résultat devient difficile à interpréter. On ne sait plus si le problème vient du modèle, du corpus, du connecteur, du prompt, des droits ou de la question posée.

Un POC utile part d’un cas précis.

Par exemple : “permettre à l’équipe support de retrouver les procédures et tickets liés aux incidents clients de niveau 2”.

À partir de là, on choisit trois ou quatre sources. On définit les groupes utilisateurs. On prépare une cinquantaine de questions réelles. On fixe les critères de succès. On mesure la qualité des réponses, la pertinence des sources, le temps gagné, les erreurs et les limites.

Le but n’est pas de prouver que l’IA est impressionnante. Le but est de savoir si le RAG en entreprise apporte une valeur mesurable dans un contexte réel.

Chez Scroll, ce type de démarche passe souvent par un cadrage court, puis un POC centré sur un cas d’usage core. La méthode présentée sur la page IA Scroll parle d’un projet en plusieurs temps : cadrage, choix du modèle, POC, évaluation, puis industrialisation si les critères sont atteints.

C’est exactement l’approche à adopter avec Onyx.

Ce qu’un DSI doit retenir avant de lancer Onyx

Onyx arrive au bon moment. Les entreprises veulent utiliser l’IA, mais elles veulent aussi garder le contrôle sur leurs données, leurs droits, leurs modèles et leurs coûts. Le RAG en entreprise est une réponse sérieuse à ce besoin, à condition de ne pas le réduire à une simple démo de chatbot.

Pour une DSI, Onyx est intéressant parce qu’il combine plusieurs briques clés : interface IA, recherche documentaire, connecteurs, RAG, agents, options self-hosted et gestion des permissions. C’est exactement le type de socle qui peut aider une organisation à passer de l’expérimentation IA à un usage interne plus structuré.

Mais la réussite ne dépend pas seulement de l’outil.

Elle dépend du cadrage, du choix des sources, de la qualité documentaire, des permissions, de l’évaluation et de l’adoption par les équipes. Un mauvais corpus donnera un mauvais assistant. Des droits mal gérés créeront un risque. Un POC trop large donnera des résultats flous.

La bonne approche est donc progressive : un cas d’usage, un corpus, des questions réelles, une mesure claire, puis une industrialisation si les résultats sont bons.

Chez Scroll, nous aidons les entreprises à cadrer et déployer des assistants IA connectés à leurs données internes, avec une attention forte sur la sécurité, la fiabilité, les coûts et la mise en production. Onyx peut faire partie des options à étudier, au même titre qu’OpenWebUI, LlamaIndex, LangChain, pgvector, Qdrant, Supabase, n8n ou une architecture sur mesure.

L’objectif n’est pas de choisir l’outil le plus à la mode. L’objectif est de construire un système IA utile, contrôlé et maintenable, qui s’intègre vraiment dans le SI.