Combien de temps pouvez-vous travailler sans informatique ? La méthode simple pour évaluer votre vraie tolérance à l’arrêt

Dans beaucoup de PME, la question ne se pose jamais clairement. On sait qu’une panne serait gênante, parfois très gênante, mais personne n’a vraiment chiffré combien de temps l’entreprise peut continuer à fonctionner si l’ERP n’est plus accessible, si les postes deviennent inutilisables ou si un site distant perd sa connexion. Le plus souvent, on découvre la réponse le jour où tout s’arrête. ⚠️

Sur le terrain, les blocages ne viennent pas uniquement d’une grosse panne serveur. Une simple coupure Internet sur un site isolé, un VPN instable, une sauvegarde incomplète, un pare-feu saturé ou un applicatif métier qui ralentit peuvent suffire à désorganiser la production, retarder les expéditions, empêcher la saisie administrative ou bloquer la facturation. Et là, les heures perdues deviennent vite des coûts cachés.

La bonne approche n’est pas de partir de la technique, mais de l’activité réelle. Avant de parler PRA, supervision, redondance ou infogérance, il faut répondre à une question simple : combien de temps pouvez-vous réellement travailler sans informatique, sans impact majeur sur votre entreprise ?

Commencez par raisonner métier, pas infrastructure

L’erreur classique consiste à lister des serveurs, des licences, des switchs ou des applications sans relier cela au fonctionnement concret de l’entreprise. Pourtant, ce n’est pas un routeur ou un hyperviseur qui perd de l’argent quand ça tombe : ce sont vos équipes qui ne produisent plus, vos commerciaux qui ne répondent plus, votre atelier qui attend une information, votre ADV qui ne facture plus.

Pour évaluer votre tolérance à l’arrêt, partez donc des activités essentielles. Par exemple : prendre des commandes, lancer une production, imprimer des bons, expédier, assurer le SAV, accéder aux données techniques, établir la paie ou encaisser les règlements. Pour chacune, posez une question très directe : si cette activité s’arrête à cause de l’informatique, au bout de combien de temps la situation devient-elle critique ?

Dans une PME industrielle, un arrêt de deux heures sur la messagerie peut être absorbé. En revanche, une indisponibilité de l’ERP de gestion d’entreprise pendant la même durée peut déjà désorganiser un atelier entier. À l’inverse, dans une structure multisite avec équipes mobiles, la connectivité et les accès VPN deviennent parfois plus critiques que le serveur local lui-même. 🔧

Une panne informatique n’est jamais seulement un problème technique : c’est d’abord un arrêt ou une dégradation de vos processus métier.

La méthode simple : activité, dépendance, délai maximum acceptable

Une méthode efficace consiste à construire une grille très simple, sans chercher tout de suite la perfection. L’objectif est d’identifier les dépendances critiques et de leur associer un délai maximum acceptable d’interruption. Vous pouvez faire cet exercice en réunion courte, avec un dirigeant, un responsable métier, la production, l’administratif et l’IT. 🤝

• Colonne 1 : l’activité métier concernée
• Colonne 2 : les outils, applications, accès réseau ou équipements indispensables
• Colonne 3 : le temps d’arrêt acceptable avant impact majeur
• Colonne 4 : les conséquences concrètes si l’arrêt se prolonge

Le point clé est de rester concret. “Impact majeur” doit vouloir dire quelque chose : commandes non saisies, production ralentie, équipe inactive, données non accessibles, clients non informés, pénalités contractuelles, trésorerie décalée. Si vous restez sur des formules vagues, vous ne prioriserez rien correctement.

En général, les seuils utiles sont simples : moins d’une heure, quatre heures, une journée, quarante-huit heures. Au-delà, la question n’est plus seulement technique, elle devient organisationnelle. Si votre entreprise ne supporte pas plus d’une heure de coupure sur certains flux, vos besoins en supervision, redondance et support ne sont évidemment pas les mêmes que si vous pouvez fonctionner en mode dégradé jusqu’au lendemain. 📉

Cette logique rejoint d’ailleurs les notions de PRA et PCA informatique, qui consistent à aligner les moyens techniques sur le niveau réel d’exigence de continuité de l’entreprise.

Évaluez séparément les sites, les applications et les accès réseau

Une autre erreur fréquente consiste à penser la continuité d’activité comme un bloc unique. En réalité, la tolérance à l’arrêt n’est pas la même selon les sites, les équipes et les usages. Un siège administratif, un atelier de production, un dépôt logistique ou un site technique isolé n’ont ni les mêmes contraintes ni les mêmes dépendances.

Dans les environnements techniques ou industriels, la connectivité est souvent sous-estimée. Quand un parc photovoltaïque, un parc éolien, une station distante ou un site sans fibre fiable perd sa liaison, le problème n’est pas seulement “Internet ne marche plus”. Cela peut vouloir dire plus de télésurveillance, plus d’accès distant sécurisé, plus de remontée d’alertes, plus de diagnostic rapide. Sur certains sites, quelques heures sans visibilité suffisent à créer un vrai risque opérationnel.

