La réussite d'un projet PCA repose en grande partie sur la qualité des échanges entre le Responsable de Projet PCA et le représentant des équipes informatiques en charge de la mise en œuvre des solutions de secours techniques. De la compréhension des besoins métiers, jusqu’à la prise en compte des contraintes associés à l’exploitation du système d’information, les sujets communs ne manquent pas. Il est donc essentiel, pour les différents contributeurs, d’avoir un langage commun et de partager les mêmes objectifs. Sur la base d’études de cas concrètes, ce webinar vous proposera des solutions pragmatiques visant à aboutir à la mise en place d’un espace commun de coopération efficient. Inscrivez-vous gratuitement à cette session (60 minutes) et découvrez comment amener le RPSI et le RPCA vers une situation coopérative.

1. CONTINUITÉ MÉTIER ET
SECOURS INFORMATIQUE
Convergences et Divergences
Webinar – 5 février 2015
Dominique Nadjar & David Abgrall
Consultant manager PCA - Hapsis

2. Pour plus d’informations :
www.hapsis.fr
Cabinet de conseil indépendant créé en 2002 par
des professionnels de la sécurité informatique.
QUI SOMMES-NOUS ?
La mission de Hapsis a pour objectifs d’identifier, de
quantifier et de gérer des risques par la mise en
œuvre de processus de sécurité dont l’efficacité est
renforcée par des compétences et des
comportements adéquats. La diversité de nos
compétences permet de couvrir un large spectre des
besoins des clients.
© Copyright Hapsis 2015. Tous droits réservés
QUISOMMES-NOUS?
1

3. © Copyright Hapsis 2015. Tous droits réservés
QUISOMMES-NOUS?
LES CHIFFRES CLES :
2

4. © Copyright Hapsis 2015. Tous droits réservés
Introduction & Définitions
Inventaire des souffrances
Recovery Time Objective
Tests et Exercices
Facteurs de complexité
Conclusion
AU SOMMAIRE :
3
SOMMAIRE

5. © Copyright Hapsis 2015. Tous droits réservés
Introduction & Définitions
Inventaire des souffrances
Recovery Time Objective
Tests et Exercices
Facteurs de complexité
Conclusion
4
FACTEURSDE
COMPLEXITE
CONCLUSIONINTRODUCTION
RECOVERYTIME
OBJECTIVE
TESTSET
EXERCICES
INVENTAIREDES
SOUFFRANCES

6. © Copyright Hapsis 2015. Tous droits réservés
INTRODUCTION
En fonction de l’organisation de la structure, la responsabilité du PCA et celle du PSI
peuvent être dissociées. Si le Plan de Secours Informatique est logiquement pris en
charge par la DSI, la responsabilité du secours métier (hors ressources DSI) est souvent
localisé dans une entité fonctionnelle distincte.
Dans ce cas précis le développement d’un partenariat efficace PCA/PSI peut être
difficile et remettre en cause l’atteinte des trois principaux objectifs de ce partenariat :
 Contribuer à l’alignement du niveau de secours du Système d’Information sur les
exigences des métiers
 Définir et mettre en œuvre des solutions techniques qui supportent la reprise des
activités
 Obtenir une meilleure visibilité sur le niveau de secours du SI et des applications
Problématique : Comment amener RPSI et RPCA à coopérer efficacement ?
FACTEURSDE
COMPLEXITE
CONCLUSIONINTRODUCTION
RECOVERYTIME
OBJECTIVE
TESTSET
EXERCICES
INVENTAIREDES
SOUFFRANCES
5

