Définir le seuil de viabilité minimale avec Constellation Energy

La viabilité minimale désigne l’ensemble minimal de capacités essentielles – ressources humaines, processus et technologies – nécessaires pour maintenir une entreprise opérationnelle en cas de perturbation majeure. 

Elle nécessite des décisions de la direction, une coordination interfonctionnelle et une hiérarchisation des résultats, ce qui en fait une discipline stratégique plutôt qu’un simple exercice technique. 

Les interruptions pouvant souvent durer plusieurs semaines, la viabilité minimale offre le moyen le plus rapide de rétablir les opérations essentielles et de réduire l’impact financier et sur la réputation. 

Grâce à une analyse interfonctionnelle des dépendances, des flux de travail et des services d’identité, qui permet souvent de mettre au jour des systèmes critiques qui avaient été négligés auparavant. 

La viabilité minimale relève d’une responsabilité partagée entre les services informatiques, la sécurité, les opérations, la gestion des risques, les finances et la direction générale. 

Veuillez visionner la vidéo ici pour obtenir une transcription horodatée

Bonjour et bienvenue dans cet épisode du podcast SHIFT.

Cet épisode est consacré à la mise en place de la viabilité minimale, afin d’en faire l’atout le plus
précieux pour votre entreprise.

Bonjour à tous, je m’appelle Vidya Shankaran, directrice technique sur le terrain chez Commvault, et je suis aujourd’hui accompagnée de Ha
Hoang, directeur informatique chez Commvault Technologies, et de Jay, directeur informatique chez Constellation Energy.

Merci de vous joindre à nous aujourd’hui.

Merci de nous accueillir.

Merci de nous accueillir.

Bien sûr.

En général, lorsqu’on parle de viabilité minimale, la durée moyenne d’indisponibilité enregistrée
dans le secteur, selon les statistiques les plus optimistes, est de 24 jours.

Mais pour la plupart des entreprises, c’est une durée trop longue à supporter.

Ce n’est pas tout : il faut également tenir compte de l’impact financier sur le chiffre d’affaires que cela peut avoir sur les entreprises,
sans parler de l’atteinte à la réputation que subit l’entreprise pendant ces 24 jours d’

.

C’est pourquoi, aujourd’hui, le secteur définit la viabilité minimale comme un ensemble minimal de capacités comprenant
les personnes, les processus et, bien sûr, la pile technologique qui constituent cette

viable.

Et le rétablissement de cette viabilité minimale devient le moment décisif qui déterminera si l’entreprise
pourra survivre et prospérer après une cyberattaque.

Puisque la viabilité minimale est le sujet de notre discussion d’aujourd’hui, je suis ravi que Ha.

et Jay se joignent à nous.

Ma première question à Ha serait la suivante : comment définiriez-vous la viabilité
minimale au-delà de l’idée fausse probablement répandue dans le secteur selon laquelle il s’agit simplement d’une liste de contrôle informatique ?

Comment aborder ce sujet avec un état d’esprit de dirigeant ?

Pour moi, la viabilité minimale relève moins de la pile technologique que de la clarté décisionnelle.

Il s’agit donc de se demander : quel est le plus petit ensemble de capacités dont nous avons besoin pour faire tourner l’entreprise
alors que tout le reste est à l’arrêt, n’est-ce pas ?

C’est donc un état d’esprit qui impose une certaine discipline, consistant à donner la priorité aux résultats et pas seulement
à l’infrastructure, n’est-ce pas ?

Je pense donc que lorsque l’on adopte cette perspective, la planification de la Recovery devient un débat de direction
portant sur les compromis, et non plus un simple exercice technique, n’est-ce pas ?

Et cela contribue également à instaurer une responsabilité partagée entre les différentes unités opérationnelles, la gestion des risques et…
euh… l’informatique.

C’est tout à fait logique.

Maintenant, puisque nous avons le plaisir de vous accueillir parmi nous aujourd’hui, Jay, que signifie la « viabilité minimale »
pour une entreprise d’infrastructures critiques comme Constellation Energy, où

les temps d’arrêt sont absolument inconcevables ?

Eh bien, je pense que je vais probablement rebondir un peu sur ce dont vous parliez.

C’est le sport d’équipe par excellence.

N’est-ce pas ?

Je veux dire, ce n’est pas une discussion qui concerne uniquement l’informatique.

Ce n’est pas une discussion avec les différentes divisions de l’entreprise.

Ce n’est pas une discussion avec le service de sécurité, ni avec le service informatique.

