Publié le 1 novembre 2026 · L'équipe mitza.es
Quand un service cloud tombe, le problème est rarement « le nôtre » : la panne arrive de l'extérieur, sans prévenir, et on ne peut pas la réparer. Mais c'est l'entreprise qui décide si, ce jour-là, elle vend, facture et sert ses clients, ou si elle attend devant un écran. Ce guide part de trois pannes réelles de l'automne 2025, explique ce qu'elles enseignent et propose un plan de continuité qu'une PME peut mettre en place avec peu de budget.
Trois pannes en moins d'un mois
- AWS, 20 octobre 2025 (région US-EAST-1) : un problème dans le système de noms (DNS) du service de base de données DynamoDB, qui, selon l'analyse d'AWS, trouvait son origine dans une condition de concurrence latente dans son automatisation, a laissé un enregistrement DNS vide et s'est propagé à d'autres services. Il a touché des applications aussi diverses que Slack, Atlassian, Snapchat ou Roblox, pendant plusieurs heures.
- Microsoft Azure, 29 octobre 2025 : une modification de configuration involontaire dans Azure Front Door, le service qui distribue le trafic de nombreuses applications, a laissé des nœuds sans chargement correct. Elle a touché Microsoft 365, son centre d'administration et des services comme Xbox ou Minecraft. Microsoft a bloqué les nouvelles modifications de configuration et est revenu à la dernière configuration valide. Les sources situent l'incident à environ huit ou neuf heures, avec de légères différences d'horaire.
- Cloudflare, 18 novembre 2025 : une modification des autorisations d'une base de données a doublé la taille d'un fichier de configuration du système de gestion des bots ; en dépassant une limite interne, les serveurs proxy ont planté. Elle a laissé sans réponse, entre autres, des plateformes comme X, ChatGPT, Spotify ou Canva pendant environ trois heures. Cloudflare a précisé qu'il ne s'agissait pas d'une attaque.
Dans les trois cas, l'origine était une erreur interne ou une modification de configuration, pas un piratage. Et dans les trois, la leçon est la même : vous dépendez de fournisseurs très fiables, mais pas infaillibles. Nous avons aussi vu des effets similaires avec des outils précis, comme les pannes de ChatGPT d'août 2026.
Combien coûte réellement une heure d'arrêt
Avant de concevoir quoi que ce soit, calculez le coût de l'arrêt de chaque service pendant une heure : les ventes qui ne se font pas, les commandes qui ne peuvent pas être traitées, les factures qui ne partent pas, les personnes payées qui ne peuvent pas travailler et les clients qui vont voir ailleurs. Nul besoin de précision : un ordre de grandeur suffit pour décider dans quoi il vaut la peine d'investir un plan B et dans quoi non.
Étape 1 : la cartographie des dépendances
Dressez la liste de tout ce que votre entreprise utilise dans le cloud ou par internet, et pour chaque élément notez qui l'héberge et ce qui se passerait s'il tombait pendant quatre heures :
- Messagerie et agenda.
- Logiciel de facturation, ERP ou CRM.
- Terminal de paiement et passerelle de paiement.
- Site web et boutique en ligne (et le service qui diffuse leurs images ou leur DNS).
- Fichiers partagés et documents.
- Téléphonie et messagerie instantanée (WhatsApp, Teams, Meet…).
- Outils d'intelligence artificielle, de pointage, de paie, etc.
Souvent, la découverte est inconfortable : plusieurs services dépendent, à votre insu, du même fournisseur en arrière-plan.
Étape 2 : décidez ce qui est critique et définissez un plan B par service
- Messagerie : si votre fournisseur tombe, comment le client peut-il continuer à vous joindre ? Ayez un canal alternatif (téléphone, WhatsApp professionnel) et faites-le savoir. Envisagez un accès par navigateur en plus du logiciel de bureau.
- Ventes et encaissements : existe-t-il un autre moyen d'encaisser (terminal de paiement avec une autre connexion, Bizum, virement) ? Pouvez-vous noter les commandes à la main et les enregistrer ensuite ?
- Site et boutique : préparez une page statique d'information que vous pouvez publier ailleurs et sachez qui contrôle votre DNS. Nous expliquons cette partie dans nom de domaine et hébergement.
- Fichiers : conservez une copie synchronisée des documents critiques en local ou sur un NAS pour pouvoir les ouvrir sans internet.
- Communication interne : convenez à l'avance de la manière dont l'équipe est prévenue quand l'outil habituel tombe en panne.
Étape 3 : des copies indépendantes de vos données
La panne d'un fournisseur est temporaire, mais si tout ce que vous avez est chez lui, votre marge de manœuvre est nulle. Une copie indépendante et testée, selon la règle 3-2-1 des sauvegardes, est la base de tout plan de continuité. Si vous utilisez du stockage cloud, rappelez-vous que synchroniser n'est pas sauvegarder.
Étape 4 : connexion et électricité
Toutes les pannes ne viennent pas du cloud. Une ligne internet de secours (4G/5G) coûte peu et évite de nombreux arrêts ; un onduleur protège les équipements et les disques des coupures de courant. Vérifiez aussi ce qui se passe si la fibre tombe : le terminal de paiement, le routeur de secours et les mobiles continuent-ils de fonctionner ?
Étape 5 : communication en cas de panne
- Préparez à l'avance une note pour les clients (« nous subissons un incident chez un fournisseur ; nous répondons par… »).
- Décidez qui l'envoie et par quel canal (réseaux, téléphone, affiche, message automatique).
- Consultez les pages d'état officielles de vos fournisseurs avant de présumer que la panne vient de chez vous.
- Notez ce qui a été perdu (commandes, heures) pour réclamer des crédits de service ou ajuster le plan.
Contrats et garanties : ce qu'ils promettent réellement
Les grands fournisseurs publient des accords de niveau de service (SLA), mais le plus souvent la compensation consiste en crédits de service, pas en une indemnisation de vos pertes. Lisez ce qu'ils garantissent, à partir de quand ils comptent une panne et comment on demande le crédit. Et si vous dépendez d'un seul service pour facturer, demandez-vous s'il vaut la peine de souscrire de la redondance ou de maintenir une alternative de base.
Étape 6 : testez le plan une fois par an
Un plan qui n'a jamais été répété échoue généralement le jour où il faut. Consacrez une heure par an à simuler une panne : éteignez le service principal « sur le papier » et vérifiez que chacun sait quoi faire, que les copies se restaurent et que les téléphones et accès alternatifs fonctionnent.
Erreurs courantes
- Croire que « le cloud » inclut déjà la continuité d'activité.
- Avoir la messagerie, le site et le DNS chez le même fournisseur, sans accès alternatif.
- Ne pas savoir qui détient les identifiants du domaine ni comment on change le DNS.
- N'avoir jamais testé la restauration d'une sauvegarde.
- Communiquer tard ou sans transparence avec les clients.
- Investir dans la redondance d'un service peu important et laisser le service critique sans plan B.
Lien avec votre stratégie cloud
Tout cela n'est pas un argument contre le cloud : pour la plupart des PME, il reste plus fiable et moins cher qu'un serveur à soi. C'est un argument pour l'utiliser les yeux ouverts. Si vous voulez le panorama complet des modèles, des avantages et des risques, lisez notre guide du cloud computing pour PME.
Comment Mitza peut vous aider
Nous vous aidons à construire la cartographie des dépendances, à définir le plan B de ce qui est critique et à préparer les sauvegardes et les accès alternatifs. Si vous êtes dans le sud de Madrid, consultez notre service de maintenance informatique ou écrivez-nous depuis la page de contact.