7. © Copyright Hapsis 2015. Tous droits réservés
DÉFINITIONS : PCA vs PSI
Plan de Continuité des Activités (PCA) / Business Continuity Plan (BCP)
Le Plan de Secours
Informatique permet de
couvrir un sinistre sur un site
informatique via la mise en
place d’une architecture
spécifique et de procédures
techniques.
Organisationdecrise
DatacenterSite utilisateurs
DatacenterSite utilisateurs
PCA
PRU
PSI
DRP
PRA
PCIT
Le Plan de Repli Utilisateur
permet de couvrir un sinistre
sur un site utilisateurs via la
mise en place de stratégies de
repli et des procédures
fonctionnelles.
• Le PCA met le processus métier au cœur de la solution et s’assure de la mise à jour et du caractère
opérationnel du PSI.
• Le PSI a pour objectif de maintenir la disponibilité et l’accessibilité du système d’information en cas de
sinistre.
6
FACTEURSDE
COMPLEXITE
CONCLUSIONINTRODUCTION
RECOVERYTIME
OBJECTIVE
TESTSET
EXERCICES
INVENTAIREDES
SOUFFRANCES

8. © Copyright Hapsis 2015. Tous droits réservés
Introduction & Définitions
Inventaire des souffrances
Recovery Time Objective
Tests et Exercices
Facteurs de complexité
Conclusion
7
FACTEURSDE
COMPLEXITE
CONCLUSIONINTRODUCTION
RECOVERYTIME
OBJECTIVE
TESTSET
EXERCICES
INVENTAIREDES
SOUFFRANCES

9. © Copyright Hapsis 2015. Tous droits réservés
INVENTAIRE DES SOUFFRANCES
• Remise en cause des RTO recensés dans le cadre du Business Impact Analysis par la
DSI
• Peu de visibilité sur le niveau de secours du SI et de ses applications
• Absence de référentiel applicatif
• Incompréhension/questionnement sur les RTO mesurés par la DSI (Tests unitaires
vs Tests Globaux)
• Peu de solutions techniques proposées dans le catalogue de la DSI
• Surévaluation des RTOs exprimés par les métiers (Syndrome de la liste au Père
Noël)
• Apparition ponctuelle d’applications inconnues (suite à une mise à jour du BIA)
• Demandes récurrentes de mise en œuvre de solutions techniques pour le secours
utilisateurs (Accès à distance, VDI, création de Masters…)
• Difficulté pour tester le secours d’applications mutualisées sur un même socle
technique avec des responsables métiers différents
Responsable PCA
Responsable PSI
• Manque de rigueur / refus de coopérer
• Rétention d’information
• Retard technologique / Innovation faible
SA PERCEPTION
DU PSI
SA PERCEPTION
DU PCA
• Chronophage
• Utilité réduite
• Connaissance technique faible
8
FACTEURSDE
COMPLEXITE
CONCLUSIONINTRODUCTION
RECOVERYTIME
OBJECTIVE
TESTSET
EXERCICES
INVENTAIREDES
SOUFFRANCES

10. © Copyright Hapsis 2015. Tous droits réservés 9
FACTEURSDE
COMPLEXITE
CONCLUSIONINTRODUCTION
RECOVERYTIME
OBJECTIVE
TESTSET
EXERCICES
INVENTAIREDES
SOUFFRANCES
Introduction & Définitions
Inventaire des souffrances
Recovery Time Objective
• Parlons-nous le même langage ?
Tests et Exercices
Facteurs de complexité
Conclusion

11. © Copyright Hapsis 2015. Tous droits réservés
DÉFINITIONS : RTO & RPO
La durée d'interruption maximale admissible constitue le temps maximal acceptable durant lequel un
processus métier ou une ressource (généralement informatique) peuvent être interrompus après
l’occurrence d’un sinistre entraînant une interruption majeure de service.
RTO (Recovery Time Objective) - DIMA (Durée d’Indisponibilité Maximale Admissible)
La perte de données maximale admissible quantifie les données qu'un système d'information peut être
amené à perdre par suite d’un incident. Usuellement, elle exprime une durée entre l’incident
provoquant la perte de données et la date la plus récente des données qui seront utilisées en
remplacement des données perdues. Cette durée est exprimée généralement en heures ou minutes.
RPO (Recovery Point Objective) - PDMA (Perte de Données Maximale Admissible)
Activation du secours
Reconstruction Synchronisation
DIMA
Sauvegarde Sauvegarde Sauvegarde
PDMA
10
FACTEURSDE
COMPLEXITE
CONCLUSIONINTRODUCTION
RECOVERYTIME
OBJECTIVE
TESTSET
EXERCICES
INVENTAIREDES
SOUFFRANCES

