Microsoft 365 En Panne : La Situation S’Améliore Lentement

Vous avez tenté d’ouvrir votre boîte Outlook lundi matin et rien n’est arrivé ? Un collègue vous a écrit que Teams refusait de le laisser rejoindre une réunion ? Ce n’est pas un caprice isolé de votre connexion. Depuis plusieurs jours, une panne Microsoft 365 perturbe l’accès au courrier, à l’authentification et à toute une chaîne de services cloud. Mardi, l’éditeur affirmait que la situation s’améliorait. Ce n’est pas la même chose que de dire que tout est rentré dans l’ordre. Et c’est précisément ce décalage qui agace les entreprises, les startups et les équipes informatiques qui dépendent de cette plateforme comme d’un système nerveux.

Quand Le Nuage Devient Un Point Unique De Défaillance

On a longtemps vendu le cloud comme une assurance contre les pannes locales. Plus de serveur dans le placard, plus de disque qui grille un vendredi soir. En échange, on a accepté de confier à un petit nombre d’acteurs la quasi-totalité de la messagerie, des fichiers, des réunions et même d’une partie de la sécurité. Lorsque Exchange Online tousse, ce n’est plus un service qui vacille. C’est le rythme de travail de millions de personnes qui se met à claudiquer.

L’incident de fin août et début septembre 2026 l’illustre avec une clarté presque scolaire. Une configuration d’authentification défectueuse a empêché certains composants de se déployer correctement sur une portion de l’infrastructure. Résultat : retards de mail, échecs d’envoi, soucis de connexion, recherche dégradée dans Outlook, et un effet de bord sur SharePoint, Teams, Copilot, Purview, Defender XDR, le centre d’administration Microsoft 365 et même Universal Print. Autrement dit, le problème n’était pas « juste la messagerie ». Il touchait le sésame qui ouvre la porte de presque tout le reste.

Cette phrase officielle mérite d’être lue lentement. Elle ne dit pas « c’est réparé ». Elle dit que les correctifs avancent, que les signaux internes sont encourageants, et que l’éditeur entre dans une phase de surveillance prolongée. Pour un directeur des systèmes d’information, c’est le langage d’un incident qui n’est plus en phase critique, mais qui n’est pas encore clos. Pour un fondateur de startup qui doit envoyer une proposition le jour même, c’est une autre affaire : le calendrier commercial, lui, n’entre pas en période de monitoring étendu.

Une Chronologie Qui S’Étire Sur Plusieurs Journées

Le récit officiel, tel qu’il a filtré via la page de statut et les messages publiés sur X, dessine une séquence classique des grands incidents cloud. D’abord les symptômes : files d’attente de messages, authentifications qui échouent, utilisateurs qui se reconnectent en boucle. Ensuite l’investigation : revue des changements récents, identification d’une mauvaise configuration empêchant le déploiement attendu de composants d’authentification. Puis les mitigations testées, appliquées, élargies. Enfin la convalescence, cette zone grise où le trafic reprend mais où la recherche reste boiteuse, où certains tenants reviennent plus vite que d’autres, où personne n’ose crier victoire trop tôt.

Lundi, Microsoft indiquait une amélioration progressive du flux de messagerie. Vers 22 heures, heure de l’Est, le courrier circulait mieux, mais la recherche demeurait dégradée. Dans la nuit, peu après 3 heures du matin, la recherche commençait elle aussi à donner des signes de reprise. Mardi matin, le discours était celui d’un mieux mesurable, pas d’un retour à la normale. Ce rythme, lent et prudent, est cohérent avec la nature du problème. Une authentification mal déployée ne se corrige pas comme on redémarre un service unique. Il faut propager une configuration saine, vérifier qu’elle tient, observer les files, surveiller les pics de reconnexion, éviter qu’un correctif trop brutal ne crée une seconde vague.

Les utilisateurs, eux, ne vivent pas cette chronologie comme une belle courbe de rétablissement. Ils voient un lundi amputé, un mardi encore collant, des fils de discussion internes où l’on échange des captures d’écran d’erreurs, des rumours sur tel ou tel data center, des conseils de contournement plus ou moins efficaces. Dans les startups, on bascule parfois vers Gmail personnel, on envoie un PDF par WeTransfer, on improvise une visio ailleurs. Ce bricolage sauve la journée. Il révèle aussi à quel point le plan B était fragile, ou inexistant.

