Adresse contact partagée : organiser Microsoft 365 sans mot de passe commun

Choisir entre boîte partagée, alias, groupe et boîte utilisateur

Une adresse contact@, accueil@ ou support@ peut cacher plusieurs besoins très différents. Avant de configurer Microsoft 365, je demande qui doit lire les messages, qui doit répondre, quelle identité doit apparaître au destinataire et si un historique commun doit rester visible. La solution vient de ces usages, pas du seul nom de l’adresse.

Une boîte partagée convient notamment aux adresses d’information, de support ou d’accueil utilisées par plusieurs personnes. Pour les autres formes — alias, groupe ou boîte utilisateur — je ne déduis pas leur comportement de leur nom : je compare le besoin au fonctionnement documenté dans le tenant avant de choisir. Si l’usage attendu dépasse la lecture et la réponse partagées, la solution doit être vérifiée séparément.

Je rédige donc un mini-brief : destinataires entrants, personnes autorisées à consulter, identité d’envoi, règles de suppression, historique attendu et appareils utilisés. Une boîte partagée n’est pas automatiquement la réponse à tous les workflows collaboratifs ; elle doit correspondre à la façon réelle de traiter les messages.

Je vérifie aussi si une seule personne reste responsable du suivi ou si plusieurs membres doivent se remplacer. Cette réponse détermine le besoin de visibilité commune et évite de choisir une solution trop lourde pour une simple redirection.

Conserver un compte nominatif par personne sans mot de passe commun

Je déconseille de transmettre le mot de passe d’une adresse générique à toute l’équipe. Dans Microsoft 365, les utilisateurs accèdent à la boîte partagée au moyen de leur propre boîte Exchange Online sous licence et de droits délégués. Chaque personne se connecte donc avec son compte nominatif, puis reçoit uniquement les autorisations nécessaires.

La boîte partagée n’est pas destinée à une connexion directe avec le compte utilisateur qui lui est associé ; Microsoft demande de maintenir cette connexion bloquée. Ce point évite de transformer la boîte technique en compte collectif dont le mot de passe circule et dont les accès deviennent difficiles à attribuer ou à retirer.

• un compte nominatif pour chaque personne ;
• une authentification propre à ce compte ;
• des droits délégués selon les tâches réelles ;
• aucun mot de passe commun transmis par message ou document ;
• une procédure de retrait lorsque la personne change de rôle ou quitte la structure.

Si un compte Microsoft a déjà été exposé ou compromis, le guide reprendre le contrôle d’un compte Microsoft piraté détaille les premières vérifications. La création d’une boîte partagée ne remplace pas la remise en sécurité des comptes individuels.

Distinguer accès complet, Send As et Send on Behalf

Les droits de lecture et d’envoi ne sont pas interchangeables. Full Access permet d’ouvrir et de gérer la boîte, mais n’accorde pas à lui seul le droit d’envoyer depuis son adresse. Je l’attribue aux personnes qui doivent consulter, classer ou supprimer des messages selon la procédure convenue.

Send As fait apparaître la boîte partagée comme expéditeur. Le destinataire voit donc l’adresse générique. Send on Behalf indique au destinataire qu’une personne a envoyé le message au nom de la boîte. Ce choix est visible à l’extérieur : je le valide avec la structure au lieu de sélectionner une permission par habitude.

Lorsque quelqu’un doit à la fois gérer les messages et répondre avec l’adresse partagée, Full Access et Send As doivent être attribués séparément. Je documente les deux lignes de droit. Cette séparation permet de donner à une personne la consultation sans l’envoi, ou l’envoi au nom de la boîte sans lui ouvrir inutilement toutes les opérations de gestion.

• lire et organiser : Full Access ;
• envoyer comme l’adresse générique : Send As ;
• envoyer avec la mention « au nom de » : Send on Behalf ;
• gérer et envoyer comme la boîte : Full Access et Send As, attribués séparément.

Régler les membres, les réponses et les messages envoyés

La liste des membres ne suffit pas. Je définis qui peut lire, répondre, supprimer, déplacer et consulter l’historique. Les membres et leurs autorisations peuvent être ajoutés ou retirés séparément dans le centre d’administration. Je limite chaque droit au besoin réel plutôt que de donner les mêmes possibilités à tout le monde.

