GuideReprise informatique
Trois niveaux de lecture · direction · gestionnaire · praticien

Votre organisation tiendrait combien de temps sans son informatique ?

Ce guide ne vous apprendra pas à écrire un plan de reprise informatique : il vous fait mesurer, en vingt minutes, l'écart entre ce que vous croyez tenir et ce que vous tenez vraiment. Neuf chapitres courts, un autodiagnostic en douze questions, et sept actions à poser dans les trente prochains jours, sans budget.

0chapitres
0questions
0étapes essentielles
0actions en 30 jours
0de lecture
1Le jour où

L'informatique s'arrête, et le reste s'arrête avec elle

Une panne informatique ne se vit pas comme un incident technique. Elle se vit comme une série de renoncements, heure par heure, dans des services qui n'ont rien à voir avec l'informatique.

Ce qui se passe vraiment, dans l'ordre

Le premier quart d'heure ressemble à une panne ordinaire : on redémarre, on appelle, on attend. C'est vers la deuxième heure que la nature du problème change. Le personnel cherche des contournements, chacun le sien. Les décisions se prennent sans les données. Vers la fin de la première journée, la question n'est plus « quand ça revient » mais « qu'est-ce qu'on annule ».

Direction Ce qu'il faut retenir

Une panne informatique longue n'est pas un problème d'informatique : c'est un problème de services rendus. Les premières victimes sont la paie, la facturation, les rendez-vous, l'accueil du public. Ce sont vos équipes, pas votre équipe TI, qui absorbent le choc, et elles improvisent si personne n'a écrit d'avance ce qu'elles doivent faire.

Gestionnaire Ce qu'il faut regarder

Ce que la panne révèle est toujours la même chose : personne ne sait dans quel ordre redémarrer.

  • Quelles activités sont réellement à l'arrêt, et lesquelles tournent encore en mode papier.
  • Qui a le mandat de décider d'annuler, de reporter, de fermer.
  • Comment on parle aux usagers quand les canaux habituels sont en panne eux aussi.
  • Ce que l'on perd de façon définitive à chaque heure qui passe.

La distinction utile est entre l'interruption et la perte. L'interruption se rattrape : le service reprend, le retard se résorbe. La perte de données ne se rattrape pas, elle se ressaisit ou elle disparaît. Ces deux dimensions se mesurent séparément, par le DMIA et le PDMA, et c'est de là que part tout le reste du plan.

Avant
  • Cartographier la dépendance de chaque service à ses applications.
  • Documenter le mode dégradé de chaque activité critique.
Pendant
  • Qualifier vite : panne, sinistre matériel ou cyberattaque.
  • Tenir un journal horodaté des décisions, il servira au bilan et à l'assureur.
Après
  • Mesurer la durée réelle et la comparer aux objectifs affichés.
  • Réviser les priorités à la lumière du vécu, pas de la théorie.
Sources · ISO 22301:2019, systèmes de management de la continuité d'activité · NIST SP 800-34 Rev. 1, Contingency Planning Guide
2Idées reçues

Trois convictions rassurantes qui coûtent cher le jour venu

Elles ont toutes les trois un fond de vrai. C'est exactement ce qui les rend dangereuses : elles ne se corrigent pas en réunion, elles se corrigent en essayant.

« On a des sauvegardes »

Une sauvegarde qui se termine sans erreur n'est pas une sauvegarde restaurable. Seule une restauration réelle le prouve. Et le test utile n'est pas de récupérer un fichier : c'est de remonter un serveur complet et de le faire fonctionner, avec son application.

Direction Ce qu'il faut retenir

Demandez une seule chose à votre équipe : « Quand avons-nous restauré un serveur complet pour de vrai, et combien de temps ça a pris ? » Si la réponse est une date, vous êtes en avance sur la majorité. Si la réponse est « les sauvegardes sont vertes », vous venez de mesurer votre écart.

Gestionnaire Ce qu'il faut exiger

  • Une restauration complète par trimestre, sur un système différent chaque fois.
  • Le chronomètre : la durée réelle, notée, comparée à l'objectif.
  • Une copie que le réseau ne peut pas atteindre, ou qu'aucun compte ne peut effacer.
  • Un serveur de sauvegarde sorti du domaine, avec ses propres comptes.

La règle de référence est le 3-2-1-1-0. Le zéro final est le chiffre qui manque presque partout, et le second « 1 », la copie hors ligne ou immuable, est celui que les rançongiciels ont rendu indispensable : c'est la seule copie qui échappe à l'attaquant par construction plutôt que par configuration.

3 et 2
  • Trois copies, dont deux de sauvegarde.
  • Deux technologies aux modes de défaillance différents, pas deux baies identiques.
1 et 1
  • Une copie hors site, assez loin pour ne pas subir le même sinistre.
  • Une copie hors ligne ou à rétention verrouillée.
