Combien de temps votre entreprise peut-elle tenir sans son informatique ?

Un plan de reprise d’activité existe, quelque part, dans beaucoup de PME. C’est souvent un document validé un jour, jamais rouvert depuis. Avant d’avoir vraiment besoin de vous en servir, assurez-vous qu’il répond à deux questions fondamentales, trop souvent oubliées : combien de temps l’entreprise peut-elle tenir sans son informatique, et combien de travail accepte-t-elle de perdre quand tout s’arrête ? Sans ces deux réponses, un plan de reprise n’est qu’une intention qui rassure jusqu’au jour où elle est mise à l’épreuve.

Combien de temps avant que ça devienne grave ?

Un incident informatique ne devient pas un problème au moment où il survient, mais au moment où sa durée dépasse ce que l’activité peut absorber. Pour la plupart des PME, quelques heures sans accès à la messagerie ou aux outils métiers restent une gêne gérable. Mais passé un certain seuil, propre à chaque entreprise, le même blocage commence à coûter réellement : commandes non traitées, clients qui attendent une réponse, échéances qui se rapprochent. Un cabinet d’avocats, par exemple, tolérera mal un blocage la veille d’une échéance de procédure, alors que le même blocage un dimanche passerait presque inaperçu. Le seuil critique n’est donc pas universel : il dépend du métier, du moment, et de l’outil concerné.

Cette durée maximale tolérée avant qu’un incident cause un dommage réel à l’activité, plutôt qu’une simple gêne ce que les professionnels de l’informatique appellent le RTO, pour Recovery Time Objective doit être fixée à l’avance, par métier et par outil, plutôt que découverte le jour de l’incident. Un serveur de messagerie et un outil de facturation n’ont pas la même urgence de redémarrage, et c’est à la direction de trancher cette hiérarchie, pas à l’informatique seule.

Combien de travail pouvez-vous vous permettre de perdre ?

La seconde question porte sur les données plutôt que sur le temps. Entre la dernière sauvegarde exploitable et le moment de l’incident, un volume de travail a été produit : contrats rédigés, échanges avec un client, mouvements comptables. Ce volume peut être perdu si l’incident survient avant la sauvegarde suivante.

Une sauvegarde quotidienne accepte, par construction, de perdre jusqu’à une journée de travail en cas d’incident survenant juste avant ce volume maximal toléré, les professionnels l’appellent le RPO, pour Recovery Point Objective. Pour une PME qui produit des documents engageants tout au long de la journée, cette perte représente des heures de travail à refaire, avec le risque supplémentaire d’oublier un engagement pris entre-temps. Une société de gestion de portefeuille qui perdrait une journée de suivi client mesure vite ce que ce volume représente concrètement. C’est ce volume acceptable de perte qui doit guider la fréquence des sauvegardes, et non l’inverse : ce n’est pas la technique qui doit dicter ce qu’on accepte de perdre, mais l’activité qui doit dicter la fréquence de sauvegarde nécessaire.

Le piège qu’on oublie : redémarrer, ce n’est pas encore travailler

Un serveur qui redémarre techniquement n’équivaut pas à une équipe qui peut reprendre le travail. Entre les deux, il faut vérifier que les données restaurées sont cohérentes, reconfigurer les accès, s’assurer que les outils métiers communiquent correctement entre eux, et parfois former ou rassurer les équipes sur la marche à suivre. Ce temps de remise en route réelle, une fois le redémarrage technique terminé, porte lui aussi un nom : le WRT (Work Recovery Time). Cette étape est souvent absente du calcul initial, ce qui explique qu’un incident annoncé comme « résolu en quatre heures » se traduise en pratique par une journée de travail dégradé. La limite globale à ne pas franchir le redémarrage technique et cette remise en route réelle additionnés porte elle aussi un nom : le MTD, pour Maximum Tolerable Downtime.

Comment fixer ces seuils sans se tromper