Ce Que La Page De Statut Dit Vraiment

La communication grand public s’est d’abord concentrée sur Outlook, ce qui est compréhensible. Le courrier reste le rituel le plus visible de la journée de travail. Mais la page de statut destinée aux clients professionnels et entreprises dressait un tableau plus large. Plusieurs services ont été touchés parce qu’ils s’appuient sur une configuration d’authentification centrale. Quand cette couche vacille, les applications en aval n’ont plus seulement un bug d’interface. Elles perdent le droit de savoir qui est qui.

C’est une leçon technique que les équipes produit connaissent, mais que les métiers redécouvrent à chaque crise. On peut avoir la plus belle application du monde. Si le jeton d’identité ne se délivre pas, l’application n’existe plus pour l’utilisateur. Teams n’est plus un outil de réunion, c’est un écran qui tourne. SharePoint n’est plus un espace documentaire, c’est une page qui refuse l’accès. Copilot n’est plus un assistant, c’est une promesse hors ligne. Le centre d’administration lui-même, ironie cruelle, peut devenir plus difficile à piloter au moment où l’on en a le plus besoin.

• Messagerie Exchange Online : retards, échecs d’envoi, files d’attente.
• Outlook : connexion instable et recherche dégradée pendant de longues heures.
• Teams, SharePoint et Copilot : effets collatéraux liés à l’identité.
• Purview, Defender XDR et Universal Print : rappels que la sécurité et l’impression passent aussi par le même sésame.
• Centre d’administration Microsoft 365 : visibilité réduite au pire moment.

Cette liste n’est pas un inventaire pour faire peur. Elle sert à comprendre la géographie réelle d’une suite logicielle. On achète « Microsoft 365 » comme un bloc. On le subit aussi comme un bloc. La facturation est unifiée, l’annuaire est unifié, l’identité est unifiée. L’incident, lui, se propage selon les mêmes lignes de force.

Une Mauvaise Configuration, Pas Un Mystérieux Pirate

Microsoft a indiqué que l’enquête pointait vers une misconfiguration, une configuration erronée empêchant des composants d’authentification de se déployer comme prévu sur une partie de l’infrastructure. Ce détail compte. Il éloigne le scénario spectaculaire de l’attaque massive et rapproche un scénario beaucoup plus fréquent dans les grandes plateformes : un changement, une hypothèse fausse, un périmètre mal estimé, un mécanisme de déploiement qui n’atteint pas toutes les zones attendues.

Les organisations qui opèrent à cette échelle savent que le changement est à la fois indispensable et dangereux. On corrige, on optimise, on étend, on unifie. Chaque évolution porte un risque de régression. Les garde-fous existent : revues, canaris, déploiements progressifs, télémétrie, procédures de rollback. Ils réduisent la fréquence des catastrophes. Ils ne les abolissent pas. Quand le composant concerné est l’authentification, la surface de dégât s’élargit d’un coup. Ce n’est plus un micro-service isolé qui tombe. C’est la clé du château.

On peut discuter longtemps de la maturité des processus internes d’un géant. On peut aussi, plus utilement, se demander pourquoi tant d’entreprises n’ont aucun plan lorsque cette clé se bloque. La réponse est souvent prosaïque. Migrer vers Microsoft 365 a été un projet de deux ans. Documenter un mode dégradé a été un slide oublié dans un dossier de fin de projet. Tester réellement l’envoi de mails critiques hors de la suite a été reporté au trimestre suivant. Puis au suivant encore.

Startups, Scale-Ups Et Grands Comptes Face Au Même Mur

Le thème n’est pas seulement technologique. Il est organisationnel. Une jeune pousse de quinze personnes et un groupe de quinze mille salariés n’ont pas les mêmes ressources. Ils partagent pourtant le même réflexe : tout faire passer par la suite Office dans le nuage. Le pitch deck part d’Outlook. Le contrat circule dans SharePoint. La daily se tient sur Teams. Le support client archive ses tickets dans la même galaxie. Quand l’authentification se grippe, la petite structure improvise plus vite, mais elle a moins de marge. Un devis bloqué vingt-quatre heures peut faire rater un closing. Un mail de relance investisseur qui n’arrive pas peut sembler anodin. Il ne l’est pas toujours.

