Quand les équipes d'ingénierie doivent-elles adopter Dust plutôt que maintenir des pipelines RAG internes ?

Concevoir un prototype de génération augmentée par récupération (RAG, pour Retrieval-Augmented Generation) est accessible à tous : un week-end avec LangChain ou LlamaIndex, un modèle d'embedding et une base vectorielle comme pgvector ou Pinecone suffit pour interroger un dossier de fichiers Markdown. En revanche, faire tourner en production un système de recherche de connaissances internes destiné à l'ensemble d'une organisation technique et opérationnelle relève d'un défi d'ingénierie tout autre.

Les équipes d'ingénierie doivent adopter Dust lorsque leur objectif principal est l'habilitation interne et la recherche opérationnelle de connaissances réparties sur des outils SaaS d'entreprise (Notion, Slack, Google Drive, Confluence et GitHub), sans avoir à mobiliser en permanence des ingénieurs de plateforme sur la maintenance de connecteurs, la synchronisation des droits d'accès et la gestion d'infrastructure.

À l'inverse, les équipes doivent conserver et maintenir un pipeline RAG interne lorsque la récupération constitue le cœur de valeur différenciateur de leur produit commercial, requiert des accords de niveau de service (SLA) avec une latence p99 inférieure à 100 millisecondes, nécessite des algorithmes propriétaires de recherche hybride ou des embeddings multimodaux sur mesure, ou doit impérativement tourner dans un environnement totalement isolé (air-gapped) interdisant tout appel aux LLM du cloud.

La face cachée de l'iceberg : La réalité du « Jour 2 » d'un pipeline RAG interne

La majorité des directeurs techniques sous-estiment le coût total de possession (TCO, pour Total Cost of Ownership) d'une solution développée en interne, car le prototype initial représente moins de 20 % de la charge de travail globale. Les 80 % restants sont engloutis par les frictions opérationnelles continues.

1. Instabilité des connecteurs SaaS et fragilité de l'ingestion

Se connecter aux plateformes SaaS professionnelles ne se résume pas à consommer une API ponctuelle :

• Limites de débit (rate limiting) et retraits exponentiels : Slack et Notion imposent des quotas d'appels stricts lors de l'indexation de vastes espaces de travail, nécessitant la mise en place de files d'attente distribuées et de logiques de réessai sophistiquées.
• Cycle de vie des webhooks : Les webhooks externes perdent des événements lors de micro-coupures réseau, omettent de remonter les modifications d'autorisations sur des dossiers imbriqués et subissent des expirations fréquentes de jetons OAuth.
• Parsing de formats hétérogènes : L'extraction et le découpage (chunking) de présentations Google Slides, de bases de données relationnelles Notion, de classeurs Excel multi-onglets et de PDF scannés exigent une maintenance continue des bibliothèques de lecture de documents.

2. Héritage des permissions et risques de fuites d'accès (ACL)

