Dans une entreprise, la mise en place d’un PSI a des répercussions sur tous les services. Ce plan de secours oblige aussi à segmenter les applications selon des contraintes de continuité et à multiplier les tests. Avec un seul objectif : optimiser la reprise d’activité.
Les PSI sont devenus très complexes. Établir la liste des applications critiques touchées par un sinistre, par exemple, est très difficile, car les technologies informatiques ont beaucoup évolué et sont multiplateformes. Il n’est plus possible de se contenter d’avoir un plan de secours comme il y a 10-15 ans où les architectures étaient très centralisées.
Aujourd’hui, le PSI est « un retour aux sources qui remet au premier rang l’utilisateur. Ce qu’il faut redémarrer en priorité ce sont les machines impactées qui correspondent aux activités critiques. La mission première est donc de déterminer quels salariés et quelles applications sont critiques. Les entreprises doivent ainsi établir leurs exigences en matière de continuité et la DSI en tenir compte avec des architectures à résilience appropriée », explique Emmanuel Besluau, consultant associé au Duquesne Group
Les entreprises ne doivent plus se centrer sur l’informatique, mais concentrer leurs efforts sur la criticité des métiers, dont l’informatique hérite. « Un Plan de Secours Informatique est une première brique essentielle. Pour les utilisateurs, il représente une sécurité et un confort. Pour la maîtrise d’ouvrage, il induit deux obligations. Premièrement, celle de concevoir des applications de telle façon qu’elles puissent fonctionner de manière continue. Deuxièmement, celle de formuler ses contraintes et de ses objectifs de continuité pour pouvoir les insérer dans le schéma global. C’est une tâche complexe, car l’interconnexion entre les différentes applications rend ardue la détermination d’un niveau de sécurité qui serait spécifique à chaque application », précise André Schwob, Directeur des Processus et des Systèmes d’Information à la Caisse des dépôts.
« Pour qu’il soit efficace, il faut que tous les services aient confiance en son activation. En conséquence, un plan de secours ne doit pas être lancé uniquement en cas de sinistre. Il doit être testé et mis à jour régulièrement. Il est également indispensable de bien segmenter les divers niveaux de service possibles. Par exemple, les besoins et donc solutions ne seront pas les mêmes entre des applications supportant des processus de type guichet recevant du public, des applications saisonnières comme la gestion des concours ou des applications moins critiques en termes de disponibilité, mais pour lesquelles la fraîcheur des données est primordiale», rappelle Annelise Massiera, Senior Entreprise Architect chez Axa.
Pour un PSI, l’être humain doit être le maillon-clé de sa réussite. « Cela nécessite un vrai travail de conception des processus, de finalisation des chaînes de décision avec des personnes qui ont compris ce qu’elles avaient à faire », insiste André Schwob.