Les grands comptes, eux, ont des cellules de crise, des contrats de support premium, parfois des relais téléphoniques avec l’éditeur. Cela n’empêche pas les files d’attente internes, les directions métier qui exigent une explication toutes les heures, les usines qui ne reçoivent plus les ordres de fabrication par mail, les juristes qui ne peuvent pas extraire une pièce jointe. La taille protège contre le chaos total. Elle n’annule pas le coût d’une journée ralentie.

Entre les deux, les scale-ups vivent un entre-deux particulièrement inconfortable. Assez grandes pour que l’arrêt de la messagerie soit visible par les clients. Pas assez outillées pour disposer d’un vrai dispositif de continuité multi-cloud. C’est souvent là que l’on entend les phrases les plus sincères : « on savait que ça arriverait un jour » suivies de « on n’avait juste pas prévu que ce serait aujourd’hui ».

Pourquoi L’Authentification Est Le Cœur Du Problème

Il faut insister sur ce point, parce qu’il éclaire presque tous les autres. Dans l’architecture moderne de Microsoft 365, l’identité n’est pas un accessoire. Elle est le tissu conjonctif. Un utilisateur n’ouvre pas vraiment Outlook, Teams ou le centre d’administration comme des applications séparées. Il présente une preuve d’identité, obtient des jetons, puis circule. Si la configuration qui orchestre cette preuve est mal déployée, les symptômes se multiplient et semblent disparates. En réalité, ils ont la même racine.

C’est aussi pour cela que les mitigations prennent du temps. On ne « rallume » pas l’identité comme on rallume une imprimante. On doit s’assurer que les composants concernés atteignent enfin la portion d’infrastructure oubliée ou mal configurée, que les caches se rafraîchissent, que les clients lourds et les clients web se resynchronisent, que les files de mail ne créent pas un embouteillage au moment où le trafic revient. La télémétrie positive évoquée par Microsoft est précisément ce regard interne sur ces flux. Elle rassure l’éditeur. Elle reste abstraite pour la personne qui attend encore un accusé de réception.

Les responsables sécurité observent un autre angle. Pendant un incident d’identité, les tentatives de contournement se multiplient. On désactive temporairement une politique, on ouvre un accès d’urgence, on accepte un partage moins contrôlé « juste pour aujourd’hui ». Ces gestes sont humains. Ils laissent parfois des traces. Une panne d’authentification n’est donc pas seulement un problème de disponibilité. C’est une fenêtre pendant laquelle la discipline de sécurité se relâche, parfois de façon compréhensible, rarement de façon anodine.

Ce Que Les Équipes Ont Tenté Pendant L’Attente

Dans les entreprises, la première réaction a souvent été banale et efficace à court terme : vérifier le statut officiel, relancer le client Outlook, passer par le web, vider un cache, tester un autre navigateur, demander à un collègue si le phénomène était local. Puis vient le moment où l’on comprend que le problème n’est pas le poste de travail. On bascule alors vers des canaux de secours. Téléphone. SMS. Slack ou Discord pour celles et ceux qui en ont un. Messagerie personnelle, avec tous les risques de conformité que cela implique. Documents envoyés depuis un autre tenant, un autre fournisseur, un autre continent si besoin.

Certaines organisations avaient déjà prévu une adresse de bascule externe pour les urgences. D’autres ont découvert, en direct, que leur unique canal critique était précisément celui qui tombait. Les startups productives, celles qui documentent vraiment leurs process, s’en sortent mieux. Pas parce qu’elles sont plus brillantes. Parce qu’elles ont déjà écrit, noir sur blanc, comment prévenir un client si la suite cloud est indisponible. Ce n’est pas glamour. C’est décisif.

Il y a aussi ceux qui ont continué à travailler hors ligne, en local, en acceptant de synchroniser plus tard. Cette méthode ancienne redevient soudain moderne. Rédiger le contrat dans un fichier local. Préparer la présentation sans Copilot. Noter les décisions de réunion sur papier, puis les reporter. L’incident rappelle une vérité simple : la productivité assistée par le cloud est formidable tant que le cloud répond. Elle n’abolit pas le besoin de savoir travailler sans lui.

Recherche Cassée, Flux Rétabli : Le Piège Du Demi-Retour