12. © Copyright Hapsis 2015. Tous droits réservés
RTO EXPRIMÉ
 Amnésie (et/ou désintéressement ?)
 Surévaluation par rapport au besoin
réel
 Besoin de connaître le niveau de
secours en place
- [PCA] Quelle est votre durée d’interruption maximale
admissible pour l’application SOFIX ?
- [Métier] Bah je dirais 2 heures…
- [PCA] Vous aviez répondu 1 jour l’an dernier…
- [Métier] Ah bon ? Qu’est ce que l’on a aujourd’hui?
RPCA & Métiers : Le syndrome de la liste au Père Noel
 Rappeler la définition du RTO et les enjeux de
cette démarche (Revue du secours en place =>
coûts à prévoir en cas d’upgrade)
 Challenger le RTO avec le niveau de criticité de
l’activité ou du processus métier que supporte
l’application (Business Impact Analysis)
Problématiques Axes de résolutions
11
FACTEURSDE
COMPLEXITE
CONCLUSIONINTRODUCTION
RECOVERYTIME
OBJECTIVE
TESTSET
EXERCICES
INVENTAIREDES
SOUFFRANCES

13. © Copyright Hapsis 2015. Tous droits réservés
- [PCA] Après consolidation du BIA, il ressort que les RTO de SOFIX et SUMMOT
doivent passer à 2 heures.
- [PSI] 2 heures c’est pas possible pour les infrastructures de SOFIX. D’autant plus
que lorsque l’application tombe, les métiers/utilisateurs mettent 1 semaine à s’en
apercevoir, preuve que ce n’ est pas critique. Et pour SUMMOT, je n’ en ai jamais
entendu parler…
RPCA & RPSI : Le Père Noel ne fera pas de cadeaux ce coup ci…
 Remise en cause brutale de
l’expression de besoin
métier
 BIA truffé d’applications
inconnues de la DSI
 Obtenir des preuves que le métier ne supporte plus cette
situation (Mails incidents, impacts Financier ou autre afin de
forcer le dialogue et revoir l’architecture de l’application)
 Exiger la mise en œuvre d’un référentiel applicatif à jour et
maintenu par la DSI qui spécifie le RTO sur lequel la DSI
s’engage mais aussi le RTO mesuré dans le cadre des tests
 Nettoyer la liste des applications avant de la présenter au
RPSI. Prévoir des ateliers de travail en cas d’absence de
référentiel applicatif.
Problématiques Axes de résolutions
RTO EXPRIMÉ
12
FACTEURSDE
COMPLEXITE
CONCLUSIONINTRODUCTION
RECOVERYTIME
OBJECTIVE
TESTSET
EXERCICES
INVENTAIREDES
SOUFFRANCES

14. © Copyright Hapsis 2015. Tous droits réservés
• Classification Gold, Silver,
Bronze, ou P1, P2, P3, ou
Vitale, Critique,…)
• Classification héritée de
l’infrastructure qui héberge
l’application
• Engagement de la DSI sur un
RTO pour chaque niveau
• RTO « contractuel » dont le
respect ne sera prouvé que
grâce aux tests
RTO RÉEL OU MESURÉ
« La DSI m’assure que le RTO actuel de SOFIX est de 6 heures. Que dois-je
réellement comprendre? »
RTO THEORIQUE
Niveau de service ou de
classification de criticité
de l’application
RTO MESURE
Résultat de tests
effectués par la DSI
RTO « Sorti du Chapeau »
Indisponible ou non
mesuré
• Mesuré dans le cadre d’un
test applicatif unitaire
OU
• Mesuré dans le cadre d’un
exercice de simulation de
perte de datacenter
1 2 3
13
FACTEURSDE
COMPLEXITE
CONCLUSIONINTRODUCTION
RECOVERYTIME
OBJECTIVE
TESTSET
EXERCICES
INVENTAIREDES
SOUFFRANCES