C’est vraiment une discussion qui concerne tout le monde.

Car au fond, c’est bien cela que signifie « entreprise minimale viable », n’est-ce pas ?

Qu’est-ce que cela signifie pour moi de continuer à faire fonctionner mon cœur de métier ?

N’est-ce pas ?

Et à quoi cela ressemble-t-il ?

Pour moi, le message le plus important, c’est qu’il s’agit d’un travail d’équipe, car aucun groupe
ne peut y parvenir seul

Aucun groupe ne peut y arriver tout seul.

J’adore ça.

Et je dois vous poser cette question à vous deux.

Je vais sans doute commencer par Ha.

Y a-t-il eu des écueils ou des surprises qui vous ont pris au dépourvu lorsque vous avez établi la
liste des actifs critiques minimaux viables ?

Oui, tout à fait.

Il y en a eu quelques-uns.

Certains des systèmes ou applications fondamentaux

que nous considérions comme indispensables, vous voyez, n’y figuraient clairement pas, n’est-ce pas ?

Ou n’ont pas été retenus dans notre liste.

Et puis je pense que des systèmes comme celui de gestion des identités, que l’on considère souvent comme secondaire, s’avèrent
en réalité assez essentiels.

Et parfois, euh, on se concentre surtout sur ce que voit le client, c’est-à-dire les
applications, n’est-ce pas ?

Mais si l’on se demande s’il s’agit d’un service de transition, de gestion des identités ou
simplement de systèmes de base interdépendants,

ce sont ceux-là qui, à mon avis, sont essentiels.

J’adore ça.

J’ajouterais que tout ça, c’est votre affaire.

Et si quelqu’un vous dit que ce n’est pas le cas, c’est qu’il invente tout ça.

Personne ne l’a jamais fait auparavant, n’est-ce pas ?

C’est la première fois qu’on commence vraiment à y réfléchir : on parle depuis toujours
de « produit minimum viable », mais jamais d’« entreprise minimum viable ».

Je pense que le plus important pour moi, c’est que nous avions une vision très traditionnelle du monde, où nous classions
les applications en trois catégories : celles à forte valeur commerciale, celles à valeur commerciale moyenne et celles à faible valeur commerciale.

Et on se disait : « Bon, c’est facile.

On va simplement récupérer les applications à forte valeur commerciale et le tour est joué.

Ce qu’on a appris, c’est qu’une grande partie de ces applications à faible valeur commerciale jouait
probablement un rôle pour alimenter ou fournir quelque chose aux applications à forte valeur commerciale.

Donc, raisonner en termes qui semblaient très absolus ne fonctionne pas lorsqu’on parle d’entreprise
minimalement viable, n’est-ce pas ?

Car on parle d’un système, et non d’applications individuelles.

Et cela a été la plus grande révélation pour nous.

Et je parierais que c’est le cas pour beaucoup de gens.

Je trouve que c’est une

expression qu’il vient d’utiliser : il ne s’agit pas d’un « produit minimum viable », mais d’une « entreprise minimum
viable ».

Ce qui m’amène au point suivant.

Dans tout cet exercice, dans quelle mesure avez-vous pu compter sur un partenariat avec votre RSSI,
notamment pour définir certains de ces actifs critiques et déterminer à qui incombent ces mesures de Recovery

?

Oui, vous avez identifié les actifs critiques, mais qui aide ensuite à

établir les priorités des opérations de Recovery ?

Oui.

Comme je l’ai dit, c’est un sport d’équipe, mais il faut aussi un arbitre.

Je pense donc qu’à bien des égards, le DSI et le responsable de la sécurité informatique jouent un peu le rôle d’arbitre
dans ce cas-là, car quand on commence à simuler le scénario sur table, on s’aperçoit qu’on avait un excellent partenaire qui

nous a aidés chez WWT et qui nous a vraiment aidés à réfléchir à tout cela et à passer
en revue à la fois le processus technique, mais aussi les

je dirais les processus organisationnels, car ce qu’on finit par comprendre, c’est que chacun estime
que son domaine est le plus important.

Je pense donc que le plus important pour le DSI et le RSSI est de se concentrer sur la manière d’assumer
ce rôle de juge et de juré, mais aussi de veiller à se concentrer sur, comme vous l’avez mentionné,

certaines technologies fondamentales, comme l’identité et le réseau, n’est-ce pas ?

Sans cela, rien ne fonctionne.

Il s’agit donc aussi d’aider les gens à comprendre

