Claude et Microsoft 365 : ce que le connecteur voit vraiment, et comment le limiter

L'essentiel en 30 secondes

Brancher Claude sur Microsoft 365 se fait en quelques clics, et c'est justement le problème : le consentement donné ce jour-là vaut souvent pour tout le tenant, sans que personne ne sache ensuite qui s'en sert, ni avec quels droits.

Avant de généraliser Claude Team dans votre PME, trois décisions vous reviennent, à vous et non à votre informaticien :

1. Qui a le droit de connecter Claude à Microsoft 365 ;
2. Ce qu'il peut lire : il voit tout ce que voit chaque utilisateur, partages SharePoint trop ouverts compris ;
3. Ce qu'il peut faire : préparer un brouillon, envoyer un mail, modifier un fichier, toucher aux règles de transfert de la messagerie.

Ces trois curseurs se règlent finement. Encore faut-il savoir qu'ils existent. Si vous voulez déployer Claude sans y passer vos soirées, c'est ce que couvre notre offre d'intégration de Claude en entreprise. En fin d'article, un modèle de charte d'usage de l'IA en sept règles, à adapter à votre entreprise.

Ce que le connecteur est réellement

Côté Microsoft 365, le connecteur de Claude n'est pas une simple « intégration » : ce sont deux applications d'entreprise publiées par Anthropic (éditeur vérifié) qui apparaissent dans votre annuaire Entra ID une fois le consentement accordé. L'assistant agit ensuite au nom de l'utilisateur connecté.

Conséquence directe : le périmètre de Claude n'est pas celui de l'application, c'est celui du compte qui s'y connecte. Un dirigeant qui a accès à tout SharePoint donne à l'assistant la visibilité sur tout SharePoint. Un collaborateur qui a reçu par erreur un lien vers le dossier RH donne à l'assistant l'accès au dossier RH.

C'est pourquoi un projet IA commence souvent par un ménage des droits : si les partages sont trop ouverts, l'assistant ne crée pas la fuite, mais il la rend beaucoup plus facile à exploiter. Notre article sur l'injection de prompt indirecte détaille l'autre face du risque : ce que l'assistant lit peut aussi chercher à le manipuler.

Le réglage par défaut que nous retrouvons le plus souvent

Le connecteur Claude est aujourd'hui déployé sur une trentaine de tenants de PME que nous gérons. En les passant en revue, nous retrouvons le même état de départ :

• le consentement a été accordé pour l'ensemble de l'organisation ;
• l'application n'exige aucune assignation : n'importe quel compte du tenant peut brancher Claude, sans demander l'avis de personne ;
• les autorisations accordées sont en lecture, mais une lecture large : messagerie, agenda, fichiers SharePoint et OneDrive accessibles, transcriptions de réunions Teams.

Rien d'illégitime : c'est le chemin le plus simple pour démarrer. Mais six mois plus tard, plus personne ne sait qui l'utilise.

Cas réel : « ouvrez-moi l'écriture », une demande qui n'était pas individuelle

Le dirigeant d'une PME utilise Claude depuis plusieurs mois. Il demande à pouvoir créer des rendez-vous et préparer des mails depuis l'assistant. La lecture fonctionne, l'écriture est refusée.

La demande semblait individuelle. Elle ne l'était pas. Le recensement des connexions sur 30 jours a montré qu'une quinzaine de comptes utilisaient déjà le connecteur, avec plus de 1 100 connexions, et que l'utilisateur le plus actif n'était pas le demandeur.

Restreindre l'application au seul demandeur aurait coupé tout le monde. D'où la règle que nous appliquons systématiquement : on recense les utilisateurs réels avant de toucher à quoi que ce soit.

État final, plus restrictif sur les deux axes qu'au départ :

• la lecture est réservée à un groupe nommé de quatorze utilisateurs, au lieu de tout le tenant ;
• l'écriture (agenda, brouillons, envoi après validation) est accordée au seul dirigeant ;
• aucun droit d'écriture sur les fichiers, aucun droit sur les paramètres de messagerie.

Dans une autre entreprise, un dirigeant voulait seulement que Claude prépare ses brouillons de réponse. Une seule autorisation a été ajoutée, pour lui seul. Les autres utilisateurs n'ont rien vu changer.

Les droits d'écriture : lesquels accorder, lesquels refuser

Quand on accepte le consentement « standard » proposé par l'éditeur, on accorde d'un coup tout le lot d'écriture déclaré. Voici comment nous le lisons pour une PME :

Le dernier point mérite qu'on s'y arrête. Une règle de transfert automatique vers l'extérieur est l'un des marqueurs classiques d'un compte compromis. Il n'y a aucune raison qu'un assistant puisse en créer.

La méthode, dans le bon ordre

L'ordre compte : chaque inversion a une conséquence immédiate pour les utilisateurs.

