Votre entreprise peut-elle survivre à 48 heures sans informatique ?

Dans une PME, les systèmes informatiques sont devenus indispensables à presque toutes les activités.

Un bureau d'architectes peut perdre l'accès à ses plans, ses maquettes BIM et ses dossiers de chantier.

Une fiduciaire peut se retrouver incapable d'accéder aux documents comptables de ses clients ou de respecter certaines échéances.

Une entreprise industrielle peut voir sa production ralentie ou arrêtée si ses applications de gestion ou de pilotage deviennent indisponibles.

Une société de services peut perdre temporairement l'accès à son CRM, ses plannings, ses contrats et sa facturation.

Dans chacun de ces exemples, le problème dépasse rapidement le service informatique.

Il touche les collaborateurs, les clients, les fournisseurs et parfois la réputation de l'entreprise.

Une panne de serveur peut se réparer. Les conséquences commerciales d'une interruption prolongée sont parfois beaucoup plus difficiles à rattraper.

Prenons l'exemple fictif d'une PME de 25 collaborateurs.

Supposons que 20 personnes soient fortement dépendantes de l'informatique et que leur coût complet moyen représente CHF 65 par heure.

Sur deux journées de huit heures, le coût théorique du temps de travail affecté représente :

20 collaborateurs × 16 heures × CHF 65 = CHF 20'800.

Ce montant est une illustration, pas une estimation universelle de perte financière.

Une partie du personnel peut poursuivre d'autres tâches, certaines heures peuvent être récupérées et tout le temps indisponible ne se transforme pas automatiquement en perte nette.

À l'inverse, ce calcul n'intègre pas :

• Le chiffre d'affaires potentiellement perdu.
• Les commandes ou livraisons retardées.
• Les interventions techniques exceptionnelles.
• Les pénalités contractuelles éventuelles.
• Les coûts de reconstitution de données.
• Les conséquences pour les clients.
• Le temps nécessaire pour résorber le retard.

Le véritable impact dépend donc du secteur d'activité, de la période et des processus concernés.

Mais cet exercice révèle une chose : le coût d'une interruption informatique ne se limite jamais à la facture du prestataire chargé de remettre les systèmes en service.

C'est probablement l'une des confusions les plus fréquentes.

Une entreprise peut effectuer des sauvegardes quotidiennes et se retrouver malgré tout incapable de reprendre son activité avant plusieurs jours.

Pourquoi ?

Parce que sauvegarder des données et restaurer un environnement de production sont deux opérations différentes.

Imaginons que votre serveur principal tombe définitivement en panne.

Vous disposez d'une sauvegarde parfaitement fonctionnelle.

Excellente nouvelle.

Mais sur quelle infrastructure allez-vous la restaurer ?

Disposez-vous d'un serveur de remplacement ?

Les ressources nécessaires sont-elles disponibles ?

Combien de temps faudra-t-il pour reconstruire les machines virtuelles, restaurer les bases de données, reconfigurer les accès et valider les applications ?

Et surtout : avez-vous déjà testé cette procédure ?

Une sauvegarde réussie ne garantit ni une restauration réussie, ni une reprise rapide de l'activité.

C'est précisément pour cela qu'une véritable stratégie de continuité doit aller au-delà de la simple sauvegarde.

Ces acronymes sont techniques, mais les concepts sont simples.

Le RTO : combien de temps pouvez-vous rester à l'arrêt ?

Le Recovery Time Objective définit le délai maximal ciblé pour rétablir un service après une interruption.

Par exemple, si votre application de facturation possède un RTO de quatre heures, votre organisation doit disposer de moyens permettant de viser une reprise dans ce délai.

Un RTO n'est toutefois pas une garantie automatique : il doit être réaliste, documenté et validé par des tests.

Le RPO : combien de données pouvez-vous accepter de perdre ?

Le Recovery Point Objective représente la perte maximale de données admissible, exprimée en durée.

Si votre RPO est d'une heure, votre stratégie doit permettre de récupérer des données datant de moins d'une heure avant l'incident, dans les scénarios couverts.

À l'inverse, une sauvegarde effectuée une fois par jour peut exposer l'entreprise à une perte de données allant jusqu'à environ 24 heures selon le moment de l'incident.

Un exemple concret

Pour une PME, les objectifs pourraient être les suivants :

Ces valeurs sont uniquement des exemples. Elles doivent être définies selon les besoins réels de chaque entreprise.

L'essentiel est de comprendre qu'on ne protège pas tous les systèmes de la même façon.

Une application qui conditionne directement le chiffre d'affaires ne devrait pas nécessairement avoir les mêmes objectifs de reprise qu'un outil utilisé occasionnellement.

On entend souvent parler de PRA, le Plan de Reprise d'Activité.

Son objectif est d'organiser le rétablissement des systèmes après un incident majeur.

Il définit notamment les priorités de restauration, les dépendances techniques, les responsabilités, les procédures et les ressources nécessaires.

Mais il existe une autre notion tout aussi importante : le PCA, ou Plan de Continuité d'Activité.

La distinction mérite d'être comprise.

Le PRA répond à la question : comment redémarrer ?

Le PCA répond à la question : comment continuer à travailler pendant l'incident ?

Par exemple, si votre ERP est indisponible, votre entreprise dispose-t-elle d'une procédure temporaire pour enregistrer les commandes ?