Un détail de la chronologie mérite qu’on s’y arrête. Le flux de messagerie s’est amélioré avant la recherche. Autrement dit, on pouvait de nouveau envoyer et recevoir, tout en étant incapable de retrouver correctement un vieux fil, une pièce jointe, un interlocuteur. Pour beaucoup d’activités, c’est presque aussi bloquant qu’une coupure franche. Le commercial qui doit retrouver la dernière version d’une offre. Le support qui cherche un ticket d’il y a trois semaines. Le juriste qui piste une clause. La messagerie n’est pas seulement un tuyau. C’est une mémoire.

Ce demi-retour est psychologiquement usant. Les utilisateurs croient que « c’est réparé », tapent un mot-clé, n’obtiennent rien de fiable, et concluent que rien n’est fiable. La confiance se reconstruit plus lentement que les serveurs. Microsoft a raison de parler de surveillance prolongée. Une disponibilité qui remonte dans les graphiques internes ne signifie pas encore que l’expérience perçue est saine. Entre les deux, il y a les index, les caches, les réplicas, les clients qui gardent un état incohérent.

Les éditeurs de suites cloud sous-estiment parfois ce décalage. Les clients, eux, le vivent dans leur corps. Une réunion manquée se rattrape. Une recherche qui ment pendant une demi-journée crée des erreurs en cascade, des doublons, des relances inutiles, des décisions prises sans le bon document sous les yeux.

Dépendance Au Cloud Et Illusion De La Résilience Automatique

Depuis une décennie, le discours dominant a été celui de la résilience par construction. Des zones de disponibilité, des réplications, des SLA à plusieurs neuf après la virgule. Ces mécanismes sont réels. Ils protègent contre une foule de pannes matérielles. Ils protègent beaucoup moins contre une erreur de configuration globale ou semi-globale, précisément parce que la configuration, elle, est souvent conçue pour être cohérente partout. Ce qui fait la force d’une plateforme unifiée fait aussi sa fragilité : un mauvais paramètre se propage avec la même élégance qu’un bon paramètre.

Les startups qui construisent leur produit au-dessus de Microsoft 365 devraient relire cet incident comme un cas d’école. Si votre application métier s’appuie sur l’identité Microsoft, sur les mails Graph, sur les fichiers SharePoint, alors la panne de la plateforme n’est plus un événement extérieur. C’est une panne de votre produit. Le contrat de niveau de service que vous promettez à vos propres clients se retrouve plafonné par celui, implicite, de l’infrastructure d’en dessous.

On peut répondre à cela de plusieurs manières. Concevoir des modes dégradés. Mettre en cache localement certaines données non sensibles. Prévoir un second fournisseur d’identité pour les fonctions vitales. Accepter une architecture un peu moins élégante et un peu plus survivable. Aucune de ces options n’est gratuite. Toutes coûtent moins cher qu’une journée où l’on ne peut plus prouver qui l’on est devant son propre outil.

Comment Parler D’Un Incident Sans Promettre La Lune

La communication de Microsoft pendant cette séquence a suivi un schéma désormais familier aux observateurs du cloud. Constat, investigation, mitigation, télémétrie positive, monitoring étendu. Le ton est factuel, prudent, parfois un peu lisse. Il évite le mot « résolu » tant que les indicateurs ne le permettent pas. C’est préférable à un triomphalisme prématuré. Cela reste frustrant pour qui attend une heure de fin claire.

Les entreprises clientes devraient s’en inspirer en interne. Annoncer trop tôt que « Outlook est de retour » crée une seconde déception. Mieux vaut dire ce qui fonctionne, ce qui reste dégradé, ce que l’on recommande comme canal de secours, et à quelle fréquence l’on mettra à jour la consigne. Les startups qui parlent à leurs utilisateurs avec cette honnêteté-là sortent souvent grandies d’un incident qu’elles n’ont même pas causé. Celles qui disparaissent dans le silence laissent leurs clients imaginer le pire.

Un Tableau Pour Y Voir Plus Clair

Pour poser les faits sans les noyer, voici une lecture synthétique de l’épisode, telle qu’on peut la reconstituer à partir des informations publiques de début septembre 2026.

Ce Que Les Dirigeants Devraient Faire Cette Semaine

Inutile d’attendre le rapport post-mortem définitif pour agir. Quelques gestes concrets valent mieux qu’une longue discussion sur la souveraineté numérique, même si cette discussion a sa place. D’abord, identifier les trois flux vraiment vitaux : le mail qui fait entrer l’argent, le canal qui prévient un client d’un incident, le dépôt qui contient les documents que l’on ne peut pas perdre. Ensuite, écrire noir sur blanc comment ces trois flux survivent vingt-quatre heures sans Microsoft 365. Pas dans un discours. Dans une procédure courte, testée, connue de plus d’une personne.

