---

---

Un malentendu dangereux s'est installé dans le monde de l'entreprise : les services informatiques partent du principe que la mise en œuvre de la gestion de la continuité des services informatiques (ITSCM) équivaut à une gestion complète de la continuité des activités (BCM) pour leur propre domaine. Cette hypothèse, qui consiste à considérer l'informatique comme un simple prestataire de services pour d'autres départements, crée une faille critique en matière de résilience. Elle ignore le fait que l'organisation informatique elle-même est une entité commerciale complexe présentant ses propres vulnérabilités non techniques, qu'il s'agisse du personnel clé, des sites ou des fournisseurs.

La nouvelle norme internationale ISO/IEC 27031:2025 remet en question ce statu quo. La norme exige clairement l'intégration d'une approche BCM holistique dans la fonction informatique elle-même et la traite comme une unité commerciale à sécuriser.

Le malentendu fondamental : pourquoi l'informatique a besoin de son propre BCM

Il existe dans les organisations un flou conceptuel qui peut avoir des conséquences catastrophiques en cas de crise : la confusion entre BCM et ITSCM.

La gestion de la continuité des activités (Business Continuity Management) est un processus de gestion holistique et stratégique qui vise à protéger les processus métier critiques de l'ensemble de l'organisation contre les effets d'événements susceptibles d'entraîner des pannes. La BCM prend en compte toutes les ressources qui contribuent à la création de valeur : les personnes, les infrastructures, les chaînes d'approvisionnement et la technologie.

La gestion de la continuité des services informatiques (ITSCM) est quant à elle une discipline spécialisée qui fait partie intégrante de la BCM. Elle se concentre exclusivement sur le redémarrage et la restauration de l'infrastructure technologique et des services informatiques afin d'atteindre les objectifs définis par l'entreprise dans le processus BCM. L'ITSCM est la contribution technique de l'informatique à la résilience globale de l'entreprise.

Le problème survient lorsque le service informatique considère que sa mission est accomplie dès qu'il dispose d'un plan de reprise informatique. Il oublie alors qu'il s'agit lui-même d'une unité commerciale soumise à des contraintes de temps, qui peut subir des pannes allant bien au-delà d'une simple défaillance du système. Un plan de reprise informatique peut régir le redémarrage et la restauration d'un serveur, mais il ne répond pas à la question de savoir ce qui se passe si les administrateurs nécessaires ne sont pas disponibles en raison d'une pandémie.

Les origines du malentendu : une analyse historico-culturelle

Cette simplification dangereuse n'est pas le fruit du hasard, mais le résultat d'une longue évolution marquée par des cloisonnements organisationnels et l'influence de cadres établis.

• Depuis les débuts de l'informatique d'entreprise, les services informatiques ont souvent été considérés comme des unités de support technique centralisées, séparées sur le plan organisationnel des activités principales, ce qui a conduit à des cloisonnements historiques entre les activités commerciales et l'informatique. Cette séparation a entraîné des priorités divergentes, des barrières de communication et un manque de responsabilité partagée pour la résilience globale de l'entreprise. L'entreprise « commande » des services, l'informatique « fournit » - une dynamique qui rend difficile une compréhension intégrée de la gestion de la continuité des activités.

• Le cadre largement répandu ITIL (IT Infrastructure Library) a certes professionnalisé l'informatique, mais il a également consolidé son rôle de prestataire de services, ce que l'on peut appeler l'effet ITIL. La gestion des services informatiques (ITSCM) étant un processus central au sein de l'ITIL, de nombreuses organisations informatiques l'ont intégré comme leur principale, et souvent unique, obligation en matière de continuité. Elles répondent ainsi aux exigences de leur cadre, mais négligent la nécessité de se considérer comme une entité commerciale qui a également besoin d'un BCM.

• Les experts en informatique pensent naturellement en termes de solutions technologiques, ce qui conduit à une vision centrée sur la technologie. Une « urgence » est principalement comprise comme une panne de système, un problème de réseau ou une cyberattaque. Le redémarrage et la restauration se concentrent sur les sauvegardes de données et le matériel redondant. Les risques tels que la perte de personnel clé ou la disparition d'un fournisseur urgent sont souvent exclus de cette grille centrée sur la technologie.

Le mandat de la norme ISO 27031:2025 : l'informatique en tant qu'unité commerciale à sécuriser

La nouvelle norme ISO 27031 rompt radicalement avec cette vision isolée. Elle ne traite plus la fonction informatique comme un simple prestataire de services techniques, mais comme une unité commerciale autonome et urgente qui nécessite son propre BCM intégré. Ce changement de paradigme est étayé par plusieurs aspects clés de la norme :

• La norme exige explicitement l'intégration plutôt que l'isolement (chapitre 6) de la « ICT Readiness for Business Continuity » (IRBC) dans le BCM global de l'entreprise. Cela positionne l'informatique non pas comme un fournisseur externe, mais comme une partie intégrante de la stratégie de résilience, qui doit se soumettre aux mêmes principes holistiques que tout autre service.

• Une approche holistique des ressources est établie par la norme ISO 27031, qui énumère explicitement les ressources de la fonction informatique à sécuriser. Cela inclut non seulement la technologie et les données, mais aussi les « compétences du personnel », les « installations », les « processus » (internes) et les « fournisseurs ». Il est ainsi clairement établi qu'une approche ITSCM pure, qui se concentre uniquement sur le redémarrage et la restauration de la technologie et des données, n'est pas suffisante. Le service informatique doit disposer de plans en cas d'absence de personnel clé, de perte de ses locaux, de panne de son infrastructure informatique et de défaillance de ses propres fournisseurs.