cette pièce du puzzle.

C’est ainsi que je conçois leur rôle, n’est-ce pas ?

J’adore ça.

À toi, Ha.

Dans tout ça, pour revenir à ce qu’a dit Jay sur le fait qu’il s’agit d’un travail d’équipe, as-tu rencontré des
difficultés pour monter le dossier commercial lorsque tu l’as présenté, sans doute, à l’équipe financière

, à l’équipe chargée de la gestion des risques et à celle de la conformité ?

Et quelles étaient certaines des idées fausses qui s’étaient déjà infiltrées dans ces

secteurs d’activité et que vous avez dû dissiper avant de pouvoir faire valoir le cas d’utilisation autour
de la viabilité minimale ?

Pour rassembler ces équipes, il fallait évidemment présenter la notion de viabilité minimale sous
un angle différent, n’est-ce pas ?

Il fallait l’aborder en termes commerciaux et non pas dans le jargon de Backup and Recovery, n’est-ce pas ?

Ainsi, pour la direction financière, il s’agit, vous le savez, de garantir la continuité des revenus.

Pour les équipes chargées de la gestion des risques, il s’agit de limiter l’exposition.

Et pour les équipes opérationnelles, il s’agit avant tout de préserver l’intégrité des clients.

Je pense donc que c’est lorsque les équipes et les fonctions se reconnaissent dans la stratégie de viabilité minimale
que l’alignement s’opère.

Quant aux idées reçues, je pense que la plus répandue est de croire que la viabilité minimale
équivaut à un effort minimal.

Comme s’il s’agissait d’abaisser les normes ou d’accepter une reprise partielle.

C’est un excellent argument.

En réalité, c’est tout le contraire, n’est-ce pas ?

Euh… Il s’agit en réalité de discipline et, euh, de se concentrer sur ce qui, véritablement, euh, favorise la continuité et
la résilience quand chaque minute compte, n’est-ce pas ?

Et puis je pense que l’autre idée fausse, c’est de croire qu’il s’agit d’une question purement technologique, n’est-ce pas ?

Du coup, les conseils d’administration et les DSI comme nous s’attendent à une liste de contrôle ou à un schéma architectural, mais en
réalité, c’est un débat de stratégie d’entreprise, n’est-ce pas ?

Sur la manière dont les entreprises hiérarchisent réellement les priorités en matière de valeur lorsqu’elles sont sous pression, ce qu’elles décident de protéger et
pourquoi.

J’adore ce slogan que vous venez d’évoquer : « Comment hiérarchiser la valeur
métier sous pression ».

Je vais probablement…

le mettrais en gras, le surlignerais et insisterais dessus à l’envi, car c’est là l’essence même de la
définition du MVC.

Ce qui m’amène au point suivant.

Nous avons parlé de stratégie.

Nous avons expliqué en quoi il s’agit d’un travail d’équipe.

Mais quels sont les indicateurs clés de performance (KPI) ?

Comment peut-on même les quantifier et les mesurer ?

Ce ne sont pas vraiment des indicateurs tangibles par excellence, n’est-ce pas ?

Ou est-ce que je passe à côté de quelque chose ?

Est-ce que ce sont vos RPO et RPTO qui vous guident ?

Quelles seraient les unités de mesure de la réussite basées sur le MVC ?

Je pense que, pour ma part, je vais peut-être commencer par m’éloigner un peu de l’aspect « indicateurs », puis on reviendra peut-être sur les indicateurs.

Mais pour moi, l’important est de s’assurer que l’on n’utilise pas le système uniquement en cas de crise.

Je pense que c’est une idée fausse courante de se contenter de dire : « On va s’entraîner à ça et
on aura ce système. »

De notre côté, nous avons réorienté

toutes nos sauvegardes et restaurations vers Commvault, car nous voulions que les équipes utilisent ce système au
quotidien.

Nous voulions donc nous assurer qu’elles sachent comment utiliser le système, comment s’en servir,
comment en maîtriser tous les tenants et aboutissants, car, vous savez, on parle d’être sous pression,

n’est-ce pas ?

Ce n’est pas le moment d’essayer quelque chose de nouveau.

C’est donc l’un des aspects.

Et je vais rebondir sur le dernier point dont vous parliez, qui concernait également la reprise après sinistre,
n’est-ce pas ?

Je pense qu’une autre idée fausse courante est de croire qu’on dispose déjà d’une solution de reprise après sinistre.

Pourquoi en aurais-je besoin ?