Par défaut, les messages envoyés depuis la boîte partagée sont enregistrés dans les éléments envoyés de la personne qui a expédié le message. Cela peut empêcher les autres membres de voir qu’une réponse est déjà partie. Un réglage permet de conserver aussi les messages envoyés dans le dossier Éléments envoyés de la boîte partagée.

Je choisis ce réglage selon la méthode de travail, puis je le teste. Je vérifie aussi ce qui se passe lorsqu’un message est supprimé, déplacé dans un dossier ou traité par deux personnes presque simultanément. La technique doit servir une règle simple : qui prend le message, comment les autres le savent et où retrouver la réponse.

Vérifier licences, taille, archivage et utilisateurs externes

Une boîte partagée peut stocker jusqu’à 50 Go sans licence propre, mais cette règle n’est pas universelle : certains usages, capacités ou fonctions avancées exigent une licence adaptée. Je vérifie donc la taille actuelle, la croissance, le besoin d’archivage et les fonctions attendues avant de conclure qu’aucune licence supplémentaire n’est nécessaire.

Chaque personne qui accède à la boîte utilise sa propre boîte Exchange Online sous licence. Je contrôle aussi le type de compte : seules les personnes internes à l’organisation peuvent recevoir un accès direct à une boîte partagée Microsoft 365. Si un prestataire ou un bénévole externe doit participer, je ne promets pas un accès direct identique ; le workflow doit être repensé avec une solution conforme au besoin.

Je n’affiche aucun prix, car les offres et conditions peuvent changer. Le contrôle porte sur les fonctions nécessaires, les licences déjà attribuées et les limites documentées, pas sur une formule commerciale supposée.

Si la boîte approche d’une limite ou si l’archivage devient nécessaire, je traite ce besoin avant la bascule. Je ne promets pas qu’une configuration sans licence aujourd’hui couvrira les usages futurs.

Tester Outlook web mobile réception et envoi

Je teste chaque client réellement utilisé : Outlook sur ordinateur, accès web et mobile si ces usages sont prévus. L’objectif n’est pas seulement de voir la boîte dans la liste, mais d’ouvrir les dossiers, recevoir un message, répondre avec la bonne identité et retrouver la réponse au bon endroit.

• réception depuis une adresse de contrôle ;
• ouverture et classement par un membre autorisé ;
• envoi avec Send As ou Send on Behalf selon le choix ;
• visibilité de la réponse dans les éléments envoyés attendus ;
• suppression et déplacement conformes à la règle interne ;
• vérification sur chaque client réellement utilisé.

Je réalise aussi un test avec un utilisateur qui ne possède pas le droit concerné. Un refus attendu confirme que la délégation n’est pas plus large que prévu. Si l’ajout automatique de la boîte diffère selon le client, je consigne la méthode réellement validée au lieu d’annoncer un comportement identique partout.

Pour conserver les comptes individuels sans multiplier les mots de passe mémorisés, l’article sur le gestionnaire de mots de passe explique comment organiser les accès sans les partager.

Documenter les droits et leur révocation

Je termine par un registre simple : personne, compte nominatif, rôle, Full Access, Send As ou Send on Behalf, date d’attribution, responsable de validation et client testé. Ce document ne contient aucun mot de passe. Il permet de comprendre rapidement pourquoi un accès existe et ce qu’il autorise.

Lorsqu’une personne change de fonction ou quitte la structure, je retire ses droits séparément et je vérifie le résultat. Je ne change pas un mot de passe commun puisque ce mot de passe n’a jamais été partagé. Je contrôle ensuite que la boîte reste accessible aux membres légitimes et que l’ancien compte ne peut plus l’ouvrir ni envoyer avec son identité.

La revue périodique porte sur les membres, les permissions d’envoi, l’historique des messages et les clients utilisés. Une boîte partagée reste saine lorsque ses droits suivent les responsabilités réelles, pas lorsqu’une liste ancienne continue de fonctionner par inertie.

Je prévois enfin un contrôle après chaque changement important : arrivée, départ, remplacement de responsable ou modification du mode de réponse. Le registre et le test restent ainsi alignés avec la réalité.