Quand Microsoft s'éteint, qu'est-ce qui permet à votre organisation d'avancer ?

Lorsqu'un grand fournisseur cloud tombe, la même question revient : « Comment est-ce possible ? »

La bonne question est plutôt : « Qu'est-ce qui a continué à tourner, et qu'est-ce qui s'est figé ? »

Car la douleur ne vient presque jamais de la perte d'une application. Elle vient de l'effondrement des coutures entre applications : identité, e-mail, confiance des terminaux, workflows, et ce réflexe humain de « se reconnecter ». Quand ces coutures lâchent, le travail s'arrête là où vous n'aviez pas mis l'étiquette « critique pour l'IT ».

L'incident danois décrit dans Microsoft-nedbrud rammer hele Danmark: »Den centrale nerve i kommunikationen er ramt« est utile pour une raison : il condense un risque latent en une seule journée. Collectivités, régions et entreprises privées l'ont ressenti, mais pas de la même manière. Toute la leçon est là.

Voici le modèle que j'utiliserais pour conduire le post-mortem, puis le traduire en architecture et en contrats conçus pour « tomber en douceur », et non en « best effort ».

La vraie panne, c'est souvent l'identité, pas les apps

La plupart des organisations pensent acheter du SaaS. En réalité, elles achètent un graphe de dépendances — et le nœud tout en haut, c'est l'identité.

Quand l'identité est indisponible ou incohérente, trois effets se déclenchent très vite :

• Les équipes ne peuvent pas démarrer : impossible de s'authentifier aux outils qui portent le travail du jour.
• Le support est impuissant : les scripts du helpdesk supposent précisément le même plan d'identité en train de tomber.
• Les contournements locaux sont bloqués : l'accès conditionnel, la MFA et la conformité des terminaux empêchent les solutions du type « utilisez votre téléphone ».

C'est pour cela que la formule de l'article, qui décrit Microsoft comme « le nerf central de la communication », fait mouche. Ce n'est pas seulement la communication. C'est la couche d'autorisation du travail.

Si vous voulez une discussion interne plus juste, cessez de dire « panne Microsoft » et dites plutôt : panne du plan d'identité. Ce simple choix de mots impose la bonne question ensuite : « Qu'est-ce qui s'appuie aussi sur ce plan ? »

Cartographiez les dépendances par workflow, pas par fournisseur

Le risque de concentration ne se résout pas en ajoutant un deuxième fournisseur « au cas où ». Il se résout en identifiant les workflows qui doivent survivre, puis en concevant, pour chacun, un chemin minimal viable.

Une approche simple consiste à choisir cinq workflows qui maintiennent votre organisation en sécurité, en conformité et en capacité de facturer. Puis à retracer, de bout en bout, ce dont chacun dépend un jour normal.

Dans les environnements municipaux et les services industriels, les dépendances critiques se regroupent généralement en quatre zones.

1) Identité et accès

• SSO et MFA
• Politiques d'accès conditionnel
• Parcours de réinitialisation de mot de passe
• Outillage d'accès privilégié

Si vos comptes « break glass » vivent dans le même système d'identité, ce ne sont pas des break glass. C'est du théâtre.

2) Messagerie et agenda (car c'est aussi votre bus de workflow)

L'e-mail reste l'endroit où les validations se font, où les incidents s'escaladent et où la coordination ad hoc se met en place quand les systèmes tombent. Si la messagerie est couplée au même échec d'identité, vous perdez votre canal de secours au moment où vous en avez besoin.

3) Gestion des terminaux et confiance

Les postes modernes sont gouvernés — et c'est normal. Mais la gestion des terminaux peut devenir un point de défaillance unique, souvent invisible : contrôles de conformité, renouvellement de certificats, profils VPN, capacité à pousser une configuration d'urgence.

Lors d'une panne large, le symptôme immédiat ressemble souvent à « mon ordinateur fonctionne, mais je n'accède à rien ». La cause structurelle, c'est que le terminal n'est plus considéré comme de confiance.