Il faut donc isoler trois niveaux d’analyse : le site, l’application et le lien. Un ERP peut être parfaitement hébergé et sauvegardé, mais devenir inutilisable si le WAN est instable. À l’inverse, un site peut rester connecté, mais être paralysé parce que l’impression d’étiquettes, l’accès à un lecteur réseau ou un serveur local ne répond plus. C’est souvent dans ces dépendances terrain que se cachent les vraies fragilités.

Pour les organisations réparties, une réflexion sur l’interconnexion multi-sites et sur la résilience des liens réseau apporte souvent des gains immédiats en continuité d’activité.

Repérez ce qui fait perdre du temps avant même la panne totale

Une entreprise ne bascule pas toujours d’un fonctionnement normal à un arrêt complet. Très souvent, la dégradation commence avant : lenteurs réseau, sessions VPN qui tombent, sauvegardes qui échouent sans alerte, serveur saturé, Wi-Fi instable dans l’atelier, routeur 4G en limite de couverture, poste critique non remplacé à temps. Ce ne sont pas encore des sinistres, mais ce sont déjà des pertes de performance.

Dans une évaluation sérieuse, il faut donc intégrer non seulement le temps d’arrêt total acceptable, mais aussi le temps de fonctionnement dégradé acceptable. Une application qui répond avec trente secondes de retard à chaque action pendant une journée entière peut coûter presque autant qu’une panne franche de deux heures. Le problème, c’est que ce coût est moins visible. Il se dilue dans les retards, l’agacement des équipes et les tâches reportées. 🕒

Cette étape est importante pour prioriser la supervision. Si vous ne surveillez que les pannes franches, vous passez à côté d’une partie importante de la réalité vécue par les utilisateurs. Or, dans une PME, les signaux faibles sont souvent ceux qui annoncent la vraie coupure à venir.

Le vrai coût d’une panne commence souvent avant l’arrêt total, quand les outils ralentissent suffisamment pour désorganiser le travail sans déclencher d’alerte majeure.

Pour objectiver ce diagnostic, vous pouvez aussi vous appuyer sur les recommandations de l’ANSSI sur la résilience et l’hygiène informatique, ainsi que sur les bonnes pratiques de CISA en matière de continuité et de réponse aux incidents.

Traduisez le diagnostic en priorités d’infogérance, de sauvegarde et de PRA

Une fois votre tolérance à l’arrêt clarifiée, les décisions techniques deviennent beaucoup plus simples. Si une activité ne peut pas être interrompue plus d’une heure, il faut des moyens cohérents avec cette exigence : supervision active, support réactif, sauvegardes vérifiées, scénarios de reprise testés, connectivité sécurisée et parfois redondée. Si vous pouvez absorber une demi-journée de coupure sur un périmètre non critique, l’investissement ne sera pas le même.

• Tolérance faible : supervision renforcée, support prioritaire, PRA documenté, restauration testée, liens de secours
• Tolérance moyenne : sauvegardes contrôlées, surveillance standard, procédures de contournement, matériel de remplacement identifié
• Tolérance élevée : couverture de base, documentation claire, reprise planifiée sans surdimensionner les moyens

C’est aussi à ce moment que le modèle d’infogérance informatique prend tout son sens. Un forfait mensuel bien défini n’a de valeur que s’il est aligné sur vos contraintes réelles d’exploitation. Sinon, vous payez parfois pour des services inutiles sur certains périmètres, tout en restant insuffisamment protégé sur les fonctions vraiment critiques.

Dans les environnements multisites ou industriels, cette logique doit inclure les routeurs, VPN, SIM M2M, réseaux de terrain et solutions de secours opérateur. Une stratégie de continuité crédible ne peut pas se limiter au serveur central si l’activité dépend de sites distants ou d’équipements connectés. 🌐

La vraie question n’est pas “sommes-nous couverts ?” mais “jusqu’à quand tenons-nous ?”

Beaucoup d’entreprises pensent être raisonnablement protégées parce qu’elles ont des sauvegardes, un prestataire, un antivirus et une connexion Internet correcte. Mais cela ne répond pas à la question centrale. En cas d’incident, combien de temps vos équipes peuvent-elles continuer à travailler avant que la situation devienne coûteuse, tendue ou ingérable ?

Mesurer cette tolérance à l’arrêt oblige à regarder le SI comme un outil de continuité d’activité, pas seulement comme un empilement de solutions techniques. C’est un exercice simple en apparence, mais très révélateur. Il met souvent en lumière des écarts entre la perception de la direction, la réalité du terrain et les capacités réelles du support informatique.

Quand ce travail est fait proprement, vous savez où investir en priorité, quoi superviser vraiment, quels scénarios de reprise préparer et quels sites nécessitent une attention particulière. En clair, vous passez d’une impression de résilience à une continuité d’activité réellement pilotée. ✅

Si vous n’avez jamais formalisé ce diagnostic, un atelier court suffit souvent à faire émerger les points de rupture les plus sensibles. Et dans bien des cas, ce sont ces arbitrages simples qui évitent ensuite les interruptions les plus coûteuses.