Microsoft Exchange : famille de produits et modèles de fonctionnement

Le nom Microsoft Exchange désigne aujourd’hui deux plateformes étroitement liées, mais exploitées différemment. Avec Exchange Online, Microsoft exploite les serveurs, les copies de bases de données et l’infrastructure de transport interne. Avec Exchange Server, les hôtes, Active Directory, les bases de données, les files d’attente, les certificats et la récupération relèvent de votre propre responsabilité. Exchange Hybrid relie les deux organisations lorsque les boîtes aux lettres ou les fonctions sont réparties entre elles (Microsoft Learn: Exchange, Exchange hybrid deployments).

Cette distinction est le point de départ de toute autre question. Une boîte aux lettres peut se trouver dans le cloud ou dans votre propre centre de données. L’expéditeur visible, le domaine SMTP et le carnet d’adresses peuvent néanmoins être utilisés conjointement. Ce n’est que lorsque l’emplacement de la boîte aux lettres, l’origine de ses attributs de destinataire et le chemin réel du message sont établis que la distribution, les autorisations et les erreurs peuvent être analysées de manière pertinente.

À clarifier d’abord : où se trouve la boîte aux lettres ?

Exchange gère les e-mails, les calendriers, les contacts, les tâches, les objets du carnet d’adresses et les droits d’accès. Pour les utilisateurs, cela reste en grande partie identique. Pour les administrateurs, l’emplacement de la boîte aux lettres modifie en revanche presque chaque outil et chaque responsabilité.

Le tableau n’est qu’une vue d’ensemble. Les quatre approfondissements traitent séparément les modèles de fonctionnement :

• Exchange Online explique les objets de locataire, EOP, les connecteurs, le suivi des messages, la conservation et l’exploitation d’un service cloud.
• Exchange On-Premises suit le pipeline de transport, les bases de données ESE, les DAG, Active Directory et la récupération dans votre propre centre de données.
• Exchange Hybrid traite de la synchronisation d’annuaire, de la gestion des destinataires, d’OAuth, des relations organisationnelles, d’Autodiscover et de l’Hybrid Configuration Wizard.
• Flux de messagerie hybride suit les messages entre Internet, Exchange Online, l’organisation locale et une passerelle de messagerie facultative.

Structure technique commune : ce qui reste identique dans toutes les variantes d’Exchange

Une fois le lieu d’exploitation clarifié, il est utile d’examiner le modèle fonctionnel commun. Exchange connaît les destinataires, les messages, les boîtes aux lettres, les règles de transport, les domaines et les connecteurs. Ces termes apparaissent dans le cloud et sur vos propres serveurs, même si les systèmes sous-jacents sont accessibles différemment (Microsoft Learn: Recipients, Mail flow and the transport pipeline).

Un destinataire est d’abord un objet d’annuaire à extension messagerie. Il possède des adresses et un type, par exemple une boîte aux lettres utilisateur, une boîte aux lettres partagée, un groupe, un contact ou un utilisateur à extension messagerie. L’objet répond à la question de savoir qui une adresse représente et où Exchange doit distribuer le message. La boîte aux lettres stocke ensuite les éléments proprement dits. Ainsi, un objet de destinataire défectueux et une boîte aux lettres saine peuvent coexister, ou inversement.

Le chemin des messages suit également les mêmes grandes étapes sur les deux plateformes : Exchange accepte un message SMTP, résout les destinataires, applique les règles de transport et les fonctions de protection, sélectionne la destination suivante et distribue le message soit dans une boîte aux lettres, soit vers un autre saut SMTP. L’implémentation exacte diffère. Sur vos propres serveurs, l’administrateur peut consulter les files d’attente et les journaux de suivi locaux ; dans Exchange Online, le suivi des messages, les rapports et Service Health sont disponibles à cette fin (Exchange Server mail flow, Trace an email message in Exchange Online).

De l’adresse au chemin du message

