Google Workspace : une solution de continuité d'activité en cas de pannes de Microsoft 365

Lorsque Microsoft 365 tombe en panne, la première question qui se pose est de savoir comment permettre aux collaborateurs de reprendre le travail. Il s'agit là d'un problème concret de continuité des activités, et Google Workspace peut apporter une réponse concrète.

Pour la plupart des entreprises, Microsoft 365 constitue l'infrastructure qui assure le bon fonctionnement de la communication, de la coordination et de l'activité elle-même. En cas de panne de Microsoft 365, les questions fusent :

Les utilisateurs peuvent-ils envoyer et recevoir des e-mails ?

Peuvent-ils consulter leur agenda ?

La direction dispose-t-elle toujours d'un accès aux e-mails et à l'agenda pour gérer la réponse à la crise ?

Les équipes en contact avec la clientèle peuvent-elles encore communiquer avec l'extérieur ?

Les membres de l'équipe peuvent-ils accéder aux fichiers ? Ou doivent-ils attendre que la sauvegarde soit d'abord restaurée ?

Ces questions revêtent plus d'importance que jamais, alors que la réglementation impose désormais des exigences plus strictes en matière de résilience opérationnelle et de continuité des activités.

Que vous vous prépariez à SOC 2 contrôles de disponibilité, navigation NIS2 les exigences en matière de résilience opérationnelle, ou l'alignement sur des cadres tels que NIST CSF 2.0 et ISO 22301, il convient d'évaluer de manière explicite la dépendance vis-à-vis de Microsoft 365. Se fier uniquement à la disponibilité garantie par Microsoft est de moins en moins défendable en tant que stratégie de continuité d'activité.

Cela a conduit les équipes techniques à s'intéresser de plus en plus aux solutions de secours à chaud, en particulier Google Workspace. Non pas en remplacement de Microsoft 365, ni en tant qu'outil de sauvegarde traditionnel, mais en tant que deuxième environnement cloud indépendant capable de garantir la disponibilité des e-mails, des agendas, des fichiers et des communications essentielles en cas de perturbation de Microsoft 365.

Il s'agit là d'une approche totalement différente de celle des plateformes de sauvegarde Microsoft 365, telles que Veeam, Druva ou toute autre solution de restauration, qui permettent de récupérer des boîtes aux lettres, des fichiers et d'autres données après un incident. Aussi performantes que puissent être ces plateformes, si des milliers d’utilisateurs ont besoin d’un accès opérationnel à leur boîte de réception et à leur agenda dans les deux heures qui suivent, la sauvegarde à elle seule ne suffira pas.

Google Workspace can indeed support business continuity during a Microsoft 365 outage, especially for email, calendar, appointments, and crisis communication. Microsoft 365 remains the primary platform, while Google Workspace provides an independent continuity environment. But this kind of cross-cloud business continuity model requires the right architecture and planning: identity, mail routing, synchronization, security, user access, and failback all need to be designed and tested before the outage happens, not during it.

Les réglementations et les cadres tels que la directive NIS 2, la directive DORA et le cadre de cybersécurité du NIST renforcent les exigences en matière de prévention et de gestion des perturbations affectant les services essentiels et les fonctions critiques ou importantes, bien que leur champ d'application, leur terminologie et leur effet juridique diffèrent.

DORA définit une “ fonction critique ou importante ” en fonction de l'impact significatif que sa perturbation pourrait avoir sur les résultats financiers, la continuité des services ou les obligations réglementaires, tandis que NIS2 nécessite la mise en place de mesures de continuité des activités et de gestion de crise dans le cadre de la gestion des risques liés à la cybersécurité. Par ailleurs, des référentiels tels que NIST CSF traiter les conséquences associées grâce à ses fonctions « Gérer, Réagir et Rétablir », notamment la gestion des incidents, la remise en état et la communication.

Même si les termes utilisés ne sont pas cohérents, la question pratique demeure :

Quels sont les services et les dépendances essentiels au sein de votre organisation ?

Une méthode pratique pour transposer les exigences réglementaires de haut niveau en un plan de continuité des activités consiste à mener un évaluation des fonctions critiques contre les dépendances majeures vis-à-vis du cloud. La question essentielle est simple :

Si ce service cloud est indisponible pendant X heures, cela nous fait-il franchir un seuil sur le plan juridique, opérationnel, du service client, de la sécurité ou financier ?

Pour Microsoft 365, cette évaluation doit porter sur les éléments suivants :

• RTO et RPO : how quickly services need to resume, and how much data loss is acceptable
• Rayon d'explosion : quelles fonctions, équipes, clients ou processus sont concernés
• Risque de concentration : le montant dépend du fournisseur, du locataire, de la région ou de la couche d'identité
• Interdépendances : identité, gestion des clés, accès au réseau, intégrations et voies de communication externes

