Bien que de nombreuses normes de continuité des activités soulignent l’importance du suivi des actions correctives pour résoudre les problèmes identifiés, la norme ISO 22301 récemment publiée (et précédemment BS 25999-2) exige également la réalisation d’une analyse des causes profondes – en examinant non seulement un problème, mais aussi sa cause et la manière dont il peut être évité à l’avenir. L’analyse des causes profondes (ACP) est une approche qui vise à prévenir de manière proactive la réapparition d’un même événement indésirable ou d’une même défaillance de système en remontant les relations de cause à effet d’une défaillance jusqu’à son origine la plus probable, puis en mettant en place des mesures visant à atténuer les causes sous-jacentes afin d’éviter que l’événement indésirable ne se reproduise à l’avenir. Bien qu’elle soit courante dans les disciplines qui traitent de l’extrême précision et de la protection de la vie (par exemple la qualité et la santé et la sécurité environnementales), il n’y a aucune raison pour que la discipline de la continuité d’activité ne bénéficie pas d’une approche similaire, en particulier pour les praticiens qui cherchent à mettre pleinement en œuvre l’ISO 22301. Cet article explique l’analyse des causes profondes et identifie comment les organisations peuvent bénéficier de la mise en œuvre du concept dans un contexte de continuité des activités.

Le concept d’analyse des causes profondes a été développé à l’origine par Sakichi Toyoda (le fondateur de Toyota Motor Corporation), qui a mis au point un processus appelé « les cinq raisons » pour comprendre les causes potentielles des problèmes au-delà de ce qui était immédiatement évident. L’analyse des causes profondes est devenue plus formelle lorsqu’elle a été intégrée dans plusieurs domaines différents en tant que moteur de performance, tels que la sécurité, la qualité, les opérations et la sécurité de l’information. Dans chacun de ces domaines, il ne suffisait pas de réagir à un problème – il fallait prévenir les problèmes futurs, et l’analyse des causes profondes était la voie à suivre pour améliorer les performances et atténuer les risques en éliminant les vraies causes, plutôt que les simples symptômes. L’intégration de l’analyse des causes profondes dans les actions correctives existantes liées à la continuité des activités pourrait très bien minimiser la probabilité d’incidents perturbateurs futurs et réduire les délais de rétablissement.

Parfois, la réalisation d’une ACR est aussi simple que la mise en œuvre des cinq « pourquoi », en demandant à plusieurs reprises « pourquoi » quelque chose s’est produit jusqu’à ce qu’il semble que vous ayez atteint la cause fondamentale de l’apparition de l’échec. La clé réside dans l’application disciplinée de questions approfondies. Par exemple, l’analyse de la cause fondamentale de l’échec d’une organisation à atteindre un objectif de temps de récupération de 24 heures pour son environnement SAP au cours d’un test récent pourrait ressembler à ceci :

  1. Problème : Le personnel chargé de la reprise des activités informatiques n’a pas réussi à restaurer le système SAP de l’entreprise dans le délai de 24 heures prévu lors du test de reprise des activités informatiques de la semaine dernière (….). Pourquoi ?
  2. Le personnel chargé de la reprise informatique a déclaré que les LUN SAN n’étaient pas mappés correctement, ce qui a considérablement retardé le démarrage de la restauration à partir du disque… Pourquoi ?
  3. Le personnel du fournisseur chargé de préparer l’équipement n’a pas exécuté l’installation conformément aux attentes documentées … Pourquoi ?
  4. Le personnel du fournisseur a indiqué que les instructions semblaient contradictoires et ne fournissaient pas le niveau de détail nécessaire pour exécuter les étapes, de sorte qu’il a utilisé une configuration de base par défaut… Pourquoi ?
  5. Après analyse, la documentation a omis plusieurs étapes cruciales nécessaires pour permettre à ce mappage complexe de LUN de se produire … Pourquoi cela n’a-t-il pas été découvert plus tôt ?
  6. Lors des tests précédents, le personnel n’a pas pleinement exploité la documentation existante du plan … Qu’est-ce qui a changé cette fois-ci ?
  7. La personne chargée de documenter le plan et d’effectuer les tests précédents n’était pas disponible, et le personnel qui a effectué les tests cette fois-ci a indiqué qu’il n’avait pas été correctement formé à l’utilisation des plans, et qu’il n’avait pas non plus reçu d’instructions sur la manière de faire remonter les problèmes concernant les processus de récupération.