4) Workflows autour du SCADA (pas la boucle de contrôle, la boucle humaine)

Dans les infrastructures critiques, le système de contrôle est souvent segmenté. La partie fragile, c'est tout ce qui l'entoure : tickets de maintenance, alarmes renvoyées vers des outils collaboratifs, plannings d'astreinte, passations de relève, procédures d'accès distant pour les fournisseurs, reporting.

La boucle de contrôle peut continuer à tourner, mais l'organisation perd la visibilité et la coordination. C'est ainsi que de petits défauts se transforment en incidents longs.

Une méthode pratique : pour chaque workflow, écrivez le « Day Zero Minimum ». C'est le plus petit ensemble d'actions que vous devez encore pouvoir réaliser si l'identité, la messagerie et la gestion des terminaux sont dégradées pendant 24 heures.

Concevoir du fail-soft : des modes dégradés que vous pouvez répéter

Les plans de continuité d'activité ressemblent souvent à des intentions. Le fail-soft, c'est autre chose : vous concevez un mode dégradé volontairement moins confortable, mais disponible de façon fiable.

Trois patterns reviennent systématiquement.

Pattern A : autorité locale, limitée dans le temps

Il vous faut un moyen pour qu'un nombre limité de personnes puissent agir sans le système d'identité central. Cela ne veut pas dire « sans sécurité ». Cela veut dire une sécurité alternative.

• Identifiants utilisables hors ligne, conservés via un processus physique sécurisé (enveloppe scellée, double contrôle, journal d'audit a posteriori).
• Comptes locaux à durée limitée sur des systèmes clés, activables via une chaîne d'approbation manuelle.
• Procédures d'accès d'urgence pratiquées chaque trimestre, pas simplement relues une fois par an.

Pattern B : communications alternatives qui ne partagent pas le même domaine de défaillance

Si votre canal d'incident est Teams et que votre identité est Entra, vous êtes dans un seul domaine. Si votre téléphonie est administrée dans le cloud via les mêmes comptes admin, cela peut être le même domaine aussi.

Choisissez au moins un canal réellement séparé sur le plan opérationnel. Cela peut être aussi simple qu'un arbre SMS prédéfini pour les rôles d'incident, adossé à une liste imprimée. L'objectif n'est pas l'élégance. L'objectif est d'avoir un chemin qui survit au même blast radius.

Pattern C : accès aux données sans dépendre de toute la suite de productivité

Quand le « nerf central » est touché, les blocages immédiats sont souvent banals : listes de contacts, procédures, registre d'actifs, ordres de travail en cours, personnes d'astreinte.

Rendez disponible un petit sous-ensemble en lecture seule, hors ligne ou hébergé autrement. L'erreur consiste à vouloir tout répliquer. Le gain, c'est de rendre accessibles les 20 pages qui maintiennent la coordination quand le reste disparaît.

J'ai déjà vu une organisation de produit connecté découvrir, lors d'une perturbation d'identité, que la perte opérationnelle majeure n'était pas les dashboards. C'était l'incapacité à joindre le bon technicien terrain, avec le bon contexte. Les systèmes étaient « suffisamment en ligne ». Le travail, non. Cela a changé notre manière de traiter les données de contact, les listes de rôles et les passations d'astreinte : non plus comme des détails administratifs, mais comme des intrants de production.

Contractualisez une reprise que vous pouvez tester, pas des promesses que vous pouvez citer

Les contrats cloud se négocient souvent comme un achat. Le risque de concentration impose de négocier en propriétaire du risque.

Quatre clauses comptent plus qu'un point de remise supplémentaire.

1) Modes de défaillance explicites et escalade du support

Quand ça se passe mal, vous devez savoir ce qui vous sera communiqué, à quelle vitesse, et via quel canal — un canal qui ne dépend pas du même système d'identité. Une « status page » ne suffit pas si l'accès à votre admin center est cassé.