N’est-ce pas ?

Je veux dire, j’en ai déjà une.

Et je pense

encore une fois, quand on pense à la reprise après sinistre, c’est un peu une vision dépassée, non ?

C’est une approche qui repose, faute d’un meilleur terme, sur une sorte d’idée de « trou dans le sol », n’est-ce pas ?

Si je n’ai pas cette chose-là, que se passe-t-il ?

Eh bien, je ne pense pas qu’aucun de nos univers n’existe dans moins de cinq autres « nuages » ou cinq autres
univers.

Je pense donc vraiment qu’il s’agit, d’une part, de changer de mentalité, et d’autre part, de modifier
vos opérations pour ne pas vous contenter d’agir uniquement en cas de crise.

Voilà donc comment je vois les choses.

J’adore ça.

Je suis tout à fait d’accord.

Oui, évidemment, on examine les indicateurs quantitatifs et qualitatifs, n’est-ce pas ?

Et, tu sais, techniquement, tout le monde va mesurer les RPO et les RTO, n’est-ce pas, ainsi
que le pourcentage de données de sauvegarde « propres », etc.

Mais je pense que ce sur quoi je me concentre et que je surveille également, c’est la rapidité avec laquelle nous pouvons prendre des décisions en toute confiance
sous pression, n’est-ce pas ?

Car je pense que la « Readiness » ne se résume pas seulement à la rapidité avec laquelle on peut récupérer ou restaurer des données, mais aussi à
la rapidité avec laquelle on peut faire confiance aux données et au système que l’on restaure.

Dans quelle mesure tout cela se résume-t-il en fin de compte à la mise en œuvre des tests ?

Tout.

Énormément.

Oui.

Je veux dire, c’est toujours ça qui compte au final, n’est-ce pas ?

La préparation, l’entraînement.

Écoute, dans notre milieu, on s’entraîne beaucoup.

On s’entraîne à tout ce qu’on fait.

Parce qu’on veut être sûr que, quand on en a vraiment besoin ou qu’on est sous pression,
on soit capable de le faire.

Et je pense que c’est pareil ici.

La bonne nouvelle, ou peut-être la mauvaise, c’est que nous avons tous eu de nombreuses occasions de nous
entraîner récemment, n’est-ce pas ?

Que ce soit à cause de pannes du cloud ou de fournisseurs qui font n’importe quoi, n’est-ce pas ?

Nous avons eu l’occasion de nous entraîner à cela.

Et l’autre chose que je voudrais dire, c’est qu’il faut saisir ces occasions pour se dire :
n’ayez pas peur de tirer parti du système dont vous disposez, n’est-ce pas ?

Vous avez mis en place un système, utilisez-le.

Comment puis-je l’utiliser

pour me remettre sur pied plus rapidement ?

Comment l’utiliser, qu’il s’agisse de la Recovery d’un cloud particulier ou d’un incident en
cours, n’est-ce pas ?

Je pense qu’il s’agit de se projeter dans l’avenir et de l’utiliser, plutôt que de le mettre de côté en se disant :
« Oh, est-ce que je dois m’occuper de la reprise après sinistre ?

Du genre : « Est-ce que je dois vraiment faire ça ? »

On a tous cette mentalité.

Il ne faut pas se contenter de le configurer et de l’oublier.

Exactement.

C’est là, il suffit de s’en servir.

Oui, et c’est clairement un point sur lequel les organisations doivent s’améliorer.

Ce n’est pas

exercice que l’on fait une fois pour toutes.

C’est un processus évolutif qu’il faut sans cesse améliorer.

Et soyons honnêtes, c’est aussi un domaine en constante évolution, n’est-ce pas ?

Le volume de données et tout le reste ne ralentissent pas.

Pour presque tout le monde, le produit que vous avez lancé ne représente qu’une fraction de ce que
vous êtes aujourd’hui.

Ça change vraiment la donne, n’est-ce pas ?

Exactement.

Ce qui m’amène à la question suivante, la plus cruciale, et qui était la plus difficile.

Était-ce la mise en œuvre technique ou le changement culturel ?

Je dirais sans aucun doute le changement culturel.

Le travail technique est complexe, mais il est réalisable.

On peut l’automatiser et le tester pour y parvenir.

Mais le plus difficile, c’est le changement de mentalité : passer, je pense, d’une conception où Recovery est une tâche informatique à
celle où la résilience est en réalité une

de l’entreprise.

Oui.

Oui.

Je veux dire, je suis d’accord.