Bien qu’il puisse sembler que la cause première ait été atteinte, le simple fait de corriger la documentation ne garantit pas que la documentation future sera exacte. Pour aller plus loin, l’ancien expert en informatique chargé de documenter les procédures effectue souvent des tests sur site sans utiliser de documentation, car il possède une grande expérience dans ce domaine et a estimé qu’il pouvait effectuer des tâches plus rapidement en se basant sur son expérience plutôt que sur des procédures documentées. Un examen plus approfondi de la question a révélé que le personnel nouvellement affecté aux tâches de récupération était beaucoup moins expérimenté et n’avait pas encore reçu un niveau approprié de formation de sensibilisation. À cet égard, le directeur informatique a admis qu’il ne demandait jamais à d’autres membres du personnel de valider la documentation, car les tests prennent du temps au détriment de l’assistance à la production et le fait de s’appuyer sur les « experts » à chaque phase réduit la durée des tests.

Une partie de la solution pourrait consister à exiger que toutes les procédures documentées soient validées au moins une fois par an par un autre informaticien dans un domaine d’expertise différent. Une deuxième partie de la solution pourrait consister à dispenser d’emblée une formation appropriée (mettant l’accent sur la familiarisation avec les plans et la connaissance des procédures d’escalade) à la fois aux personnes internes suppléantes et aux ressources du fournisseur chargées de l’exécution du plan. L’ensemble de ces efforts pourrait contribuer à garantir que toute la documentation relative au plan de secours informatique puisse être utilisée efficacement par les ressources internes et externes pendant les tests.

Bien que simple en théorie, l’identification de la cause première réelle et la détermination du moment où vous êtes allé assez loin peuvent s’avérer complexes en pratique. Pour mieux comprendre les causes premières, vous devez poser à plusieurs reprises des variantes de la question « pourquoi » (et quelques autres questions d’approfondissement), puis rechercher la réponse qui semble la plus susceptible d’avoir influencé le problème. Bien que l’analyse des causes profondes ne relève pas d’une « science exacte », plus vous recherchez les causes, plus vous avez de chances de trouver des problèmes à résoudre. Dans la plupart des cas, le plus gros problème auquel sont confrontées les organisations est de ne pas explorer les problèmes dès le départ ! Notre exemple a démontré ce problème dans la récupération de SAP. Cependant, il est probable que ce problème (les raccourcis) existe dans d’autres domaines et que le fait de s’attaquer à la cause première pourrait améliorer les performances et la capacité de récupération dans d’autres domaines.

Dans le cadre de la continuité des activités, plusieurs domaines peuvent être identifiés comme causes profondes des problèmes de réduction des risques, de réponse et de reprise, même si, là encore, il faut remonter plus loin que ce que la plupart des professionnels choisissent d’explorer. Pour intégrer correctement l’analyse des causes profondes dans les activités d’amélioration continue, chaque problème doit être documenté de manière adéquate, y compris la source du problème, une description détaillée, une date d’identification, et il doit également y avoir un champ pour saisir l’analyse des causes profondes. Plutôt que de laisser une seule personne tenter d’identifier la cause première, le personnel chargé de la continuité des activités devrait organiser et faciliter des discussions impliquant des experts en la matière à qui les problèmes peuvent être attribués ou qui peuvent fournir des informations sur un problème, puis le groupe devrait chercher à remonter ensemble à l’origine du problème.

Dans le cadre de la continuité des activités, il existe de nombreuses causes profondes qui peuvent conduire à une variété de problèmes ou de complications. Le tableau suivant présente quelques exemples, ainsi que les causes profondes probables, bien que cette liste soit loin d’être exhaustive. Il est donc important de remonter toutes les pistes potentielles de l’origine d’un problème, plutôt que de rechercher une seule cause directe, afin d’identifier tous les facteurs d’influence.

Encore une fois, l’analyse des causes profondes ne consiste pas seulement à résoudre un problème ponctuel, mais aussi à rechercher des possibilités d’éviter qu’il ne se reproduise à l’avenir. Une fois l’origine d’un problème identifiée, il est important d’évaluer tous les domaines de l’entreprise afin d’identifier les autres domaines à risque et de s’assurer que les mesures d’atténuation des risques appropriées sont mises en place. Une solution apportée dans un domaine n’est pas nécessairement applicable à tous les autres domaines de l’organisation, mais même si ce n’est pas le cas, le fait d’identifier d’autres domaines à risque similaires sensibilise l’organisation et lui permet de développer des solutions supplémentaires qui ont du sens et de traiter ces risques avant qu’ils ne se traduisent par des problèmes ou des temps d’arrêt à l’avenir.

Au fur et à mesure que les systèmes de gestion de la continuité des activités se développent, l’analyse des causes profondes deviendra un outil puissant permettant aux professionnels de la continuité des activités d’ examiner en profondeur la cause des problèmes et de les corriger avant qu’ils ne se reproduisent.