Le domaine SMTP commun conduit souvent à l’hypothèse erronée que tous les messages empruntent le même chemin. En réalité, une combinaison de DNS, de domaines acceptés, d’objets de destinataire, de connecteurs et de règles détermine où un message va ensuite.

Un domaine accepté indique à Exchange comment traiter un domaine. Pour un domaine faisant autorité, Exchange attend tous les destinataires valides dans son propre annuaire. Pour un domaine de relais interne, les destinataires inconnus peuvent être transférés vers un autre système. Ce paramètre n’est donc pas une simple ligne d’inventaire, mais fait partie de la décision de distribution (Accepted domains in Exchange Server, Accepted domains in Exchange Online).

Les connecteurs déterminent ensuite de quels systèmes Exchange accepte les messages et vers quels systèmes il les envoie. Dans Exchange Server, les connecteurs de réception et d’envoi utilisent des liaisons locales, des espaces d’adressage, des serveurs sources, des hôtes intelligents et des autorisations. Exchange Online utilise des connecteurs entrants et sortants pour les relations avec votre propre infrastructure ou avec des partenaires (Connectors on Exchange servers, Set up connectors to route mail).

C’est seulement à ce stade que les variantes hybrides deviennent importantes. Le transport de messagerie centralisé, une passerelle en amont ou un domaine de destinataires partagé modifient les sauts supplémentaires et les responsabilités. Ils ont donc leur place dans l’article dédié Flux de messagerie hybride, et non parmi les sujets d’identité ou de client.

De la connexion à la boîte aux lettres

Le chemin du message n’explique pas encore comment Outlook trouve sa boîte aux lettres. Pour cela, Exchange utilise Autodiscover. Un client commence par l’identité de l’utilisateur et en déduit le point de terminaison de service approprié. Localement, les points de connexion de service Active Directory et le DNS peuvent être impliqués ; dans Exchange Online, les points de terminaison Microsoft 365 conduisent au service cloud (Microsoft Learn: Autodiscover).

Après la détermination du point de terminaison, l’accès moderne d’Outlook s’effectue via HTTPS, notamment avec MAPI over HTTP. Outlook sur le Web, Exchange ActiveSync et diverses API utilisent également HTTPS, mais chacun avec ses propres protocoles d’application et autorisations. Une connexion réussie au portail Microsoft 365 ne prouve donc pas automatiquement que le fonctionnement d’Autodiscover, du protocole Outlook ou de l’accès à la boîte aux lettres concernée (Client Access protocol architecture, MAPI over HTTP).

En fonctionnement hybride, une décision supplémentaire s’ajoute : la boîte aux lettres est-elle locale ou en ligne ? Autodiscover et les attributs de destinataire doivent guider le client vers le bon côté. Ce n’est qu’ensuite que les fonctions interorganisationnelles telles que les informations de disponibilité ou les déplacements de boîtes aux lettres entrent en jeu. Cet ordre est traité étape par étape dans l’article Exchange Hybrid.

Administration et autorisations

Une fois les chemins des données et des accès compris, la question est de savoir qui peut les modifier. Exchange utilise un contrôle d’accès basé sur les rôles. Les rôles contiennent des cmdlets et des paramètres, les groupes de rôles ou les attributions de rôles les associent à des administrateurs, et les étendues limitent leur champ d’application. Exchange Online et Exchange Server possèdent des concepts RBAC apparentés, mais des configurations distinctes (Permissions in Exchange Server, Permissions in Exchange Online).

Au quotidien, cela signifie qu’un rôle d’administrateur Entra, un groupe de rôles Exchange et une autorisation de boîte aux lettres ne sont pas la même chose. Full Access permet d’ouvrir une boîte aux lettres, Send As d’envoyer en tant que destinataire et Send on Behalf d’envoyer de manière identifiable au nom de quelqu’un. Aucune de ces autorisations n’explique à elle seule si une application peut accéder via Microsoft Graph ou EWS (Manage permissions for recipients in Exchange Online).