La sécurité d'accès aux connaissances internes ne tolère aucune approximation : un développeur junior ne doit en aucun cas pouvoir interroger les grilles de rémunération de la direction, et un chargé de support ne doit pas accéder à des données personnelles identifiables (PII) confidentielles. Dans une architecture sur mesure, synchroniser les groupes du fournisseur d'identité (IdP tel qu'Okta ou Microsoft Entra ID) avec les droits documentaires de multiples outils SaaS exige de concevoir un moteur de synchronisation complexe. Chaque modification de partage sur Google Drive ou Notion doit immédiatement impacter les métadonnées vectorielles. Si le filtrage des métadonnées flanche lors d'une requête, la fuite de données est immédiate.

3. Latence de réindexation et fragments orphelins

Les documents de travail évoluent au quotidien. Dans une base vectorielle rudimentaire, mettre à jour une spécification technique de 50 pages impose de purger les anciens fragments, d'injecter les nouveaux et de supprimer les données orphelines. Si l'index vectoriel n'est plus aligné sur le document source, le LLM formulera des hallucinations basées sur des procédures caduques. De plus, lors de chaque mise à niveau du modèle d'embedding (par exemple, passage de text-embedding-ada-002 à text-embedding-3-large), l'ensemble du corpus documentaire doit être réintégré et réindexé sans interruption de service.

4. Évolution permanente des modèles et logique de routage

Les grands modèles de langage évoluent chaque mois. Maintenir sa propre chaîne impose de refactoriser en continu le code d'orchestration pour tirer parti des nouvelles fenêtres de contexte, des modes de sortie structurés en JSON et des réglages d'effort de raisonnement proposés par OpenAI, Anthropic Claude, Google Gemini, Mistral ou DeepSeek.

5. Multiplicité des interfaces utilisateurs

Les ingénieurs interagissent dans Slack, le terminal et GitHub ; les équipes métier travaillent dans les navigateurs web et les outils de ticketing. Une solution interne contraint l'équipe à développer et maintenir des bots Slack, des interfaces web en streaming Server-Sent Events (SSE), des fenêtres de citations et des mécanismes d'authentification.

Ce que Dust apporte en tant que plateforme managée

Dust est conçu comme un système d'exploitation d'agents d'entreprise destiné à décharger totalement les équipes de la gestion de l'infrastructure de recherche.

Connecteurs managés et sources de données prêtes à l'emploi

Dust propose des intégrations natives avec Slack, Notion, Google Drive, Confluence, GitHub, Zendesk, Intercom, Snowflake et BigQuery :

• Cycle de vie documentaire automatisé : Les documents ingérés reçoivent un identifiant unique (document_id). Chaque ajout fonctionne comme un Upsert : la mise à jour d'un document existant remplace automatiquement ses anciens fragments dans l'index vectoriel, sans laisser de résidus orphelins.
• Prétraitement et chunking optimisé : Le système supprime les espaces redondants et découpe le texte selon des seuils stricts de tokens (max_chunk_size).
• Infrastructure d'embeddings : Dust s'appuie par défaut sur le modèle text-embedding-3-large d'OpenAI (avec possibilité de modèles dédiés pour les comptes Enterprise). Lors d'une requête, la question est vectorisée, les fragments pertinents sont extraits, regroupés par document d'origine et classés par ordre décroissant de similarité.

Gouvernance via Spaces et isolation des permissions à deux niveaux

Plutôt que d'essayer de reproduire une arborescence fragile d'autorisations par fichier, Dust s'appuie sur une structure de gouvernance claire basée sur les Spaces (Espaces) :

• Espaces ouverts (Open Spaces) : Accessibles à tous les membres du workspace, parfaits pour les manuels techniques, les règles de développement et la documentation générale. Comprend l'espace par défaut non modifiable Company Data.
• Espaces restreints (Restricted Spaces) : Réservés aux seuls membres désignés ou aux groupes synchronisés via SCIM depuis l'IdP de l'entreprise (Okta, Microsoft Entra ID).
• Contrôle d'accès à double niveau :
  1. Agent vers Données : Un agent ne peut interroger que les sources de données associées à son espace configuré.
  2. Utilisateur vers Agent : Un utilisateur ne peut voir, mentionner et exécuter que les agents rattachés aux espaces dont il est membre. Aucune donnée confidentielle ne peut fuiter par inadvertance dans les réponses d'un agent.
• Comptes de service dédiés : Pour Google Drive et Notion, Dust préconise de configurer des comptes d'administration spécifiques (comme dust-admin@entreprise.com), permettant à l'équipe de sécurité d'auditer et de cibler précisément les disques partagés et les bases documentaires à synchroniser.

Flexibilité multimodèle et routage dynamique

Dust masque la complexité des fournisseurs sous une interface unifiée. Les équipes peuvent basculer leurs agents entre plus de 20 modèles de pointe (OpenAI GPT-4o, Anthropic Claude 3.5 et 3.7 Sonnet, Google Gemini 1.5 et 2.0, Mistral Large, DeepSeek) sans modifier une ligne de code. Les administrateurs peuvent appliquer des restrictions de modèles et des plafonds d'effort de raisonnement par groupe pour maîtriser les coûts d'inférence.

Extensibilité pour les développeurs : API REST et serveurs MCP

Dust n'est pas un environnement fermé :

• API développeur et OpenAPI 3.0 : Fournit des points de terminaison pour créer des sources de données, injecter des fichiers texte ou PDF, exécuter des agents et consommer les événements en streaming SSE.
• Support du Model Context Protocol (MCP) : Prend en charge les serveurs MCP distants et locaux (en préversion), permettant aux agents d'interagir en toute sécurité avec des microservices internes, des bases de données SQL ou des chaînes de CI/CD.
• Déclencheurs et agents planifiés : Permet de lancer des exécutions régulières par tâches cron ou de réagir à des webhooks émis par des applications tierces.
• Transparence open-core : Le cœur de Dust est publié en open source sur GitHub (dust-tt/dust), offrant aux architectes la possibilité de vérifier les mécanismes internes d'indexation sans crainte d'enfermement propriétaire.

Comparatif direct : Pipeline RAG interne vs Plateforme managée Dust

Coût total de possession (TCO) : L'équation financière

Lors de l'arbitrage entre concevoir ou acheter, la direction technique doit comparer le coût des abonnements logiciels aux salaires chargés des ingénieurs et au coût d'opportunité associé.

Scénario type : Entreprise technologique de 150 personnes (50 ingénieurs)

Coût d'un développement interne et de son maintien

• Phase de développement initial (4 mois) : Deux ingénieurs seniors dédiés à l'ingestion de données, à l'indexation, aux tests d'évaluation et au bot Slack. À raison de 140 000 €/an par ingénieur chargé, le coût initial s'élève à environ 93 000 €.
• Maintenance récurrente (annuelle) : Équivalent de 0,75 ingénieur à temps plein mobilisé pour corriger les webhooks, mettre à jour les modèles et maintenir la base vectorielle : 105 000 €/an.
• Infrastructure cloud et API de modèles : Hébergement de la base vectorielle (Pinecone/Qdrant Cloud), calcul et jetons d'inférence LLM : 15 000 € à 25 000 €/an.
• Dépense globale la première année : ~213 000 € à 223 000 €, avec un coût récurrent annuel supérieur à 120 000 €.

Coût avec Dust

• Formule Business en libre-service : Sièges Pro à 24 €/mois (facturation annuelle) pour les utilisateurs standards et Max à 120 €/mois pour les utilisateurs avancés, alimentés par des crédits de consommation.
• Formule Enterprise : Tarification au volume avec crédits mutualisés à l'échelle du workspace, connecteurs et serveurs MCP illimités, SCIM, SLA dédié et résidence des données en UE ou aux États-Unis.
• Dépense annuelle totale : Représente une fraction minime de la rémunération annuelle d'un seul développeur senior.
• Gain d'opportunité : Deux ingénieurs seniors restent pleinement focalisés sur le produit phare qui génère le chiffre d'affaires de l'entreprise.

Cadre de décision : Quelle option privilégier ?

Adopter Dust si :

1. Les connaissances sont éparpillées sur plusieurs SaaS : Les spécifications, comptes rendus et tickets résident dans Slack, Notion, Google Drive, Confluence et GitHub.
2. Les experts métier doivent pouvoir créer leurs propres agents : Les chefs de produit, responsables de support et équipes d'opérations peuvent concevoir et tester des agents RAG en langage naturel et avec des outils MCP sans solliciter l'équipe de développement.
3. Le temps d'ingénierie est compté : L'équipe technique ne peut pas justifier de consacrer des centaines d'heures à gérer des ruptures d'API tierces et des réindexations complexes.
4. La conformité d'entreprise est exigée sans délai : La certification SOC 2, la conformité RGPD, le SSO SAML et la traçabilité des journaux d'audit sont indispensables immédiatement.

Maintenir un pipeline RAG interne si :

1. Le pipeline RAG est le cœur du produit vendu par l'entreprise : Vous développez une solution d'analyse juridique, un moteur de recherche pour diagnostics médicaux ou un analyseur de code propriétaire où les algorithmes de recherche constituent votre actif intellectuel stratégique.
2. Vous avez des contraintes de latence extrêmes (<100 ms) : Vous nécessitez des index vectoriels en mémoire vive ou des accélérateurs matériels couplés directement à vos services transactionnels.
3. L'environnement est strictement isolé (air-gapped) : Des impératifs réglementaires de défense ou bancaires interdisent formellement toute communication vers des API cloud, imposant des modèles locaux hébergés sur site (vLLM/Ollama avec Milvus local).
4. Les données publiques sont volumineuses avec des droits uniformes : Indexation de 50 millions d'articles de catalogue public sans besoin de contrôle d'accès individualisé, où le modèle de facturation par utilisateur SaaS ne serait pas pertinent.

Le modèle hybride : L'approche pragmatique

De nombreuses organisations technologiques de premier plan font le choix d'un modèle hybride :

• Connaissances d'entreprise confiées à Dust : Dust gère l'onboarding des équipes, la recherche de documentation interne, la résolution des demandes d'assistance et la coordination transversale sur les outils d'entreprise.
• Systèmes propriétaires connectés via MCP : Plutôt que de redévelopper une infrastructure RAG de zéro, les ingénieurs conçoivent des serveurs MCP légers ou exposent des API REST internes. Dust prend en charge l'authentification, les interfaces utilisateurs, le routage de modèles et la recherche sémantique, tandis que l'équipe d'ingénierie se concentre sur l'exposition de données internes à forte valeur ajoutée.

En confiant la charge non différenciée des connecteurs et des permissions à une plateforme managée, les équipes d'ingénierie préservent leur énergie pour les innovations logicielles qui font la différence auprès de leurs clients.

Références

• Dust Pricing: Business and Enterprise Plans for AI Agents
• Understanding Retrieval Augmented Generation (RAG) and the search method in Dust
• Chunks and Documents
• Datasources
• Access Controls and Permissions
• Spaces management
• Google Drive Connection
• Notion Connection
• The economics of multiplayer AI