0
  • Zéro erreur de restauration, vérifiée par une restauration réelle.
  • Montage automatique en bac à sable quand l'outil le permet.
Sources · Centre canadien pour la cybersécurité, rançongiciels · ISO/IEC 27031, préparation des TIC à la continuité

« On est dans le nuage, c'est géré »

L'hébergeur garantit son infrastructure. Il ne garantit ni vos données, ni vos configurations, ni le délai dans lequel votre service redémarre. La responsabilité est partagée, et la part qui vous revient est précisément celle dont on s'aperçoit le jour de l'incident.

Direction Ce qu'il faut retenir

Le nuage déplace le risque, il ne le supprime pas. Un fournisseur indisponible, c'est un service à l'arrêt sans qu'aucune de vos équipes puisse agir. La vraie question devient : combien de temps peut-on tenir sans lui, et qu'a-t-on prévu pendant ce temps ?

Gestionnaire Ce qu'il faut vérifier

  • Ce que le contrat promet vraiment : délai d'intervention ou délai de rétablissement.
  • Qui sauvegarde les données que vous déposez chez le fournisseur, et où.
  • Le mode dégradé pendant l'indisponibilité, écrit, pour chaque service touché.
  • Votre capacité à récupérer vos données si vous quittez le fournisseur.

« C'est un dossier informatique »

L'informatique sait redémarrer des systèmes. Elle ne peut pas décider lesquels redémarrer en premier : cet arbitrage appartient aux métiers, parce qu'il porte sur des services rendus à des gens. Un plan de reprise écrit sans les métiers redémarre les systèmes les mieux documentés, pas les plus utiles.

Direction Ce qu'il faut retenir

Votre rôle n'est pas de comprendre l'architecture. Il est de trancher l'ordre de redémarrage et d'assumer ce que cet ordre implique pour ceux qui attendent. C'est le seul arbitrage que personne d'autre ne peut faire à votre place, et il se fait à froid.

Gestionnaire La technique qui marche

Forcer un classement contraint : trois activités au maximum en première vague, pas une de plus. Sans cette contrainte, on obtient une liste où quinze activités sont critiques, ce qui revient à n'avoir aucune priorité et laisse l'informatique décider seule le jour de la crise.

3Deux chiffres

Tout le plan tient sur deux nombres, et vous seul pouvez les fixer

Le délai que l'on accepte avant de rétablir, et la quantité de travail que l'on accepte de perdre. Tout le reste, architecture et budget compris, découle de ces deux réponses.

Le délai tolérable, et la perte tolérable

Le DMIA est le temps maximal pendant lequel une activité peut rester interrompue avant que les conséquences deviennent inacceptables. Le PDMA est la quantité de données que l'on accepte de perdre, exprimée en temps de travail. Ils se lisent ensemble : on peut très bien tolérer quatre heures d'arrêt mais aucune perte de saisie, ou l'inverse.

Direction Ce qu'il faut retenir

Ces deux chiffres ne sont pas techniques : ce sont des décisions de gestion. Plus ils sont serrés, plus la solution coûte cher, et l'écart de coût entre « une journée » et « quinze minutes » change d'ordre de grandeur. Les fixer, c'est arbitrer entre un risque accepté et une dépense.

Gestionnaire Le chiffre à challenger

Un métier répond souvent « aucune perte » par réflexe, alors qu'il ressaisirait sans difficulté une demi-journée de travail à partir de ses propres documents.

  • Demander comment la ressaisie se ferait concrètement, et par qui.
  • Chiffrer le coût de l'heure d'arrêt avant de discuter du délai.
  • Vérifier si une exigence réglementaire fixe déjà le délai : dans ce cas, il n'est pas négociable.
  • Comparer le chiffre demandé à ce que l'infrastructure tient aujourd'hui.

Ces objectifs sortent de l'analyse d'impact, qui regarde les conséquences et non les causes : peu importe pourquoi l'application est tombée, ce qu'on mesure est ce que l'arrêt coûte à mesure que les heures passent. C'est cette propriété qui rend l'analyse réutilisable pour tous les scénarios et qui évite la discussion sans fin sur la probabilité des menaces.

Ce que le PDMA commande
  • La fréquence des sauvegardes.
  • La technologie : sauvegarde de nuit, journalisation, protection continue.
Ce que le DMIA commande
  • Le site de reprise et son niveau de préparation.
  • Le niveau de service négocié avec les fournisseurs.
Le piège
  • Un objectif affiché que personne n'a jamais mesuré en restauration réelle.
  • Des objectifs fixés système par système, sans vue d'ensemble des dépendances.
Sources · ISO 22301:2019, clause 8.2 analyse d'impact · NIST SP 800-34 Rev. 1, section 3.2
4Autodiagnostic

Douze questions, et vous saurez où vous en êtes

