SharePoint dans Dust vs Outlook dans Dust : quoi et quoi connecter en gardant le contrôle sur ses agents IA

(cet article a été rédigé avec l'aide de mon agent IA dans Dust, vous le savez quand vous voyez ce type de tiret "—")

Quand un cabinet d'avocats nous a contactés pour déployer Dust en tant qu'environnement d'agents IA, la demande semblait claire : connecter leur écosystème Microsoft — SharePoint pour la base documentaire, Outlook pour les e-mails. Deux outils. Une même plateforme source. Une intégration qui allait de soi.

Elle ne l'était pas.

Nous avons découvert que SharePoint et Outlook n'obéissent pas du tout à la même logique dans Dust. Et cette différence, si on ne la comprend pas dès le départ, crée des surprises désagréables : des accès involontairement trop larges, des connexions fantômes après un départ de collaborateur, et des questions de conformité qui méritent une réponse claire avant de cliquer sur "Connecter".

Connection vs Tool : deux mécanismes radicalement différents

Dans Dust, tout part d'une distinction fondamentale que la documentation évoque mais que la pratique terrain rend vraiment concrète.

Une Connection (ou data source connectée) est une intégration qui indexe du contenu. Dust va parcourir la source, extraire les documents, les stocker sous forme vectorisée, et les rendre disponibles pour les agents sous forme de base de connaissance interrogeable. SharePoint fonctionne ainsi : les fichiers sont lus, découpés, indexés. Ils deviennent du contexte que l'agent peut mobiliser sans avoir besoin d'accéder à SharePoint en temps réel lors de chaque conversation.

Un Tool (outil), c'est une tout autre logique. Il n'y a pas d'indexation en amont. L'outil agit à la demande, en temps réel, avec les credentials de l'utilisateur connecté au moment où il l'utilise. Outlook fonctionne ainsi : quand un agent lit ou prépare un e-mail, il le fait à l'instant T, sous l'identité de la personne, avec ses propres droits d'accès.Ce n'est pas une nuance cosmétique. C'est une différence architecturale qui change tout : la gouvernance, les droits, les risques, et la configuration côté Microsoft Entra.

L'Admin Entra : un consentement unique, une responsabilité collective

Pour que Dust puisse se connecter à Microsoft 365, il faut passer par Microsoft Entra (anciennement Azure Active Directory). Et là, deux chemins distincts selon qu'on parle de SharePoint ou d'Outlook.

Pour SharePoint, le consentement est dit "organisationnel" : c'est l'administrateur IT du cabinet qui donne l'autorisation une seule fois pour l'ensemble du tenant. Une fois ce consentement accordé, Dust peut accéder à SharePoint avec les scopes définis, typiquement Files.Read.All. L'administrateur est le garant de ce périmètre. Les collaborateurs n'ont rien à faire côté Microsoft — ils bénéficient de la connexion configurée par leur IT.

Pour Outlook, c'est différent : chaque utilisateur doit se connecter lui-même dans Dust avec son propre compte Microsoft. Les scopes mobilisés sont Mail.Read, Mail.ReadWrite, Mail.ReadWrite.Shared et offline_access. L'admin peut avoir pré-autorisé l'application dans Entra, mais c'est bien l'utilisateur final qui initie sa connexion personnelle dans l'interface Dust. Il n'y a pas de délégation "silencieuse" : si un collaborateur ne se connecte pas, il n'a pas accès à l'outil e-mail.Ce modèle a du sens. Il protège la vie privée. Mais il introduit une gestion individuelle que l'on sous-estime souvent en phase de déploiement.

La "connexion orpheline" : le cas que personne ne vous dit

C'est la découverte qui nous a le plus interpellés lors du déploiement.

Quand un collaborateur quitte le cabinet, l'admin révoque son accès dans Azure Entra. Jusque là, tout est normal. Mais cette révocation ne désactive pas automatiquement la connexion dans Dust. L'entrée existe toujours dans l'espace de travail Dust. On appelle cela une "connexion orpheline".Concrètement, les tokens sont invalidés côté Microsoft : l'outil ne fonctionnera plus pour cet utilisateur. Mais la configuration, elle, persiste dans Dust jusqu'à ce qu'un administrateur Dust aille manuellement supprimer la connexion.Pour un cabinet d'avocats, c'est un point de vigilance important. Pas pour des raisons d'accès actif (les droits Microsoft sont bien coupés), mais pour des raisons de traçabilité et de conformité : un audit RGPD ou une inspection sur le secret professionnel peut pointer des configurations qui semblent actives alors qu'elles ne le sont plus. La liste des connexions dans Dust doit être tenue à jour.Notre recommandation : intégrer la désactivation de la connexion Dust dans le processus d'offboarding RH, au même titre que la révocation des accès Active Directory.

Les scopes Microsoft Graph : ce qu'on demande, et pourquoi

La connexion Microsoft passe par l'API Graph. Les scopes que Dust demande ne sont pas anodins, et il est important de les comprendre avant d'accorder le consentement.Pour SharePoint :

1. Files.Read.All : lecture de l'ensemble des fichiers auxquels l'utilisateur connecté a accès. C'est le scope qui permet l'indexation documentaire.

Pour Outlook (accès délégué par l'utilisateur) :

1. Mail.Read : lecture des e-mails de l'utilisateur.
2. Mail.ReadWrite : lecture et modification (pour préparer des brouillons, archiver, etc.).
3. Mail.ReadWrite.Shared : accès aux boîtes partagées et boîtes déléguées.
4. offline_access : maintien de la connexion sans que l'utilisateur soit présent à chaque action de l'agent.

Ce dernier scope mérite une attention particulière dans le contexte d'un cabinet soumis au secret professionnel. Il permet à Dust d'agir de manière asynchrone au nom de l'utilisateur. C'est ce qui rend les agents vraiment utiles (ils peuvent traiter des messages sans que l'avocat soit en train de regarder son écran) mais c'est aussi ce qui exige une politique d'usage clairement documentée.

L'accès délégué Outlook : une fonctionnalité puissante, souvent mal comprise

Un cas concret a émergé dans notre projet : une assistante juridique devait gérer les e-mails d'un avocat associé, en son absence. Dans Outlook, cette délégation est native : l'avocat accorde l'accès à l'assistante via les paramètres de boîte partagée.Dans Dust, cette délégation fonctionne via le scope Mail.ReadWrite.Shared. Concrètement : l'assistante se connecte à Dust avec son propre compte Microsoft. Elle peut alors accéder à la boîte déléguée de l'avocat — sans que celui-ci ait jamais touché à Dust, sans qu'il ait de compte Dust, sans configuration spéciale. La délégation Outlook est simplement héritée.C'est élégant. Mais cela soulève une question de gouvernance : si l'avocat n'est pas dans Dust, il ne sait pas que son e-mail est potentiellement accessible via un agent IA. La transparence interne sur ce mécanisme n'est pas optionnelle dans un contexte réglementé.

Le point de vigilance conformité que l'on ne peut pas éviter

Une connexion SharePoint dans Dust ne donne pas accès à "quelques documents choisis". Elle donne accès à l'ensemble du périmètre SharePoint de l'utilisateur connecté, selon ses droits dans le tenant Microsoft.

Pour un cabinet d'avocats, cela peut représenter des dossiers clients couverts par le secret professionnel, des documents stratégiques, des actes en cours de rédaction. L'indexation dans Dust signifie que ce contenu devient du contexte disponible pour les agents — et potentiellement pour tous les agents auxquels cet utilisateur a accès dans l'espace de travail.Nous recommandons systématiquement deux actions avant toute mise en production :

1. Documenter précisément le périmètre indexé : quels sites SharePoint, quels drives, quels dossiers sont exposés dans Dust.
2. Restreindre les droits SharePoint de l'utilisateur "connecteur" si possible : créer un compte de service avec un accès limité aux seuls espaces documentaires pertinents, plutôt que de connecter un compte avec des droits étendus.

Ce que nous retenons : 3 leçons de terrain

1. SharePoint et Outlook dans Dust, c'est deux projets distincts. L'un indexe du contenu (logique data source), l'autre agit en temps réel (logique outil). Les comprendre séparément évite les erreurs de configuration et les surprises de gouvernance.

2. La révocation dans Azure n'est pas la révocation dans Dust. Un processus d'offboarding bien conçu doit inclure la désactivation explicite dans les deux systèmes. C'est une ligne dans la procédure RH, pas une automatisation magique.

3. Le périmètre SharePoint indexé doit être pensé avant la connexion, pas après. Une fois indexé, le contenu est disponible pour les agents. Définir le bon périmètre en amont — et limiter les droits du compte connecteur — est la meilleure façon d'allier puissance et maîtrise.Ces questions de gouvernance sont au coeur de ce que nous accompagnons chez nos clients. Si vous déployez Dust dans un environnement réglementé ou souhaitez auditer vos connexions Microsoft existantes, nous pouvons vous aider à le faire correctement.

inpulp.tech — Experts en déploiement d'agents IA et en gouvernance des données pour les PME et professions réglementées.