Si l'on examine Microsoft 365 sous cet angle, le constat est rarement rassurant. La messagerie électronique, la gestion des identités, les agendas et l'accès aux fichiers s'avèrent souvent être des dépendances opérationnelles qui nécessitent une planification explicite de la continuité des activités, et pas seulement une simple sauvegarde et restauration.

Les réglementations et les normes n'imposent pas d'architecture de continuité particulière ni de fournisseurs spécifiques. Toutefois, leurs exigences peuvent influencer directement sa conception :

• ISO 22301 préconise la définition d'objectifs de reprise d'activité, la mise en place de procédures de continuité documentées et la réalisation de tests réguliers. Lorsque l'impact potentiel sur l'activité le justifie, une solution de secours « hot standby » pour Microsoft 365 peut s'avérer appropriée.
• Si votre organisation est une entité financière, DORA requires you to assess information and communication technology (ICT) concentration risk and provider substitutability. It also requires documented exit strategies for ICT services that support critical or important functions. Depending on the risk assessment, this may support an alternative-provider or multi-vendor design, but DORA does not mandate one specific architecture.
• NIS2 étend cette même logique à un ensemble plus large d’entités essentielles et importantes, et intègre explicitement la continuité d’activité, la reprise après sinistre, la gestion de crise et la sécurité de la chaîne d’approvisionnement dans ses mesures de gestion des risques liés à la cybersécurité. Cela permet de prendre en compte les dépendances majeures vis-à-vis du cloud et des fournisseurs de services dans l’évaluation des risques de l’organisation.
• Aux États-Unis, les fonctions « Gouverner », « Réagir » et « Se relever » de NIST CSF 2.0 exigent la mise en place de plans de reprise d'activité éprouvés et d'une gestion des risques liés à la chaîne d'approvisionnement, ce qui soulève la même question : les fonctions essentielles peuvent-elles continuer à fonctionner si un fournisseur clé venait à faire faillite ?

La question d'ordre architectural consiste à déterminer comment assurer la continuité des fonctions critiques lorsque le fournisseur principal n'est pas disponible. Si une panne de Microsoft 365 peut interrompre ces fonctions, l’entreprise peut avoir besoin d’un environnement de secours déjà mis en place, accessible et testé. Ce risque est souvent plus important qu’il n’y paraît à première vue, car Microsoft 365 ne repose pas sur une seule dépendance, mais sur plusieurs dépendances interconnectées.

Microsoft 365 regroupe quatre éléments qui, pris séparément, justifieraient chacun à eux seuls la mise en place d'un plan de continuité :

• Communication (Exchange / Teams). Dans la pratique, une interruption du routage des e-mails ou du service de messagerie instantanée paralyse l'activité de l'entreprise, même si, techniquement, tous les fichiers sont en sécurité.
• Calendrier (Exchange / Teams). La gestion des plannings et l'accès aux réunions fonctionnent de la même manière que pour les e-mails, ce qui entraîne un manque de coordination en interne et des réunions externes manquées, même si, techniquement, rien n'est " perdu "."
• Documents (SharePoint / OneDrive). Les fichiers doivent rester accessibles, et pas seulement récupérables.
• Identité (Entra ID / Azure AD). Si la couche d'authentification tombe en panne, peu importe que le reste fonctionne : personne ne peut se connecter à quoi que ce soit, y compris aux applications tierces qui s'appuient sur le même fournisseur d'identité.

À ce stade, on constate malheureusement que les logiciels de sauvegarde classiques ne protègent généralement que le troisième élément, et ce uniquement après un délai de restauration pouvant aller de 24 à 48 heures. Les utilisateurs ne disposent donc d'aucun autre moyen de travailler pendant ce laps de temps.

La solution qui vient immédiatement à l'esprit serait peut-être de créer un tenant Microsoft secondaire. Malheureusement, cette option ne tient pas la route lorsqu'on l'examine de plus près, car une panne pourrait mettre hors service les deux tenants simultanément, même s'ils sont déployés dans des régions Microsoft 365 ou Azure différentes. L'hébergement régional ne garantit pas l'indépendance des domaines de défaillance, car Entra ID et les services Microsoft 365 de base continuent de partager la même infrastructure mondiale en arrière-plan.

Un deuxième locataire permet certes, sur le papier, de répondre à l'exigence " nous avons un locataire de secours ", mais cela ne garantit pas une indépendance suffisante.

C’est ce qui incite à se tourner vers un autre hyperscaler. Non pas parce que Google Workspace est intrinsèquement plus fiable, mais parce qu’il offre une infrastructure et une pile d’identités distinctes sur le plan opérationnel. Cette séparation peut contribuer à répondre aux préoccupations liées au risque de concentration dans le secteur des TIC et à la continuité d’activité, telles qu’elles sont exprimées dans les réglementations DORA et NIS2.