TL;DR – Résumé
"La " continuité du service de messagerie » revêt des significations différentes selon les personnes. Historiquement, ce n'était pas un sujet qui préoccupait particulièrement la plupart des entreprises. Si vous aviez interrogé un administrateur Exchange ou Microsoft 365 il y a quelques années, il vous aurait répondu que les perturbations de la messagerie se résolvaient d'elles-mêmes, et il n'aurait pas eu tort. L'infrastructure de Microsoft est réellement performante, le protocole SMTP met les e-mails en file d'attente et la plupart des pannes sont de courte durée.
Ce n'est plus tout à fait exact. Même si les coupures ne durent pas longtemps, la question n'est plus seulement :
“ Est-ce que les e-mails finiront par arriver ? ”
Au lieu de cela, c'est devenu :
“ L'entreprise peut-elle continuer à fonctionner sans e-mail ? ”
Toute interruption de service de Microsoft 365 entraîne une perte de productivité, des retards dans la communication et des opportunités commerciales manquées, et ces conséquences sont particulièrement visibles dans les grandes entreprises.
De plus, les cadres de conformité tels que NIS2, DORAet SOC 2 renforcent cette évolution vers la continuité des activités. Ces cadres s'inscrivent dans une tendance réglementaire plus large qui pousse les organisations à aller au-delà de la sauvegarde et de la restauration, pour s'orienter vers le maintien de la capacité opérationnelle en cas de pannes, de cyberincidents et d'interruptions de service.
Vous souhaitez découvrir directement comment Google Workspace, utilisé en parallèle avec Microsoft 365, peut garantir la continuité des activités ?
Explorere Google Workspace for Business Continuity par Connecting Software, la couche technologique qui permet le fonctionnement de l'offre « Google Business Continuity Plus ».
La sauvegarde protège les données. La continuité des services de messagerie contribue à la résilience opérationnelle.
Lorsque vous envisagez une solution de sauvegarde pour Microsoft 365, vous vous préoccupez généralement de la restauration des données après un incident.
Les solutions de continuité de la messagerie électronique, quant à elles, sont conçues pour garantir le bon fonctionnement des communications, des agendas et de la collaboration pendant l'incident.
Cette distinction est importante dans les cas suivants :
- Pannes de Microsoft 365,
- exclusion des locataires,
- attaques par ransomware,
- problèmes d'identité,
- ou les cyberattaques.
La vraie question est la suivante :
Comment les utilisateurs peuvent-ils continuer à travailler lorsque l'environnement principal est indisponible ?
C'est également là que deux indicateurs, sur lesquels toute discussion relative à la continuité des activités (BCP) et à la reprise après sinistre (DR) finit inévitablement par se concentrer, prennent toute leur utilité : RTO et RPO.
Dans le cadre d'une discussion classique sur la sauvegarde, le RTO correspond généralement au temps nécessaire pour restaurer le système ou les données concernées, tandis que le RPO reflète l'ancienneté du point de restauration (en d'autres termes, la quantité de données récentes qui pourraient manquer).
Dans le cadre d'une discussion sur la continuité des activités par e-mail, les mêmes indicateurs sont souvent utilisés au niveau des fonctions métier : le RTO (temps de reprise des opérations) indique le délai que l'organisation peut tolérer avant que les utilisateurs puissent à nouveau communiquer, tandis que le RPO (point de reprise des opérations) précise le degré d'actualité requis pour l'environnement de communication de secours.
Cette distinction revêt une importance particulière dans le cadre de la NIS2, de la DORA, de la norme SOC 2 et d’autres débats similaires portant sur la résilience et la conformité, car la question est de savoir si la fonction métier peut se poursuivre pendant la perturbation.
Comparaison des approches de continuité de la messagerie dans Microsoft 365
Dès que l'exigence évolue vers “ permettre aux gens de continuer à communiquer pendant cette période de perturbation ”,” les enjeux architecturaux liés à l'informatique deviennent alors bien plus intéressants.
Un service de messagerie d'urgence allégé est-il suffisant ? Faut-il tenir compte des différentes régions ? Devrions-nous utiliser notre propre infrastructure sur site ?
Il existe plusieurs approches et compromis à prendre en compte pour atteindre le niveau de continuité dont l'entreprise a réellement besoin. Le tableau ci-dessous compare les principales approches, que nous examinerons plus en détail ci-après.
| Approche | Idée principale | Exemples d'outils et de fournisseurs | Points forts | Préoccupations courantes |
|---|---|---|---|---|
| Services de continuité d'activité basés sur le cloud | Plateforme de continuité des activités en cas d'urgence hébergée par un tiers | Mimecast, Retarus, Trend Micro | Déploiement rapide Réduction des frais généraux d'exploitation |
Continuité limitée au-delà du service de messagerie Web d'urgence |
| Deuxième locataire Microsoft 365 | Environnement Microsoft 365 distinct préparé pour la bascule | Microsoft 365 | Écosystème Microsoft familier Architecture native du cloud |
Dépendance vis-à-vis d'un écosystème reposant sur un seul fournisseur, risque de concentration |
| Serveur Exchange sur site | Environnement Exchange indépendant synchronisé avec Microsoft 365 | Microsoft, CB Exchange Server Sync | Indépendance opérationnelle et contrôle Un écosystème Microsoft familier pour les utilisateurs finaux |
Infrastructures supplémentaires et entretien |
| Google Workspace en mode « hot standby » | Environnement Google Workspace indépendant synchronisé avec Microsoft 365 | Continuité d'activité Google Workspace, CB Exchange Server Sync pour Google Workspace | Indépendance vis-à-vis des différents clouds Peut être étendu à SharePoint/ Google Drive |
Expérience utilisateur, identité et cartographie différentes |
Le choix du modèle approprié dépend du profil de risque opérationnel de l'organisation, de ses obligations en matière de conformité et de sa tolérance aux temps d'arrêt. Examinons chacune de ces options plus en détail.
Option 1 : Services de continuité de messagerie électronique basés sur le cloud
Il s'agit là d'une des approches traditionnelles. Des fournisseurs tels que Mimecast, Retarus et Trend Micro proposent des plateformes de continuité des activités basées sur le cloud, qui permettent l'accès d'urgence aux boîtes mail, le routage des e-mails et la mise en place de services de communication temporaires.
Les avantages sont un déploiement rapide et une réduction des coûts d'exploitation.
Cependant, les équipes des entreprises se demandent souvent dans quelle mesure ces plateformes garantissent une véritable continuité opérationnelle, au-delà d'un simple accès temporaire à la messagerie Web. Les utilisateurs peuvent-ils toujours synchroniser leurs agendas, utiliser des boîtes aux lettres partagées et revenir sans encombre à Microsoft 365 une fois l'incident résolu ?
Option 2 : locataire Microsoft 365 secondaire
Certaines organisations utilisent un tenant Microsoft 365 secondaire à des fins de basculement, parfois situé dans une autre région, afin de limiter leur vulnérabilité face aux interruptions de service régionales.
Cela peut renforcer la résilience, en particulier si le locataire secondaire est conçu avec une administration, un routage, des politiques d'accès et des procédures de reprise distincts. Toutefois, la mise en place d'une configuration interrégionale ne supprime pas la dépendance générale vis-à-vis de l'écosystème cloud de Microsoft.
Il existe également un problème plus subtil : si le locataire secondaire s'authentifie via le même fournisseur d'identité que l'environnement de production (généralement le même locataire Entra ID), un incident ou une panne lié(e) à l'identité peut alors affecter les deux environnements simultanément.
Option 3 : Serveur Exchange sur site synchronisé avec Microsoft 365
Une troisième approche consiste à maintenir un environnement serveur Exchange indépendant, synchronisé avec Microsoft 365.
On peut citer, par exemple, l'utilisation d'un serveur Exchange sur site synchronisé avec Microsoft 365.
Dans ce modèle :
- Microsoft 365 reste la principale plateforme opérationnelle,
- Le serveur Exchange constitue un environnement de continuité indépendant,
- La transition de CB Exchange Server Sync vers Connecting Software pour BCP assure la synchronisation entre les deux.
La synchronisation peut inclure :
- boîtes aux lettres,
- calendriers,
- contacts,
- dossiers publics,
- groupes de distribution,
- et la synchronisation GAL.
Comme cet environnement fonctionne sur site avec son propre Active Directory, il n’a pas besoin de partager un plan d’identité avec le locataire Microsoft 365. Il s’agit là d’une distinction importante par rapport à l’option 2 : une attaque ciblant l’identité du locataire cloud ne s’étend pas automatiquement à l’environnement Exchange sur site, ce qui a une incidence directe sur les scénarios de " défaillances d’identité " et de " verrouillage du locataire " mentionnés ci-dessus.
Le déploiement sur site en fait également la solution la plus adaptée si votre entreprise a besoin d'une solution de ce type dans un réseau isolé physiquement. La version sur site peut être utilisée en association avec des diodes de données pour permettre ce scénario.
Pourquoi certaines organisations préfèrent cette architecture
Pour les organisations soumises à des exigences plus strictes en matière de résilience opérationnelle, cette approche peut offrir :
- indépendance opérationnelle vis-à-vis de Microsoft 365,
- le code Outlook bien connu et la continuité du calendrier,
- un meilleur contrôle sur l'infrastructure et la bascule,
- prise en charge des environnements réglementés ou isolés,
- indépendance de l'identité par rapport au locataire de production,
- et une réduction du risque lié à la concentration des nuages.
Les organisations qui s'appuient également sur SharePoint et la collaboration sur des documents peuvent en outre mettre en œuvre des stratégies de synchronisation des documents à l'aide de Secure Sync for SharePoint by Connecting Software, afin d'assurer une synchronisation sécurisée de SharePoint entre des environnements indépendants ou isolés.
Option 4 : Google Workspace en mode « hot standby »
Une quatrième approche suit la même logique que l'option 3, mais change de plateforme de secours : au lieu d'un serveur Exchange sur site, l'environnement indépendant est Google Workspace, qui reste synchronisé en permanence avec Microsoft 365 via .
Cela offre aux entreprises une option de basculement inter-cloud sans aucune dépendance vis-à-vis de l'écosystème Microsoft. Cet aspect peut s'avérer important pour les entreprises soucieuses des risques liés à la concentration, et cette solution est également très prisée par celles qui exploitent déjà une partie de leurs activités sur Google Workspace. Même pour celles qui ne le font pas, les utilisateurs connaissent souvent Google Workspace grâce à leur expérience personnelle, ce qui s'avère utile lors d'un basculement.
Nous analyserons en détail cette architecture, son modèle d'identité et ses compromis spécifiques dans un prochain article.
Découvrez comment mettre en place une solution de secours « hot standby » avec Google Workspace pour assurer la continuité des activités, par Connecting Software
Basculement : suppression de la fenêtre de restauration
Avec l'approche traditionnelle de sauvegarde et de restauration, lorsqu'une panne survient, quelqu'un doit tout de même effectuer une restauration avant que quiconque puisse se remettre au travail.
Cela pose deux problèmes : l'intervention manuelle requise et la durée de la restauration, qui est proportionnelle au volume de données à restaurer. Pour les grands locataires, il n'est pas rare que les délais de reprise d'activité (RTO) se mesurent en jours.
Les services de continuité de messagerie basés sur le cloud constituent une solution de contournement à ce problème, mais leurs fonctionnalités sont limitées.
Un environnement de secours synchronisé permet de supprimer cette étape. Comme vous disposez d’une copie mise à jour en continu des boîtes aux lettres, des agendas et, à terme, des documents, il suffit de rediriger les utilisateurs vers cet environnement pour qu’ils puissent continuer à travailler. Il s’agit d’un basculement sans fenêtre de restauration. Cet environnement est opérationnel et à jour, ce qui élimine la fenêtre de restauration du calcul du RTO.
Vous devrez mettre en balance ce coût et celui lié au fait que vos utilisateurs n'aient pas accès à leurs e-mails, à leur agenda et aux autres contenus de leur boîte de réception, en termes de perte de productivité, de contrats non conclus et de coûts liés à la conformité, le cas échéant.
Reprise après incident : éviter le rapprochement manuel
Le basculement ne représente que la moitié du processus. À un moment donné, l'environnement principal redevient opérationnel et les utilisateurs doivent y revenir. C'est la phase de retour en production, où la véritable question est de savoir ce qu'il advient des e-mails envoyés et reçus, des modifications apportées au calendrier et des modifications de documents effectuées dans l'environnement de secours, sans perte de données ni création de doublons.
Les nouveaux e-mails, les modifications apportées au calendrier et les documents modifiés devront-ils être réintégrés manuellement dans l'environnement de production ? Personne n'apprécie cette tâche, car c'est précisément le genre d'étape manuelle qui est source d'erreurs, de confusion entre les versions et de retards.
Grâce à la synchronisation bidirectionnelle, ce rapprochement s'effectue automatiquement : les modifications apportées pendant l'interruption de service sont répercutées dans Microsoft 365 sans intervention du service informatique, une fois l'environnement principal rétabli. Les seules données à risque sont celles qui ont été modifiées au cours du dernier intervalle de synchronisation, c'est-à-dire le laps de temps entre deux cycles de synchronisation. Si cet intervalle est de cinq minutes, le RPO effectif correspond approximativement à cinq minutes de modifications, et non à la durée totale de l'interruption. Vous pouvez planifier la reprise automatique en fonction de votre intervalle de synchronisation afin de ramener le RPO à zéro.
Il convient de noter que l'intervalle d'interrogation implique un compromis : le raccourcir réduit le RPO, mais ; l'allonger réduit la surcharge, mais élargit la fenêtre de perte de données potentielle.
Il n'existe pas d'architecture de messagerie électronique “ idéale ”.
Le choix de la solution appropriée dépend des éléments suivants :
- dépendance opérationnelle vis-à-vis de Microsoft 365,
- temps d'arrêt acceptable,
- exigences réglementaires,
- capacités informatiques internes,
- et les objectifs en matière de résilience opérationnelle.
Les organisations dont les besoins sont modérés peuvent être pleinement satisfaites par des services de continuité d'activité basés sur le cloud.
Les organisations soumises aux dispositions de la directive NIS2 ou de la directive DORA, ou devant répondre à des exigences strictes en matière de résilience, peuvent avoir besoin d’une plus grande autonomie opérationnelle et de capacités de basculement plus solides.
Réflexions finales
Microsoft 365 offre une excellente disponibilité.
Mais la disponibilité à elle seule ne garantit pas la résilience opérationnelle.
Les entreprises prennent de plus en plus conscience que la continuité des services de messagerie électronique, l'accès à l'agenda et la continuité de la collaboration sont essentiels pour assurer la continuité des activités en cas de perturbation.
Car lors d'une véritable panne, la question la plus importante n'est pas :
“ On peut se revoir plus tard ? ”
C'est :
" Pouvons-nous continuer à fonctionner ? "
Découvrez comment mettre en place une solution de secours « hot standby » avec Google Workspace pour assurer la continuité des activités, par Connecting Software
En savoir plus sur la continuité d'activité et la reprise après sinistre
La sauvegarde n'est pas synonyme de continuité : restauration « à chaud » ou « à froid » pour Exchange, SharePoint et Microsoft 365
Le piège de la simplicité : pourquoi la messagerie électronique en nuage doit faire partie de toutes les conversations sur les PCA
Les nuages souverains s'élèvent : Remise en question du contrôle des données à l'ère de l'informatique dématérialisée
A propos de l'auteur
Par Ana Neto, conseiller technique à Connecting Software.
"Je suis ingénieur logiciel depuis 1997, et depuis peu, j'aime écrire et parler en public. Avez-vous des questions ou des commentaires sur cet article ? J'aimerais avoir votre avis, laissez un commentaire ci-dessous !"