1. Recenser les comptes qui utilisent réellement le connecteur, à partir des journaux de connexion Entra ID.
2. Créer un groupe et y placer tous ces comptes, pas seulement celui qui a fait la demande.
3. Assigner ce groupe aux deux applications du connecteur.
4. Ensuite seulement, exiger l'assignation : seuls les membres du groupe peuvent désormais connecter Claude.
5. Accorder l'écriture par utilisateur, autorisation par autorisation, plutôt que d'accepter le lot complet.
6. Faire déconnecter puis reconnecter le connecteur aux utilisateurs concernés, faute de quoi l'ancien jeton reste en cache et le refus persiste.
7. Revoir le périmètre régulièrement : un nouveau clic sur « Accorder le consentement administrateur », ou une évolution du connecteur côté éditeur, peut réécraser ces réglages fins.

Une précision qui évite des heures perdues : ces autorisations ne se règlent pas dans « Inscriptions d'applications » du portail Entra, comme le suggèrent beaucoup de tutoriels. Ce sont des applications d'entreprise tierces, et le consentement nominatif se crée par Microsoft Graph.

Et Claude for Outlook ?

L'extension Claude for Outlook est une application distincte du connecteur, avec ses propres autorisations. Deux situations reviennent :

• elle n'a jamais été autorisée sur le tenant : l'utilisateur voit un lien de consentement administrateur, qu'un administrateur global doit ouvrir et accepter ;
• elle ne voit pas les boîtes partagées : elle les lit via une autorisation dédiée, en lecture seule et dans la limite des droits Exchange de l'utilisateur, comme l'indique la documentation d'Anthropic. Sur un tenant où le consentement des utilisateurs est désactivé, cette autorisation doit être ajoutée par un administrateur.

Dans les deux cas, ne confondez pas cette extension avec le connecteur Microsoft 365 de claude.ai : l'un peut voir une boîte partagée et l'autre non, ce qui sert d'ailleurs de diagnostic.

Avant de généraliser : la checklist du dirigeant

• Je sais qui dans l'entreprise a connecté Claude à Microsoft 365.
• L'application est réservée à un groupe nommé, et quelqu'un est responsable de sa liste.
• Les droits d'écriture sont accordés par personne, pas au lot complet.
• Personne n'a donné à l'assistant le droit de modifier les règles de transfert.
• Les partages SharePoint ont été revus : l'assistant n'hérite pas d'accès ouverts par erreur.
• Une revue périodique est prévue, par exemple à chaque trimestre.
• Une charte d'usage dit ce que l'on peut confier à l'IA, et ce que l'on ne lui confie pas (modèle ci-dessous).

Si plusieurs cases restent vides, commencez par le socle : notre sécurisation Microsoft 365 traite les accès, les partages et l'accès conditionnel sur lesquels l'assistant s'appuie.

Une charte d'usage de l'IA en sept règles

Dernière case de la checklist, et souvent la première qui manque. La charte n'a pas besoin de faire dix pages : une page lue et signée par chacun vaut mieux qu'un document que personne n'ouvre. Voici une base volontairement classique, pensée pour une PME française, à adapter à votre activité et à faire relire par votre conseil si vous êtes dans un secteur réglementé. Ce n'est pas un avis juridique.

1. Un seul outil, le compte professionnel. L'assistant IA s'utilise avec le compte Microsoft 365 de l'entreprise et le connecteur validé par la direction. Aucun document de l'entreprise n'est déposé sur un compte personnel, gratuit ou payant.
2. Ce que l'on peut confier. Ce à quoi l'utilisateur a déjà accès dans son travail : brouillons, comptes rendus, synthèses, reformulations, préparation de réunions, recherche dans ses propres mails et fichiers.
3. Ce que l'on ne confie pas, sauf accord écrit de la direction. Les données personnelles de clients, de salariés ou de candidats au-delà du strict nécessaire (RGPD), les données de santé, les coordonnées bancaires, les mots de passe, les informations couvertes par un accord de confidentialité, les dossiers contentieux.
4. L'humain reste responsable. Un mail, un devis ou un document préparé par l'assistant est relu avant envoi. Les chiffres, les dates, les noms et les références juridiques sont vérifiés. Aucune décision concernant une personne (recrutement, évaluation, sanction) ne repose uniquement sur l'IA.
5. Transparence avec les clients. La direction décide, par écrit, si et comment l'aide de l'IA est mentionnée dans les livrables et les contenus publiés. Tout le monde applique la même règle.
6. Signaler ce qui est anormal. Une réponse étrange, une action que l'on n'a pas demandée, un document que l'on ne devrait pas voir apparaître dans une réponse : on le signale à l'informatique sans attendre. C'est souvent le premier signe d'un partage trop ouvert ou d'une injection de prompt.
7. Une charte vivante. Annexée à la charte informatique ou au règlement intérieur, relue une fois par an et à chaque nouvel outil. Dans les entreprises d'au moins 50 salariés, le comité social et économique est consulté avant l'introduction d'une nouvelle technologie (article L2312-8 du code du travail).

Ces sept règles tiennent sur une page. Le reste, les groupes, les autorisations, les journaux de connexion, c'est le travail de votre prestataire, et c'est ce que décrit cet article.