Ne cochez que ce que vous pouvez prouver par un document ou une date. Une intention ne compte pas. Votre état se sauvegarde dans ce navigateur, et le bouton d'export vous en donne une copie.

Les trois verdicts

0 à 4 cases : vous êtes exposé. Le chapitre 8 vous donne sept actions à poser dans les trente jours, sans budget. 5 à 9 : vous avez des morceaux, pas un plan ; l'ordre de redémarrage et le test sont vos deux chantiers. 10 à 12 : vous avez un plan vivant, la question devient sa mise à l'épreuve et son maintien dans le temps.

0 / 12 items couverts
Ce que vous savez0 / 4
Ce que vous avez0 / 4
Ce que vous avez prouvé0 / 4
5Cinq étapes

La démarche complète, ramenée à ce qui ne peut pas sauter

Chaque étape produit ce dont la suivante a besoin. On peut alléger une étape, on ne peut pas en sauter une : le manque se paie plus loin, toujours plus cher.

1
Cadrer

Nommer un responsable, écrire les objectifs et délimiter le périmètre. Ce qui entre, et surtout ce qui n'entre pas. Un périmètre non écrit s'étend tout seul jusqu'à ce que le projet devienne infaisable, et c'est la première cause d'abandon.

2
Mesurer les besoins

Aller chercher auprès des métiers l'ordre de redémarrage, le délai toléré et la perte tolérée. C'est le métier qui répond, pas l'informatique : c'est ce qui rend l'arbitrage légitime et opposable le jour de la crise.

3
Choisir les stratégies

Comment on tient face au matériel indisponible, aux données perdues, au site inutilisable, au fournisseur défaillant, au spécialiste absent. Chaque réponse est un arbitrage entre le coût de la protection et le coût des heures d'arrêt, présenté à la direction avec les deux chiffres côte à côte.

4
Écrire

Le plan et les procédures, dans un format utilisable sous stress, par quelqu'un qui n'a pas participé à leur rédaction. Le critère de qualité n'est pas l'exhaustivité, c'est qu'un renfort extérieur puisse s'en servir à trois heures du matin.

5
Tester et maintenir

Exercer, corriger, recommencer. Un plan qui n'est pas testé est une hypothèse écrite, quelle que soit la qualité de sa rédaction. C'est l'étape la plus souvent sacrifiée, et c'est celle qui fait la différence entre un document et une capacité.

6Le plan

Ce que contient un plan dont on se sert vraiment

Un plan de reprise informatique n'est pas un document d'architecture. C'est un mode d'emploi de crise, et sa table des matières s'en ressent.

La table des matières type

Les huit parties ci-dessous suffisent à couvrir l'essentiel. Ce qui compte n'est pas leur volume, c'est qu'aucune ne manque : chaque absence se traduit par une improvisation le jour venu.

Direction Les huit parties

  • Déclenchement : qui décide d'activer, sur quels critères.
  • Rôles : qui fait quoi, et qui remplace qui.
  • Communication : qui parle, à qui, par quel canal de secours.
  • Ordre de redémarrage : la séquence, validée par la direction.

Gestionnaire La suite

  • Procédures techniques de reprise, une par système essentiel.
  • Modes dégradés des activités, écrits avec les métiers.
  • Contacts et contrats : fournisseurs, assureur, autorités, hors courriel.
  • Retour à la normale, qui est une seconde opération à risque.

Trois règles de forme font la différence entre un plan lu et un plan classé. Il vit hors du système qu'il sert à rétablir, y compris sur papier. Il se nomme et se range selon une gestion documentaire écrite dès le démarrage du projet, sinon trois versions concurrentes du même plan circulent, ce qui est la situation la plus fréquente sur le terrain. Il contient un glossaire local : les surnoms de serveurs que seuls les anciens comprennent, et dont le nom ne figure dans aucune documentation officielle.

Format
  • Une page par procédure, numérotée, testable.
  • Rapport d'état de situation : format fixe, jamais plus d'une page.
Accès
  • Hors domaine, hors réseau, avec une copie papier au centre de coordination.
  • Une liste de diffusion connue d'avance.
Maintien
  • Revue annuelle allégée, plutôt qu'une refonte tous les cinq ans.
  • Mise à jour déclenchée par tout changement d'architecture.
Sources · NIST SP 800-34 Rev. 1, structure du plan de contingence · ISO/IEC 27031
7Tester

L'erreur numéro un : le plan que personne n'a jamais joué

Une redondance qui n'a jamais basculé n'est pas une redondance, c'est une hypothèse. Le premier exercice se prépare en une demi-journée et révèle plus que six mois de rédaction.

Commencer par l'exercice de table

On réunit les bonnes personnes autour d'une table, on leur annonce un scénario, et on leur demande ce qu'elles feraient, dans l'ordre, avec les moyens réellement disponibles. Rien n'est débranché, aucun système n'est touché. Ce qui remonte, ce sont les décisions manquantes, les rôles flous et les documents introuvables.

