ISO 27031 : retour à la réalité : le dangereux fossé entre les entreprises et les services informatiques en matière de RTO

Dans le monde de la gestion de la continuité des activités (BCM), il n'existe pratiquement aucun indicateur aussi fondamental et en même temps aussi susceptible d'être mal interprété que l'objectif de temps de récupération (RTO). Alors que les services spécialisés et les services informatiques pensent parler le même langage, ils définissent souvent de manière fondamentalement différente le point de départ de cette période critique. Cette divergence n'est pas une subtilité académique, mais une bombe à retardement qui, en cas d'urgence, peut conduire à des hypothèses de sécurité erronées, à une escalade des conflits et à des pertes financières incontrôlées.

Deux mondes, un seul indicateur : quand le compte à rebours commence-t-il réellement ?

La controverse peut se résumer à une question simple : quand commence le RTO ? La réponse à cette question divise souvent les organisations en deux camps, qui s'orientent respectivement vers les normes ISO et les pratiques courantes du BSI.

La perspective commerciale (selon ISO 22301 et ISO 27031) : pour l'entreprise, le préjudice commence exactement au moment de l'incident. Chaque seconde d'indisponibilité coûte de l'argent, de la confiance et des parts de marché. Les normes internationales telles que ISO 22301:2019 et la nouvelle ISO 27031:2025 sont sans équivoque à cet égard : la mesure du RTO commence à partir du moment où l'incident se produit, c'est-à-dire au moment où le dommage survient. Cette perspective est la seule base logique pour une analyse d'impact sur l'activité (BIA) valide, car elle couvre toute la durée de l'indisponibilité.
La perspective informatique (pratique courante, souvent dans le domaine de la sécurité informatique) : pour le service informatique, le RTO est souvent un objectif de niveau de service (SLO) dont le respect doit être mesuré et rapporté. Dans la pratique, le chronomètre ne démarre donc souvent qu'après la découverte et l'analyse de l'incident et la déclaration officielle d'une situation d'urgence. Les phases de détection, d'analyse et de décision ne sont pas prises en compte dans le RTO de l'informatique.

Ces différents points de départ génèrent un « temps d'arrêt caché » (Hidden Downtime) – une période pendant laquelle l'entreprise subit déjà des dommages, mais où le compte à rebours de la restauration informatique n'a pas encore commencé.

Les inconvénients fatals de cette divergence

Ce temps d'arrêt caché est à l'origine d'une cascade d'erreurs stratégiques et de risques opérationnels :

L'illusion de la sécurité apparaît lorsque le service informatique annonce le respect de son RTO de 4 heures, car la restauration technique après le déclenchement de l'urgence n'a duré que 3,5 heures. Mais à ce moment-là, l'entreprise a déjà subi 6,5 heures d'indisponibilité (3 heures de « temps d'arrêt caché » + 3,5 heures de restauration) et a depuis longtemps dépassé la limite de tolérance maximale définie dans l'analyse d'impact sur les activités (BIA). Le feu tricolore informatique est vert, tandis que l'entreprise est dans le rouge.
Il en résulte des analyses d'impact commercial sans valeur et une mauvaise planification des options de solution, car lorsque les services spécialisés définissent leurs exigences en matière de RTO, ils se basent sur le temps d'indisponibilité total. Si le service informatique confirme cette exigence avec un autre calcul du temps, toutes les solutions proposées par la suite reposent sur une prémisse erronée. L'analyse d'impact sur les activités passe ainsi d'un instrument de contrôle à un instrument d'auto-illusion.
Un conflit de crise préprogrammé est inévitable lorsque, en cas d'urgence, les différentes attentes s'affrontent. La direction attend une reprise basée sur le RTO commercial, tandis que le service informatique travaille selon son propre calcul du temps. Il en résulte une perte de confiance, une gestion de crise inefficace et des accusations mutuelles, précisément au moment où une coopération étroite serait vitale.
Des risques sous-estimés et des budgets insuffisants en sont le résultat, car les temps d'arrêt cachés représentent un risque non pris en compte. Les coûts encourus pendant cette phase ne sont pas pris en compte dans l'évaluation des risques. Par conséquent, les budgets nécessaires pour les mesures indispensables, telles que des mécanismes de détection plus rapides ou des solutions manuelles pour pallier ces temps d'arrêt, sont considérés comme inutiles.

Conclusion : un signal d'alarme pour les dirigeants et les responsables

Les différentes interprétations du RTO ne sont pas une simple question sémantique, mais un problème fondamental de gouvernance. La nouvelle norme ISO 27031:2025 reconnaît cette réalité et exige des mesures concrètes : si le service informatique n'est pas en mesure de respecter le RTO exigé par l'entreprise (à compter de la survenue du sinistre), l'organisation est tenue de disposer d'un plan pour combler cette lacune, à savoir une solution de contournement manuelle.

Recommandations d'action pour les cadres dirigeants et les responsables :

Il est essentiel de créer un langage uniforme. Organisez un atelier entre les responsables commerciaux et la direction informatique dans le seul but d'adopter une définition RTO contraignante à l'échelle de l'entreprise, qui commence au moment de l'incident. Ancrez cette définition dans votre politique BCM et ITSCM.
Il est indispensable de mesurer la réalité. Introduisez l'indicateur Recovery Time Actual (RTA). Mesurez, à l'aide de tests et d'exercices, le temps réel écoulé entre l'incident simulé et le redémarrage. Ce RTA est la mesure honnête de votre résilience.
Rendez la lacune transparente. Réalisez une analyse des écarts qui compare les exigences de l'entreprise (RTO) aux performances réelles (RTA). Cette méthode sert de base à toute décision stratégique, qu'il s'agisse d'investir dans une informatique plus rapide ou dans le développement de processus manuels robustes.
Prendre ses responsabilités est fondamental. Le développement de solutions de contournement n'est pas une tâche informatique, mais relève de la responsabilité des responsables de processus dans les départements spécialisés. La direction doit fournir les budgets et les ressources nécessaires à cet effet et établir une culture de test qui considère les points faibles comme des opportunités d'apprentissage.

Comblez le fossé en matière de résilience

Combler le fossé entre les exigences commerciales et la réalité informatique est un défi complexe. Notre équipe de spécialistes expérimentés en BCM et IRBC vous aide de manière ciblée à mettre la théorie en pratique. De l'animation d'un atelier décisif sur l'alignement RTO à la réalisation d'une analyse approfondie des lacunes, en passant par l'élaboration de plans de continuité des activités pratiques, nous vous aidons à développer une résilience réelle et mesurable.

Contactez-nous pour une première consultation sans engagement et faites le premier pas pour passer d'un plan sur papier à une stratégie concrète et résistante aux crises.