• La norme attribue à la direction générale une responsabilité claire (chapitre 13) pour l'évaluation et l'approbation des stratégies IRBC. Cela élève la continuité de la fonction informatique elle-même à un niveau stratégique et signale qu'elle doit être traitée avec le même sérieux que la continuité de la production, par exemple.

La norme ISO 27031 exige donc que l'informatique se soumette à une analyse d'impact sur les activités et mette en œuvre un BCM qui sécurise sa propre organisation afin qu'elle soit en mesure de remplir ses tâches ITSCM pour le reste de l'entreprise.

Les risques de l'erreur ITSCM dans la pratique

Si un service informatique se contente de mettre en œuvre l'ITSCM et pense ainsi être résilient, il expose l'entreprise à des risques incalculables. Se concentrer uniquement sur la restauration technique ne tient pas compte des scénarios de panne non techniques et urgents :

• Un plan de reprise informatique qui ne décrit que les étapes techniques de la reprise est inutile si personne n'est là pour le mettre en œuvre, ce qui augmente le risque de défaillance du personnel clé. Que se passe-t-il si les quelques spécialistes qui administrent un ancien système complexe ou une base de données critique sont simultanément indisponibles en raison d'une pandémie, d'un accident ou d'une grève ? Un BCM pour l'informatique exigerait ici des mesures telles que la formation polyvalente, la séparation des compétences de base et l'automatisation.

• La perte de sites informatiques est un autre risque, car un incendie dans le bâtiment administratif de l'informatique, une inondation régionale ou une panne de courant affectant les postes de travail des employés informatiques peut paralyser la capacité à coordonner le redémarrage et la restauration. L'ITSCM planifie le redémarrage des serveurs dans un centre de données de secours, mais un BCM pour l'informatique planifie à partir d'où les équipes informatiques peuvent contrôler et effectuer ce redémarrage.

• L'informatique elle-même dépend d'une chaîne de processus, et la panne des processus informatiques internes peut rendre impossible une réponse efficace à la situation d'urgence proprement dite. Si les systèmes qui soutiennent ces processus internes (par exemple, le système de tickets, les outils de surveillance) ou le personnel responsable tombent en panne, l'informatique perd sa capacité de contrôle. L'informatique dépend fortement de partenaires externes, c'est pourquoi la défaillance des fournisseurs représente un risque considérable.

• L'informatique dépend fortement de partenaires externes, c'est pourquoi la défaillance des fournisseurs représente un risque considérable. Un plan ITSCM peut prévoir une sauvegarde des données dans le cloud, mais un BCM pour l'informatique analyse les obligations contractuelles, prévoit des fournisseurs alternatifs et définit des processus pour le cas où un partenaire stratégique ferait défaut.

Conclusion

L'hypothèse selon laquelle l'ITSCM ou l'IRBC remplace un BCM pour l'informatique est l'une des lacunes les plus dangereuses en matière de résilience dans les entreprises modernes. Elle découle d'une vision obsolète, centrée sur la technologie, et est renforcée par les silos organisationnels. La norme ISO/IEC 27031  est très claire : l'informatique n'est pas seulement un prestataire de services, mais une unité commerciale critique qui nécessite sa propre gestion intégrée de la continuité des activités.

Recommandations d'action pour la direction et les responsables :

• Une attribution claire des responsabilités est essentielle. La direction doit reconnaître que l'organisation informatique a elle-même besoin d'une gestion de la continuité des activités (BCM). La responsabilité de cette BCM « interne » de l'informatique doit être clairement attribuée au directeur informatique/responsable informatique, en étroite collaboration avec le responsable BCM de l'entreprise.

• La réalisation d'une BIA pour l'organisation informatique est indispensable. Réalisez une analyse d'impact sur les activités qui n'évalue pas les services informatiques fournis à d'autres, mais les processus internes, le personnel, les sites et les fournisseurs du service informatique lui-même. Identifiez les véritables « points de défaillance uniques » au sein de votre organisation informatique.

• Élaborez des plans de continuité des activités (PCA) pour l'informatique. Élargissez la perspective des plans informatiques et de reprise après sinistre existants pour inclure des aspects non techniques. Élaborez des plans concrets pour des scénarios tels que l'indisponibilité de personnel clé, la perte de postes de travail informatiques, la défaillance de l'infrastructure informatique et la défaillance de fournisseurs informatiques critiques. Établir une culture de test intégrée est fondamental. Réalisez des exercices qui testent non seulement le basculement technique, mais aussi la résilience.

• Il est fondamental de mettre en place une culture de test intégrée. Réalisez des exercices qui testent non seulement le basculement technique, mais aussi la résilience de l'organisation informatique elle-même. Simulez la défaillance du personnel informatique et vérifiez si les processus documentés peuvent également être exécutés par d'autres équipes.

Comblez le fossé en matière de résilience : votre informatique est-elle vraiment résiliente ou simplement récupérable ?

La norme ISO 27031:2025 exige une nouvelle façon de penser. Un plan de reprise purement technique ne suffit plus pour sécuriser l'informatique elle-même. Nous vous aidons à combler le fossé entre l'ITSCM et une véritable gestion de la continuité des activités (BCM) pour votre informatique, de l'analyse d'impact sur les activités (BIA) pour votre organisation informatique à l'élaboration de plans d'urgence intégrés. Contactez-nous pour tester la résilience de votre informatique et en faire une unité commerciale résistante aux crises.