DIMA, PDMA, RTO, RPO : ces sigles reviennent dans la quasi-totalité des plans de continuité d’activité que j’audite ou que j’accompagne. Le problème n’est pas qu’ils soient techniques : c’est qu’ils sont, la plupart du temps, mal compris et mal alignés entre eux. Avec NIS2 et DORA, cette confusion n’est plus un détail : les organisations doivent désormais démontrer une capacité réelle de résilience, et non plus se contenter d’indicateurs alignés dans un tableau.

Deux niveaux que l’on confond trop souvent

Pour raisonner correctement, il faut d’abord séparer deux niveaux de décision qui n’ont ni les mêmes responsables, ni la même logique.

Côté métier :

  • la DIMA (durée d’indisponibilité maximale admissible) : à partir de combien de temps d’arrêt l’activité est réellement mise en difficulté ;
  • la PDMA (perte de données maximale admissible) : quelle perte de données reste acceptable pour l’activité.

Côté IT :

  • le RTO (objectif de temps de reprise) : en combien de temps le service peut redémarrer, ce qui conditionne les mesures de continuité ;
  • le RPO (objectif de point de reprise) : à quel instant on peut restaurer les données, ce qui conditionne le plan de sauvegarde.

Le principe clé : la stratégie part du métier, pas de l’IT

C’est souvent là que ça bloque. L’IT ne décide pas du niveau de continuité attendu : elle répond techniquement à un besoin défini par le métier. Or, dans beaucoup d’organisations, la logique est inversée : on met en place une architecture, on choisit des niveaux de sauvegarde, puis on « fait rentrer » des RTO et des RPO dans un tableau, sans toujours vérifier qu’ils correspondent au besoin réel de l’activité.

Si le RTO ou le RPO retenus ne sont pas contraints par la DIMA et la PDMA d’définies par le mêmier, la stratégie de continuité ne protège personne : elle rassure sur le papier, sans garantir la résilience réelle de l’organisation.

Un exemple concret : quand la technique ne suit pas le besoin métier

Prenons le cas, très répandu, d’une PME éditrice de logiciel SaaS. Ses clients attendent un service disponible en continu : au-delà de 8 heures d’indisponibilité, le support sature, les clients se plaignent, et les pénalités contractuelles se déclenchent. La perte de plusieurs heures de données clients (configurations, tickets, opérations en cours) est, elle aussi, difficilement acceptable. Le besoin métier est donc clair : une DIMA de 8 heures et une PDMA d’une heure.

Schéma d'un incident : sauvegardes, perte de données et durée d'indisponibilité

Regardons maintenant ce que donne, concrètement, une architecture technique qui n’a pas été calibrée sur ce besoin. Des sauvegardes sont réalisées les 5, 10 et 15 janvier. Un incident survient le 19 janvier. Le service n’est restauré que le 22 janvier, à partir de la dernière sauvegarde disponible, celle du 15 janvier. Résultat : 4 jours de données perdues (RPO réel) et 3 jours d’indisponibilité (RTO réel) — très loin de la DIMA de 8 heures et de la PDMA d’une heure attendues par le métier. Sur le papier, l’entreprise dispose pourtant d’un plan de sauvegarde et d’une procédure de reprise. Dans les faits, cette stratégie technique ne répond simplement pas au besoin de l’activité.

Ce que changent NIS2 et DORA

Le plan de continuité d’activité devient une obligation à part entière pour de nombreuses organisations, portée par l’article 21 de NIS2 pour les entités essentielles et importantes, et par l’article 11 de DORA pour le secteur financier. Dans les deux cas, l’exigence ne s’arrête pas à la rédaction d’un document. Les organisations doivent désormais :

  1. identifier et évaluer clairement leurs risques et impacts ;
  2. construire une stratégie de continuité cohérente avec ces risques, et non avec les seules contraintes techniques disponibles ;
  3. démontrer, par des tests réguliers et des exercices de crise, que cette stratégie tient réellement face à un incident.

Un plan de continuité qui n’est jamais testé n’offre aucune garantie exploitable en cas de crise réelle.

Aller plus loin avec le Parcours Gouvernance SSI

C’est exactement ce type de sujet que nous abordons dans le Parcours Gouvernance SSI de l’Académie du RSSI : apprendre à faire dialoguer les métiers et l’IT autour d’indicateurs de résilience partagés, cohérents et tenables.

Envie d’en savoir plus ? Réservez votre place pour construire ensemble votre parcours de formation.