15. © Copyright Hapsis 2015. Tous droits réservés
IMPACT DE LA MUTUALISATION DES
INFRASTRUCTURES INFORMATIQUES
• Application utilisée par plusieurs
métiers distincts ayant des besoins
en secours différents.
• L’application a été conçue en
premier lieu pour des besoins
« SILVER »
Métiers Applications Infrastructures
RTO GOLD
RTO SILVER
RTO GOLD
RTO SILVER
1
2
Cas n° 1
• Plusieurs applications hébergées
sur un même socle technique et
utilisées par des métiers distincts
ayant des besoins en secours
différents.
Cas n° 2
14
FACTEURSDE
COMPLEXITE
CONCLUSIONINTRODUCTION
RECOVERYTIME
OBJECTIVE
TESTSET
EXERCICES
INVENTAIREDES
SOUFFRANCES

16. © Copyright Hapsis 2015. Tous droits réservés 15
FACTEURSDE
COMPLEXITE
CONCLUSIONINTRODUCTION
RECOVERYTIME
OBJECTIVE
TESTSET
EXERCICES
INVENTAIREDES
SOUFFRANCES
Introduction & Définitions
Inventaire des souffrances
Recovery Time Objective
Tests et Exercices
• Rappel des contributions
Facteurs de complexité
Conclusion

17. © Copyright Hapsis 2015. Tous droits réservés
TESTS & EXERCICES
Tests de
repli
utilisateur
Tests
d’accès à
distance
Tests
Unitaires
Tests DRP
Globaux
SecoursMétierSecoursInformatique
• Mise à jour et déploiement de masters/image
système et validation des zonings
• Déploiement d’applications spécifiques à la demande
des métiers
• Fournitures/déploiement d’équipements réseau ou
autre en cas de repli interne
• Support utilisateur
• Tests de charge / nombres de connexions
simultanées possibles
• Ouvertures de flux
• Support utilisateur
La DSI
intervient en
tant que
contributeur du
PCA
Le RPCA
intervient en
tant
contributeur
• Mobilisation des métiers pour réaliser les tests de
validation fonctionnels de l’application en
environnement de secours et lors du retour en
production
• Remontée des résultats de tests auprès des métiers
avec mise en évidence des RTOs non validés
16
FACTEURSDE
COMPLEXITE
CONCLUSIONINTRODUCTION
RECOVERYTIME
OBJECTIVE
TESTSET
EXERCICES
INVENTAIREDES
SOUFFRANCES

18. © Copyright Hapsis 2015. Tous droits réservés 17
FACTEURSDE
COMPLEXITE
CONCLUSIONINTRODUCTION
RECOVERYTIME
OBJECTIVE
TESTSET
EXERCICES
INVENTAIREDES
SOUFFRANCES
Introduction & Définitions
Inventaire des souffrances
Recovery Time Objective
Tests et Exercices
Facteurs de complexité
• Sinon c’est trop simple
Conclusion

19. © Copyright Hapsis 2015. Tous droits réservés
REGLEMENTATION
Un contexte règlementaire flou et souvent méconnu des équipes
informatiques
« ensemble de mesures visant à assurer, selon divers scénarios de crises, y compris face à des chocs
extrêmes, le maintien, le cas échéant de façon temporaire selon un mode dégradé, des prestations
de services essentielles de l'entreprise puis la reprise planifiée des activités ».
Dans le cas d’une sous-traitance (infogérance…) cette méconnaissance
renforcée par :
 La multiplicité des clients
 La multiplicité des environnements règlementaires
 Méconnaissance des choix d’architectures du SI lié
 A la complexité du SI
 A la multiplicité des plateformes
Parmi les éléments qui conditionnent la définition d’un schéma directeur IT,
les problématiques de règlementation liées à la continuité d’activité ne sont
pas ou peu prises en compte.
Extrait du règlement CRBF 97-02
18
FACTEURSDE
COMPLEXITE
CONCLUSIONINTRODUCTION
RECOVERYTIME
OBJECTIVE
TESTSET
EXERCICES
INVENTAIREDES
SOUFFRANCES