2) RTO et RPO là où vous en avez réellement besoin

Beaucoup d'organisations écrivent des chiffres génériques qui font sérieux et ne servent à rien. Alignez les objectifs sur les workflows cartographiés plus haut. Si les achats ne peuvent pas émettre des bons de commande, ou si une région ne peut plus coordonner les effectifs, ce n'est pas une « dégradation mineure ».

3) Sortie et portabilité couvrant l'identité et la posture des terminaux

Les plans de sortie se concentrent souvent sur l'export de données. En situation de panne, les goulots d'étranglement sont l'identité et la posture des terminaux. Vos droits de sortie doivent inclure ce qui vous permet de rétablir l'authentification, la confiance endpoint et l'accès admin ailleurs — sous contrainte de temps.

4) Le droit de répéter

Vous ne pouvez pas revendiquer une résilience que vous n'avez jamais exercée. Inscrivez contractuellement le droit de mener des tests planifiés de vos modes dégradés. Pas du chaos engineering pour le principe. Une répétition contrôlée : « Pendant deux heures, considérez que l'identité est indisponible. Prouvez le Day Zero Minimum. »

Si cela vous paraît disproportionné, rappelez-vous l'alternative : vous ferez ce travail de toute façon, mais en pleine panne, avec des équipes sous stress et une pression politique maximale.

Un modèle de post-mortem que vous pouvez lancer la semaine prochaine

Servez-vous de la panne comme d'un déclencheur. Même si vous n'avez pas été touchés directement, traitez-la comme un quasi-accident.

1. Racontez la timeline en termes humains : quand les premiers ont-ils remarqué ? Qu'ont-ils essayé ? Qu'est-ce qui a lâché en premier ? Quel travail s'est arrêté ?
2. Choisissez 5 workflows qui doivent tenir 24 heures. Nommez un propriétaire de workflow pour chacun.
3. Tracez les dépendances : identité, messagerie, gestion des terminaux, ticketing, communications, accès aux fichiers, outillage d'astreinte.
4. Définissez le Day Zero Minimum pour chaque workflow, en un paragraphe. Sans jargon.
5. Concevez un chemin dégradé par workflow, même s'il est manuel.
6. Désignez un responsable qui rend cela réel : documentation, accès, répétitions.
7. Négociez les ajustements contractuels qui rendent le chemin dégradé tenable, y compris les droits de répétition et les canaux d'escalade.

C'est là que beaucoup d'organisations découvrent une vérité inconfortable : leur récit de résilience est surtout implicite. Implicite, c'est comme non assumé.

Si vous voulez un modèle mental connexe, j'aime poser la question « qu'est-ce qui casse en premier ? », parce qu'elle oblige à être précis, plutôt que de se cacher derrière des slogans. J'utilise la même approche dans les infrastructures de marché, où les cascades de défaillance ne sont pas théoriques. C'est la même question derrière What breaks first in 24/7 tokenized equities: halts or dividends?

Mon avis : le fail-soft relève d'un choix de leadership, pas d'une fonctionnalité cloud

L'objectif n'est pas d'être indépendant des grands fournisseurs. Pour la plupart des organisations, c'est irréaliste et inutile.

L'objectif est d'être indépendant d'une défaillance. L'identité tombe, vous continuez à coordonner. L'e-mail prend du retard, vous continuez à valider. La gestion des terminaux se dégrade, vous continuez à accéder aux systèmes critiques. Les workflows autour du SCADA ralentissent, mais ils ne vous rendent pas aveugles.

Voilà à quoi ressemble, dans la vraie vie, le « risque de concentration cloud » : pas une ligne dans un registre des risques, mais un mardi où les gens ne peuvent plus faire leur travail.

Si vous concevez pour ce mardi, vous n'êtes pas seulement plus en sécurité. Vous allez plus vite le reste de l'année, parce que vous comprenez enfin de quoi votre organisation dépend réellement.