Si les fichiers ne sont plus accessibles, certaines activités peuvent-elles être poursuivies avec des documents disponibles hors ligne ?

Si la messagerie tombe, existe-t-il un canal de communication alternatif connu des collaborateurs ?

Qui décide des priorités ?

Qui informe les clients ?

Qui coordonne les prestataires ?

Un plan de continuité efficace ne dépend pas uniquement de l'informatique.

Il implique aussi la direction, les responsables métier et les collaborateurs.

Migrer ses applications vers Microsoft 365, Azure ou un autre fournisseur cloud peut améliorer la résilience de certains services.

Mais cela ne signifie pas que l'entreprise devient automatiquement insensible aux incidents.

Une panne de connexion Internet, une indisponibilité du fournisseur, une mauvaise configuration, une suppression accidentelle ou une compromission de compte peuvent toujours perturber les opérations.

Le cloud déplace une partie des responsabilités techniques.

Il ne supprime pas les dépendances ni la nécessité de prévoir des procédures de continuité.

De la même manière, une infrastructure locale peut offrir une excellente disponibilité si elle dispose de redondance, de sauvegardes adaptées et de mécanismes de reprise éprouvés.

Le sujet n'est donc pas de savoir où se trouvent vos serveurs, mais comment votre entreprise réagit lorsque les services dont elle dépend deviennent indisponibles.

Documenter des procédures constitue une première étape.

Mais un document n'a jamais redémarré un serveur à lui seul.

Un plan de reprise doit être testé.

Cela peut commencer simplement, avec la restauration d'un fichier ou d'une machine virtuelle dans un environnement isolé.

Puis évoluer vers des scénarios plus complets :

• Perte d'un serveur critique.
• Corruption d'une base de données.
• Indisponibilité du site principal.
• Compromission de comptes administrateurs.
• Restauration après une attaque par ransomware.
• Perte de connectivité ou indisponibilité d'un fournisseur.

Ces exercices permettent de mesurer les délais réellement observés, de vérifier les dépendances et d'identifier les points faibles.

Ils mettent souvent en évidence des questions auxquelles personne n'avait pensé.

Un logiciel nécessite-t-il une licence spécifique pour redémarrer ?

Une application dépend-elle d'un autre serveur ?

Qui possède les identifiants nécessaires ?

La documentation est-elle accessible même lorsque l'infrastructure principale est indisponible ?

Qui valide que les données restaurées sont exploitables ?

Le bon moment pour découvrir les limites de son plan de reprise, c'est pendant un exercice. Pas pendant une crise.

Vous n'avez pas besoin d'être ingénieur système pour évaluer la préparation de votre entreprise.

Commencez par ces questions :

1. Quels sont les trois systèmes informatiques sans lesquels notre activité ne peut pas fonctionner ?

2. Combien de temps pouvons-nous accepter leur indisponibilité ?

3. Quelle quantité de données pouvons-nous perdre sans mettre notre activité en difficulté ?

4. Quand avons-nous effectué notre dernier test de restauration et quels résultats avons-nous obtenus ?

5. Qui prend les décisions et comment communiquons-nous en cas d'incident majeur ?

6. Disposons-nous d'un plan documenté, accessible et réellement applicable ?

Si vous ne connaissez pas les réponses, cela ne signifie pas nécessairement que votre informatique est mal gérée.

Mais cela signifie qu'un travail d'évaluation mérite probablement d'être engagé.

On ne peut pas demander à une équipe IT de garantir un redémarrage en une heure sans lui donner les moyens techniques et financiers d'y parvenir.

La haute disponibilité, la réplication, les sauvegardes fréquentes, les infrastructures de secours et les tests réguliers ont un coût.

Et tous les systèmes ne justifient pas le même investissement.

C'est pourquoi les objectifs de continuité doivent être définis avec les responsables métier et validés par la direction.

Le rôle du prestataire informatique est de traduire ces objectifs en solutions réalistes, d'en expliquer les limites et de vérifier régulièrement leur efficacité.

La direction, elle, doit arbitrer entre les coûts, les risques et les conséquences acceptables pour l'entreprise.

Ce dialogue est indispensable.

Nous investissons dans des pare-feu, des antivirus, des sauvegardes, des licences et des services cloud.

Ces investissements sont nécessaires.

Mais une question reste trop souvent sans réponse :

Si tout s'arrête demain matin, savons-nous exactement comment et dans quels délais notre entreprise pourra reprendre son activité ?

La résilience informatique ne se mesure pas uniquement au nombre de technologies installées.

Elle se mesure à la capacité d'anticiper les incidents, de limiter leur impact et de rétablir les activités essentielles dans des délais maîtrisés.

Un bon partenaire informatique ne devrait pas seulement être capable de résoudre un incident.

Il devrait également aider l'entreprise à s'y préparer avant qu'il ne survienne.

Parce que le jour où tout s'arrête, il est trop tard pour commencer à réfléchir à la reprise.

Après des années dans l'administration des systèmes, des réseaux et la gestion des opérations informatiques, je reste convaincu d'une chose : la continuité d'activité n'est pas un sujet réservé aux grandes entreprises. C'est un enjeu de gouvernance pour chaque PME qui dépend de son informatique.

Et vous, si vos systèmes informatiques devenaient indisponibles pendant 48 heures dès lundi matin, votre entreprise serait-elle capable de continuer à fonctionner ?

#ContinuiteActivite #Cybersecurite #InfrastructureIT #PME #PRA