20. © Copyright Hapsis 2015. Tous droits réservés
FACTEURS DE COMPLEXITE ET IRRITANTS
Non respect des normes et standards internes
• Utilisation d’applications développées en interne par les métiers et hébergées sur un NAS
• Stockage de données sensibles sur un poste utilisateur en local plutôt que sur le réseau comme
préconisé
Organisation et structure de l’entreprise
Business Unit 1
Business Unit 3
DSI
(Infrastructures)
DSI 1
(Applications)
Business Unit 2
DSI 2
(Applications)
• Echanges plus complexes lorsque la DSI est fractionnée (entités distinctes pour la gestion des
applications et des infras) avec des interlocuteurs intermédiaires.
• Difficulté pour la DSI d’organiser un test d’applications mutualisées sur un même socle
technique avec des responsables métier différents (parfois même issus de départements
différents).
Applications complexes ou soumises à de nombreuses migration/refonte
• Plusieurs noms utilisés et désignant une seule et même application
• Architecture applicative complexe (nombreux composants, plusieurs instances, modules derrière
une même application)
19
FACTEURSDE
COMPLEXITE
CONCLUSIONINTRODUCTION
RECOVERYTIME
OBJECTIVE
TESTSET
EXERCICES
INVENTAIREDES
SOUFFRANCES

21. © Copyright Hapsis 2015. Tous droits réservés 20
FACTEURSDE
COMPLEXITE
CONCLUSIONINTRODUCTION
RECOVERYTIME
OBJECTIVE
TESTSET
EXERCICES
INVENTAIREDES
SOUFFRANCES
Introduction & Définitions
Inventaire des souffrances
Recovery Time Objective
Tests et Exercices
Facteurs de complexité
Conclusion

22. © Copyright Hapsis 2015. Tous droits réservés
CONCLUSION
GUIDE POUR DEVELOPPER UN PARTENARIAT EFFICACE
Responsable PCA Responsable PSI
• Exiger la mise en œuvre d’un référentiel applicatif
complet et à jour (et prendre part aux réflexions et
réunions projets associées)
• Partager les principes d’architecture et de résilience
du SI et les contraintes associées (rôle d’éducateur)
• Partager les résultats des tests unitaires/globaux en
précisant la « nature » des RPOs et si besoin les
composants applicatifs non testés
• Utiliser les besoins du PCA métiers pour établir un
schéma directeur du secours du SI
• Disposer d’une « Charte Continuité d’Activité » formalisant les principes directeurs en matière de continuité et les
engagements réciproques
• Etablir une instance bipartite PCA/PSI pour fluidifier les échanges (via des réunion mensuelles) et établir un dialogue
constant, ne se limitant pas à la transmission d’une liste de besoins « bruts »
• Partager un référentiel applicatif commun et engager un processus d’amélioration continue pour l’harmonisation des
dénominations
• Clarifier les questions budgétaires et de refacturation
• Argumenter/Justifier les besoins métiers (impacts
financiers, nouveaux objectifs stratégiques ou autres…)
• Veiller à fournir des documents propres à la DSI (listes
d’applications sans doublons avec informations
techniques et mode d’accès pour nouvelle application
détectée)
• Profiter des campagnes BIA pour sensibiliser les métiers
aux bonnes pratiques (stockage de données et
hébergement d’applications, mise à jour des
référentiels)
• Partager les exigences, contraintes et insatisfactions
métiers liées à l’usage du SI (ex: problèmes de
performance)
• Maintenir un Gap Analysis entre besoins exprimés et
situation réelle
ET SURTOUT :
21
FACTEURSDE
COMPLEXITE
CONCLUSIONINTRODUCTION
RECOVERYTIME
OBJECTIVE
TESTSET
EXERCICES
INVENTAIREDES
SOUFFRANCES

23. © Copyright Hapsis 2015. Tous droits réservés
MERCI !
POUR ALLER PLUS LOIN …
Contactez-nous :
David Abgrall : david.abgrall@hapsis.fr
Dominique Nadjar : dominique.nadjar@hapsis.fr
Tel : 01 53 16 30 60
www.hapsis.fr
CONTACT
22
DES QUESTIONS ?