Votre plan de continuité parle-t-il des pannes du mardi après-midi ?

Votre équipe logistique ne peut plus valider les expéditions. Le logiciel métier affiche une erreur depuis le déjeuner. Ce n’est ni une inondation ni une cyberattaque nationale : c’est une mise à jour qui a mal tourné, ou un service cloud qui ne répond plus. Pourtant les camions attendent, les clients appellent, et personne ne sait qui a le droit de basculer sur Excel ou de repousser les livraisons.

Les scénarios « banals » qui font mal

Dans une tribune publiée le 2 novembre 2026 sur ZDNet France, Matt Riley, responsable européen de la sécurité de l’information chez Sharp, insiste sur un décalage fréquent : les plans de continuité d’activité (PCA) décrivent des catastrophes — attaques massives, incendies, inondations — alors que l’entreprise subit surtout des pannes courantes : correctif défaillant, coupure chez un fournisseur, système clé hors ligne sans explication. Aucun de ces événements n’a besoin d’être spectaculaire pour créer des dommages réels. Quand le système qui pilote les livraisons tombe, l’impact est immédiat. Deux heures d’indisponibilité un mardi après-midi peuvent coûter plus cher — commandes perdues, clients mécontents — qu’un incident très médiatisé survenant un week-end.

Réagir d’abord, reprendre ensuite

Riley distingue deux registres souvent mélangés. La réaction, c’est l’immédiat : contenir le problème, en comprendre la cause, en général via un plan de gestion des incidents tenu par l’informatique. La reprise d’activité, c’est ce qui vient après la stabilisation : restaurer systèmes, données et services dans un ordre établi pour retrouver un fonctionnement normal. Le PCA doit couvrir les deux volets — une feuille de route pour revenir à la normale une fois la pression retombée, pas seulement une procédure d’urgence technique.

Priorités et décideurs : avant, pas pendant

Construire un PCA commence par lister processus, systèmes et fournisseurs dont vous dépendez — tout n’a pas la même criticité. Riley cite le cycle commercial automatisé de bout en bout et la rupture d’un fournisseur stratégique : les deux méritent une réponse prévue, pas une improvisation. L’analyse d’impact (imaginer l’arrêt soudain de chaque processus clé) paraît formelle, mais l’essentiel est de la mener avant la panne. Autre point sensible : si seul le dirigeant peut autoriser le verrouillage des systèmes lors d’une cyberattaque, l’entreprise peut rester paralysée s’il est injoignable. Recours à un processus manuel, information des clients en cas de retard, suppléant désigné : tout cela se décide à froid. Riley rappelle aussi que la communication — clients, partenaires, parties prenantes — doit être planifiée (quoi dire, quand).

• Nommer un ordre de reprise : quel service remonte en premier (facturation, stock, messagerie) et qui valide chaque étape.
• Tester ou relire le plan régulièrement, même brièvement : un PCA jamais exercé n’est pas opérationnel.
• Prévoir le mode dégradé : qui sait contourner avec un fournisseur alternatif ou une saisie manuelle, et combien de temps cela tient.
• Vérifier les dépendances : un prestataire cloud ou un éditeur SaaS compte comme un maillon du PCA, pas seulement vos serveurs.

Si votre PCA ne mentionne que des catastrophes et jamais la panne du mardi, on peut le relire ensemble et choisir un premier exercice court.