Fixer ces deux seuils commence par identifier ce qui est réellement vital pour l’activité : facturation, accès aux dossiers clients, outils de reporting réglementaire, messagerie. Tout n’a pas la même urgence, et confondre l’ensemble du système d’information avec ses fonctions critiques conduit soit à des seuils inatteignables, soit à des seuils trop larges pour être utiles.

Cette hiérarchisation doit ensuite être confrontée à la réalité technique : un outil jugé prioritaire peut dépendre d’un autre système moins visible (annuaire d’authentification, connexion internet, hébergement d’un éditeur tiers) dont la disponibilité conditionne la sienne. Une bonne partie des plans de reprise échouent parce que cette dépendance n’a pas été identifiée en amont.

Ces seuils engagent ensuite l’entreprise dans la durée : ils doivent être validés par la direction, pas uniquement définis par un prestataire ou une équipe informatique interne, car c’est la direction qui porte la responsabilité de l’activité et du budget nécessaire pour les tenir. Un seuil ambitieux non budgété reste théorique.

Ce que DORA et NIS2 attendent concrètement

Pour les sociétés de gestion de portefeuille, cette exigence de seuils chiffrés et testés n’est plus seulement une bonne pratique : elle relève désormais du règlement européen DORA (Digital Operational Resilience Act), applicable depuis janvier 2025. Son article 12 impose des procédures de sauvegarde et de restauration testées périodiquement, avec des systèmes de sauvegarde séparés physiquement et logiquement du système source. Son article 11 impose de définir un plan de continuité des activités et de le tester régulièrement.

Pour les autres PME concernées par la directive NIS2, l’article 21 range explicitement « la gestion des sauvegardes et la reprise des activités » parmi les mesures de gestion des risques attendues, avec une responsabilité qui remonte jusqu’aux organes de direction.

Dans les deux cas, le principe reste le même que pour toute PME : un plan de reprise n’a de valeur que s’il répond à des seuils précis, validés par la direction et vérifiés dans les faits, pas seulement couché sur le papier.

D’un plan supposé fiable à un plan vérifié

La plupart des PME ne partent pas de zéro : une sauvegarde existe, un prestataire s’en occupe, un document décrit vaguement une procédure de reprise. L’enjeu n’est donc pas de tout refaire, mais de transformer ce dispositif supposé fonctionnel en un dispositif dont les seuils sont explicites, budgétés et testés.

Car ces seuils ne valent que s’ils sont testés en conditions réelles, au moins une fois par an. Deux études internationales, à défaut de données françaises équivalentes, donnent une idée de l’écart qui existe généralement entre avoir un plan et avoir un plan éprouvé : au Royaume-Uni, l’étude Data Health Check 2025 de Databarracks (500 professionnels IT interrogés) trouve que neuf organisations sur dix avaient testé tout ou partie de leurs capacités de reprise sur les douze derniers mois, tandis qu’une étude Dimensional Research pour Arcserve menée en 2022 auprès de plus de 1 100 décideurs IT dans le monde indiquait que seuls 24 % des répondants disposaient d’un plan de reprise bien documenté, rigoureusement testé et à jour. Ces chiffres viennent d’environnements économiques différents du tissu de PME françaises et ne doivent pas être transposés tels quels ; ils illustrent surtout une tendance de fond, largement partagée, que des retours de terrain en France confirment sans la chiffrer aussi précisément.

Un accompagnement structuré permet justement ce travail : passer de seuils supposés à des seuils vérifiés, sans reconstruire l’existant.

Un plan de reprise d’activité ne se juge pas à son épaisseur, mais à deux réponses précises : combien de temps, et combien de données. Ces seuils ne sont pas toujours simples à fixer, ni à tester dans la durée mais c’est bien leur présence, plus que celle du document lui-même, qui fait la différence le jour où un incident survient. Les clarifier avec la direction et les éprouver régulièrement transforme un document rassurant en un dispositif qui tient réellement le jour où il sert.