Je dirais que l’aspect technique est facile, car je dispose d’une formidable équipe technique qui
donne l’impression que tout est vraiment simple.

Mais je pense vraiment que la technologie n’est pas un obstacle, n’est-ce pas ?

Ce ne sont que des uns et des zéros, et on peut tout comprendre.

Le problème, c’est que le discours a toujours été : « Allez, les informaticiens, faites votre boulot et prévenez-nous quand
vous aurez fini », n’est-ce pas ?

Ce n’est plus du tout comme ça aujourd’hui.

Et pour moi, c’est là le plus grand changement : il faut désormais réunir tous les dirigeants de l’entreprise dans
une même pièce pour leur dire : « Bon, il faut qu’on discute de Recovery. »

Et ce n’est plus simplement : « Bon, les informaticiens, prévenez-nous quand vous aurez fini. »

Et c’est ça, le changement culturel.

Je suis tout à fait d’accord.

Je pense que la viabilité impose des discussions un peu délicates sur
la hiérarchisation des priorités, n’est-ce pas ?

Ce qui doit vraiment être fait dans les premières 24 heures, par opposition à ce qui peut attendre.

Et c’est là que, selon moi,

nous demandons essentiellement aux dirigeants d’entreprise de faire des compromis en temps réel, et ce sont
là des discussions difficiles.

Oui.

Non, c’est tout à fait logique.

Et surtout, comme vous le soulignez, si vous demandiez à n’importe quel dirigeant d’entreprise, il
vous répondrait que son AppStack est important.

Tout est important.

C’est moi qui suis le plus important.

Oui, tout à fait.

Donc, après avoir abordé

et mis en pratique la mise en place de votre architecture MVC – et bien sûr, comme nous venons d’en discuter, c’est
un processus en constante évolution –,

mais quels sont les principaux enseignements, ces « cicatrices de guerre », que tu aimerais
absolument partager avec tes pairs pour qu’ils ne se heurtent pas aux mêmes difficultés lorsqu’ils

développeront leur MVC ?

Je dirais : entraînez-vous à la Recovery, comme si c'était le jour du match, d'accord ?

Car on ne peut pas développer sa résilience en pleine crise.

Elle se construit grâce aux répétitions que l’on effectue au préalable.

Parfait.

Je pense que pour moi, et vous l’avez mentionné à plusieurs reprises – je ne le soulignerai jamais assez –
, c’est la couche fondamentale.

Je pense que, traditionnellement, on n’envisage tout simplement pas de se passer d’éléments fondamentaux tels
qu’Active Directory, le réseau, etc. Tous ces éléments sont désormais davantage définis par des logiciels

que jamais auparavant.

Et je pense que c’est le changement le plus important à prendre vraiment en compte et à mettre en pratique

et de comprendre : à quoi cela ressemble-t-il lorsque je dois rétablir mon système d’authentification central avant
que mes collaborateurs puissent commencer à travailler ?

Et c’est là que nous oublions toujours.

Les informaticiens ne peuvent rien faire sans cela.

Et je pense que c’est là le point crucial de la bataille par excellence.

Et franchement, je pense que c’est l’une des choses que
Commvault fait mieux que quiconque : cette restauration au niveau de la forêt Active Directory, qui est absolument essentielle et qui a été l’un des

principaux facteurs qui nous ont poussés à choisir ce produit.

Merci de votre attention.

Merci d’avoir partagé ce point de vue.

Et avant de vous laisser partir tous les deux, quelles sont ces phrases percutantes, ces petites répliques
qui font mouche, que vous aimeriez nous laisser en guise de conclusion ?

Oh là là, je crois que je viens justement de le dire.

Entraînez-vous à la Recovery comme si c’était le jour du match.

Parfait.

J’adore ça.

Pour moi, c’est un sport d’équipe.

Et on ne peut pas simplement confier ça à son équipe informatique en leur disant : « Tenez-moi au courant quand ce sera fait. »

C’est un sport d’équipe qui nécessite que tout le monde soit présent pour en discuter.

Parfait.

Merci beaucoup d’être venu nous rejoindre aujourd’hui et d’avoir partagé vos réflexions.

C’est très enrichissant.

Et à tous nos spectateurs qui nous rejoignent virtuellement, si vous souhaitez approfondir les concepts liés
à la viabilité minimale, n’hésitez pas à consulter notre rapport d’analyse Giga Om, qui aborde

plus en détail la viabilité minimale, disponible sur Commvault.com.

Merci de votre attention.