Ensuite, regarder les droits d’administration. Pendant une crise d’identité, ceux qui peuvent encore se connecter au centre d’administration deviennent des personnages clés. S’ils sont en congés, si leurs comptes sont eux-mêmes bloqués, si personne n’a de numéro d’urgence éditeur, le temps se dilate. Les startups négligent souvent cette hygiène parce qu’elles sont petites. C’est précisément parce qu’elles sont petites qu’un seul compte cassé devient un drame.

Enfin, résister à la tentation du grand soir architectural. Changer de suite demain matin n’est pas une réponse. En revanche, réduire quelques dépendances absurdes l’est. Un formulaire critique qui n’existe que dans un flux Outlook. Une alerte de production qui ne part que par Teams. Un coffre-fort documentaire sans copie hors tenant. Ces nœuds se corrigent sans révolution.

• Cartographier les processus qui meurent si l’authentification Microsoft 365 échoue.
• Désigner un canal de crise extérieur à la suite, déjà connu des équipes.
• Tester une fois par trimestre l’envoi d’un message critique hors Outlook.
• Documenter qui peut parler à l’éditeur et qui décide d’un mode dégradé.
• Revenir, après l’incident, sur les contournements de sécurité improvisés.

Productivité, Copilot Et La Promesse D’Un Bureau Toujours Allumé

L’ironie de cet épisode, c’est qu’il survient à une époque où l’on pousse les assistants intégrés, les résumés automatiques, les brouillons générés, les recherches intelligentes. Copilot figure parmi les services affectés. Quand l’identité se dérobe, l’intelligence artificielle du bureau ne disparaît pas seulement comme gadget. Elle rappelle qu’elle n’est qu’une couche posée sur une infrastructure classique. Pas d’authentification, pas d’assistant. Pas de mail indexé, pas de résumé magique.

Les équipes qui avaient commencé à déléguer une partie de leur mémoire à ces outils ont ressenti un vide particulier. Non pas que l’outil soit indispensable à la pensée. Mais parce que les habitudes se forment vite. On ne cherche plus dans les dossiers. On interroge. On ne relit plus le fil. On demande un condensé. Lorsque la recherche est dégradée, c’est précisément cette nouvelle gymnastique qui se brise. Revenir au bon vieux tri manuel prend plus de temps qu’avant, parce que l’on a désappris une partie du geste.

Cela ne condamne pas l’assistance logicielle. Cela impose de la traiter comme un accélérateur, pas comme la seule mémoire de l’organisation. Les startups qui archivent encore leurs décisions dans un espace simple, exportable, recopiable, traversent mieux ce genre de trou d’air. Celles qui ont tout parié sur la magie d’un volet latéral s’aperçoivent que la magie a besoin d’électricité.

Faut-Il Fuir La Suite, Ou Apprendre À Vivre Avec ?

Chaque panne visible relance le débat sur la diversification. Google Workspace. Boîtes autonomes. Messageries souveraines. Outils de réunion séparés. Identité gérée ailleurs. Ces options existent. Elles ont leurs propres pannes, leurs propres contrats, leurs propres angles morts. Changer de cathédrale n’abolit pas le risque de la cathédrale. En revanche, refuser de tout empiler dans la même nef reste une stratégie raisonnable.

Pour une majorité d’organisations, Microsoft 365 demeurera le socle. La question n’est donc pas « faut-il partir ». La question est « que fait-on quand le socle tremble ». Les entreprises les plus adultes ne promettent pas l’invulnérabilité. Elles promettent un temps de reconnexion, un message clair aux clients, une capacité à facturer et à livrer même si la recherche Outlook est capriceuse pendant une nuit.

Les fondateurs qui pitchent leur startup comme « native Microsoft 365 » devraient ajouter une phrase moins vendeuse et plus vraie : nous savons travailler si la plateforme vacille. Cette phrase-là, aucun investisseur ne la demandera le premier jour. Tous la comprendront le jour où leur propre boîte mail d’entreprise restera muette jusqu’à midi.

Ce Que Cet Incident Dit De L’Époque