Direction Votre place dans l'exercice

Vous n'êtes pas spectateur. L'exercice sert précisément à voir si la direction sait décider sans données, sans courriel et sans certitude. C'est la partie que les exercices strictement techniques ne testent jamais, et c'est celle qui bloque le plus souvent le jour venu.

Gestionnaire Ce que l'exercice doit produire

  • Des objectifs écrits avant de commencer, et des critères de succès.
  • Une règle d'arrêt claire, connue de tous.
  • Un compte rendu avec des corrections datées et un responsable par correction.
  • Une date pour le prochain exercice, fixée le jour même.

Les exercices se montent par difficulté croissante : revue documentaire, exercice de table, test technique isolé, bascule réelle. Toute épreuve technique se joue dans un bac à sable étanche, avec un retour arrière préparé, hors période critique. Un programme d'exercice triennal avec une grille de couverture par scénario et par système rend visible ce qui n'a jamais été testé, souvent la moitié du périmètre.

Scénario cyber
  • On ne fait confiance à rien : la réplication a recopié la corruption.
  • La date de restauration dépend de la chronologie établie par l'analyse forensique.
Scénario sinistre
  • Site inutilisable : où travaille l'équipe, avec quels accès.
  • Délai réel de remplacement du matériel, contrat en main.
Scénario fournisseur
  • Service infonuagique indisponible plusieurs jours.
  • Mode dégradé métier, et communication aux usagers.
Sources · ISO 22301:2019, clause 8.5 programme d'exercice · NIST SP 800-34 Rev. 1, section 3.5
830 jours

Sept actions à poser dès maintenant, sans budget

Aucune de ces sept actions ne demande d'investissement. Elles demandent du temps de gestionnaire, et elles produisent chacune un document que vous n'aviez pas.

Jour 1

Nommer un responsable

Une personne, avec un mandat écrit et du temps dégagé. Sans ce nom, rien n'avance : le dossier revient à celui qui a déjà trop de dossiers.

Semaine 1

Écrire les trois activités de première vague

Trois, pas quinze. Le classement contraint est ce qui rend la discussion productive et l'arbitrage légitime.

Semaine 1

Lister les dix équipements sans lesquels tout s'arrête

En remontant depuis les services critiques, jamais depuis l'inventaire. La liste contient presque toujours une pièce unique que personne n'avait vue comme un point de rupture.

Semaine 2

Vérifier la copie hors ligne

Existe-t-elle ? Le réseau peut-il l'atteindre ? Un compte peut-il l'effacer avant l'échéance ? Trois questions, une réponse écrite.

Semaine 2

Restaurer un serveur complet, pour de vrai

Pas un fichier : un serveur, avec son application, qui démarre. Noter la durée. C'est votre premier chiffre honnête.

Semaine 3

Sortir les contacts d'urgence des boîtes courriel

Fournisseurs, numéros de contrat, procédure d'escalade, assureur. Sur papier, au centre de coordination, vérifiés une fois par an.

Semaine 4

Jouer un exercice de table de deux heures

Un scénario, les bonnes personnes, direction comprise. Un compte rendu avec des corrections datées, et la date du prochain.

9Aller plus loin

Quand le guide ne suffit plus

Ce guide couvre ce qu'on peut faire seul. Trois formations prennent le relais selon ce qui vous manque : la compréhension, le plan, ou la capacité à le jouer.

2 heuresDirection

Comprendre la reprise informatique

Pour la direction et les gestionnaires qui doivent arbitrer sans être techniciens. Six modules, dont un temps d'échange sur votre propre situation. À faire avant de lancer un projet, pas pendant.

7 ateliers de 3 hÉquipe projet

Construire son plan

La démarche complète, en ateliers de production : on repart avec le plan écrit, pas avec des notes. Cinq étapes, quatorze actions, et un portefeuille de gabarits remis remplis d'exemples.

1 journéeDirection et TI

Conduire une reprise informatique

La conduite de crise, avec une demi-journée d'exercice de table joué pour de vrai. C'est la formation qui manque presque partout : celle où l'on découvre ce que le plan ne dit pas.

Parler à quelqu'un qui l'a déjà fait

Crise et Résilience accompagne des organisations publiques et privées du Québec sur la continuité des activités, la reprise informatique et la gestion de crise. Si votre autodiagnostic vous a laissé une question, elle mérite une conversation de trente minutes plutôt qu'un projet de six mois mal cadré.

Pour écrire Nous joindre

Alexandre Fournier, Crise et Résilience. crise-resilience.com

Pour lire Le magazine

Le magazine Crise et Résilience publie quatre numéros par an sur la continuité, la cybersécurité et la gestion de crise. magazinecriseetresilience.com