La question d’expert n’est donc pas « L’utilisateur est-il administrateur ? », mais : quelle identité se connecte, quel rôle s’applique dans quelle organisation Exchange, quel objet est ciblé et quelle autorisation supplémentaire de boîte aux lettres ou d’application est vérifiée ?

L’exploitation et le dépannage commencent du bon côté

Un diagnostic pertinent commence par trois informations : utilisateur ou destinataire concerné, heure exacte et emplacement de la boîte aux lettres. Le chemin est ensuite suivi dans l’ordre suivant : DNS ou Autodiscover, connexion, point de terminaison Exchange, résolution du destinataire, événement de transport et distribution dans la boîte aux lettres.

Pour Exchange Online, le suivi des messages et Microsoft 365 Service Health fournissent l’état du service visible par le client. Pour Exchange Server, s’y ajoutent les files d’attente locales, les journaux de suivi des messages, les ensembles d’intégrité, les journaux d’événements et les copies de bases de données. En fonctionnement hybride, les éléments probants des deux côtés sont réunis sur une chronologie commune (Message Trace FAQ, Server health and performance).

Les articles approfondis contiennent chacun des blocs de diagnostic Windows/Unix appropriés et la documentation officielle des outils utilisés. Ici, la règle d’exploitation principale suffit : déterminer d’abord le lieu et le chemin, puis choisir l’outil.

Stockage des données, disponibilité et récupération

La différence entre le cloud et l’exploitation en interne est particulièrement visible lors de la récupération. Exchange Server stocke les boîtes aux lettres dans des bases de données ESE avec des journaux de transactions. Les Database Availability Groups répliquent les copies de bases de données et permettent des activations sur d’autres serveurs. L’organisation reste toutefois responsable de la stratégie de sauvegarde, de la récupérabilité et de la dépendance à Active Directory (Database availability groups, Backup, restore and disaster recovery).

Exchange Online exploite la redondance des bases de données et du transport comme une composante du service. Les administrateurs du locataire travaillent plutôt avec les éléments supprimés, Single Item Recovery, la conservation, les conservations légales et, le cas échéant, des exigences de sauvegarde externes. La résilience du service Microsoft et une règle de conservation métier répondent à des questions différentes : l’une protège le service en cours d’exécution, l’autre détermine quels contenus sont conservés après suppression ou à des fins de conformité (Exchange Online data resiliency, Retention policies for Exchange).

En fonctionnement hybride, les deux modèles de récupération doivent être documentés côte à côte. La synchronisation d’annuaire, les certificats, la configuration OAuth et les connecteurs sont également nécessaires pour rétablir la connexion après une panne. Ces configurations ne contiennent certes pas de contenu de boîtes aux lettres, mais elles déterminent si les deux organisations Exchange peuvent à nouveau fonctionner ensemble.

Évolution technique

Exchange 4.0 est apparu en 1996 comme successeur des premières plateformes de messagerie Microsoft. Les premières versions utilisaient leur propre annuaire, MAPI et la famille de bases de données ESE ; les protocoles Internet ont progressivement gagné en importance. Avec Exchange 2000, Active Directory et SMTP sont devenus des composants centraux. Exchange 2007 a introduit des rôles de serveur marqués et l’Exchange Management Shell, Exchange 2010 le Database Availability Group (Exchange Team: A brief history of time, Exchange Team: Exchange Server 2007 transport redesign).

Parallèlement, Microsoft a développé ses offres Exchange hébergées vers Exchange Online. Ainsi, Hybrid n’est pas né comme un produit unique, mais comme la connexion de deux organisations Exchange indépendantes. Exchange Server Subscription Edition poursuit cette ligne de développement locale dans le Modern Lifecycle depuis 2025. Les informations concrètes sur les builds et les mises à jour sont vérifiées avant toute modification dans la documentation Microsoft continuellement mise à jour (Exchange Server SE release notes, Exchange Server Subscription Edition lifecycle).