Nous travaillons dans un monde où l’on peut lancer une entreprise sans acheter un seul serveur, où l’on signe des contrats depuis un café, où l’assistant rédige la première version du mail difficile. C’est une époque formidable. Elle produit aussi une vulnérabilité collective. Quelques configurations, chez quelques opérateurs, tiennent debout une part immense du commerce quotidien. Ce n’est ni un complot ni une fatalité. C’est un choix industriel que l’on a fait parce qu’il était commode, puissant, souvent moins cher que l’alternative artisanale.

La panne de début septembre 2026 n’est pas la première et ne sera pas la dernière. Sa particularité tient à cette combinaison : une cause relativement prosaïque, une durée qui dépasse la simple matinée, une liste de services plus longue que le seul Outlook, et une communication qui assume le « pas encore tout à fait ». Les organisations qui en tireront un plan d’une page auront gagné quelque chose. Celles qui n’en garderont qu’un souvenir agacé recommenceront la même improvisation à la prochaine occase.

Il reste une note presque réconfortante. Les mitigations ont produit des effets. La télémétrie est devenue meilleure. La recherche a fini par reprendre des couleurs. Le service, selon l’éditeur, s’améliore. Des millions de personnes ont pu, au fil des heures, retrouver un semblant de journée normale. Le cloud n’est pas une illusion. Il est simplement imparfait, comme l’étaient les salles machines d’autrefois, avec une différence de taille : quand il tombe, il tombe pour beaucoup de monde en même temps.

Garder La Tête Froide Après Le Redémarrage

Le moment le plus délicat d’un incident n’est pas toujours le plus bruyant. C’est celui où tout semble revenir. Les boîtes se remplissent d’un coup. Les notifications longtemps retenues arrivent en grappe. Les utilisateurs rouvrent dix onglets. Les files se vident mal. On croit tourner la page alors que le système digère encore le retard. C’est précisément pour cela que Microsoft parle d’une période de surveillance étendue. Les équipes internes devraient faire de même : ne pas déclarer la victoire trop vite, observer les files, vérifier les envois critiques, s’assurer que la recherche dit vrai, reprendre un à un les contournements ouverts pendant la tempête.

Un incident d’authentification laisse parfois des comptes dans un état bizarre, des sessions orphelines, des applications métier qui gardent un jeton périmé. Un passage en revue après coup évite que la panne initiale se transforme en une série de petits incidents privés, moins visibles, tout aussi pénibles. Les startups pressées sauteront cette étape. Elles le paieront en tickets épars pendant une semaine.

On peut aussi en profiter pour parler vrai avec les métiers. Expliquer qu’un outil central n’est pas une assurance-vie. Montrer la page de statut. Relire ensemble la procédure de crise. Décider, sans lyrisme, ce que l’on accepte de perdre pendant quatre heures et ce que l’on refuse de perdre même pendant vingt minutes. Ce débat est plus utile que la recherche d’un coupable dans une configuration que personne, en interne, n’a écrite.

Pour Ne Pas Refermer Le Sujet Trop Vite

Au moment où ces lignes sont écrites, le message officiel n’est pas celui d’une résolution totale. C’est celui d’un mieux, d’une infrastructure encore partiellement concernée, d’une vigilance qui continue. Cette prudence devrait inspirer le ton de tous ceux qui commentent l’affaire. Pas de triomphe. Pas de procès d’intention. Un constat : une suite devenue indispensable a vacillé à cause d’un problème d’identité, et le monde du travail l’a immédiatement senti.

Si vous dirigez une équipe, posez aujourd’hui trois questions simples. Que se passe-t-il si Outlook ne part plus demain matin ? Qui prévient nos clients, et par quel canal ? Quelle preuve d’identité de secours avons-nous si le mécanisme central refuse de déployer ses composants ? Les réponses tiendront sans doute sur une feuille. Cette feuille vaudra plus que bien des tableaux de bord verts.

La technologie d’entreprise n’a pas besoin de mythes. Elle a besoin de clarté. Microsoft 365 reste un outil immense, souvent excellent, parfois indisponible. L’incident de ces derniers jours n’efface pas ses qualités. Il rappelle seulement le prix de la commodité. On gagne du temps tous les jours. On en rend une partie, d’un seul coup, lorsque la configuration d’authentification décide de ne plus se déployer comme prévu. À chacun de décider si ce marché reste acceptable, et surtout, comment le rendre un peu moins brutal la prochaine fois.