Plan de continuité informatique : la méthode pour garder son système d’information debout en pleine crise

Quand le système d'information s'arrête, ce n'est pas seulement l'équipe informatique qui est bloquée : la facturation, la relation client, la paie et parfois la production s'arrêtent avec lui. Le plan de continuité informatique répond à une question simple, que l'on préfère traiter à froid plutôt qu'au cœur de la crise : que fait-on, dans quel ordre et avec quels moyens, si tel service informatique devient indisponible ? Bien construit, il permet de travailler en mode dégradé pendant l'incident, puis de revenir à la normale dans des délais connus à l'avance. Ce guide détaille son périmètre, son articulation avec le PCA et le PRA, une méthode de construction en cinq étapes, puis les erreurs qui rendent tant de plans inutilisables le jour J.

Ce que couvre un plan de continuité informatique dans le système d'information

Le PCI ne se limite pas aux serveurs. Son périmètre englobe tout ce dont dépend un processus métier pour fonctionner. Dans une entreprise de taille moyenne, cela comprend généralement :

• les infrastructures : serveurs physiques et virtuels, stockage, réseau local, liaisons internet, téléphonie ;
• les applications métiers, y compris les logiciels en SaaS dont l'entreprise n'a pas la maîtrise technique ;
• les données et leurs sauvegardes, avec les supports et les lieux où elles sont conservées ;
• les services d'identité (annuaire, authentification forte, gestion des accès), souvent oubliés alors qu'aucune reprise n'est possible sans eux ;
• les postes de travail et les accès distants, qui conditionnent la capacité des équipes à continuer depuis un autre lieu ;
• les prestataires et fournisseurs critiques : infogérant, hébergeur, éditeur, opérateur télécom.

Le plan décrit pour chacun de ces éléments la solution de secours prévue, le responsable de son activation et la procédure à suivre. Il précise aussi ce qu'est un fonctionnement en mode dégradé acceptable : saisir des commandes sur un formulaire papier pendant quatre heures peut être toléré, perdre une journée d'encaissements beaucoup moins.

PCI, PCA et PRA : trois plans de continuité qui ne se confondent pas

Les sigles se croisent dans la littérature et dans les appels d'offres, ce qui entretient la confusion. Le tableau ci-dessous résume la place de chacun.

En pratique, le PCI se concentre sur la continuité (haute disponibilité, redondance, bascule automatique), tandis que le PRA organise la reprise après coupure (restauration depuis sauvegarde, reconstruction d'un environnement). Beaucoup d'organisations rédigent un document unique intitulé PCA/PRA informatique : ce n'est pas un problème tant que les deux logiques sont clairement distinguées et que le tout reste rattaché au PCA global, qui seul peut arbitrer entre les priorités des différents métiers.

Mettre en place un plan de continuité informatique : la méthode pas à pas

Il n'existe pas de modèle universel, mais les démarches sérieuses, qu'il s'agisse des guides publics français ou des référentiels comme ISO 22301, suivent une progression comparable. La voici, découpée en cinq étapes.

Étape 1 : cartographier les processus métiers et leurs dépendances informatiques

On part des activités, pas des machines. Pour chaque processus (vente, logistique, comptabilité, souscription de contrats, gestion des sinistres pour un assureur), on liste les applications utilisées, les flux de données entrants et sortants, les interfaces avec des partenaires et les ressources techniques sous-jacentes. Cette cartographie révèle souvent des dépendances insoupçonnées : un serveur de fichiers ancien dont dépend encore un export réglementaire, un compte de service unique qui fait tourner trois traitements nocturnes.

Étape 2 : conduire le bilan d'impact sur l'activité

Le bilan d'impact (BIA, pour Business Impact Analysis) consiste à mesurer, avec les responsables métiers, les conséquences d'une interruption selon sa durée : une heure, une journée, une semaine. Les impacts sont financiers, mais aussi contractuels, réglementaires et d'image. Cet exercice débouche sur deux indicateurs par service, le RTO et le RPO, détaillés plus bas. C'est l'étape la plus politique de la démarche, car chaque direction a tendance à juger son outil indispensable : la validation finale doit revenir à la direction générale.

Étape 3 : analyser les risques et les scénarios de crise

On identifie ensuite ce qui peut provoquer l'indisponibilité. Les scénarios les plus utiles à travailler sont rarement exotiques :

• chiffrement des serveurs et des sauvegardes par un rançongiciel ;
• perte de la salle informatique (incendie, dégât des eaux, coupure électrique prolongée) ;
• indisponibilité d'un fournisseur cloud ou d'un éditeur SaaS ;
• coupure des liens réseau ou de l'opérateur télécom ;
• erreur humaine majeure, comme la suppression d'une base de production ;
• absence simultanée des personnes qui détiennent les accès administrateurs.

Étape 4 : choisir les solutions de secours adaptées à chaque service

Les solutions retenues découlent directement des objectifs fixés au BIA. Un service dont le RTO est de quelques minutes exige de la redondance active, par exemple une réplication synchrone vers un second site ou une architecture répartie sur plusieurs zones de disponibilité. Un service tolérant 48 heures d'arrêt peut se contenter d'une restauration depuis sauvegarde sur une infrastructure louée à la demande. Entre les deux, on trouve les sites de secours tièdes, les machines virtuelles préconfigurées, les contrats de remplacement matériel sous quatre heures. L'arbitrage est économique : chaque gain de disponibilité se paie, et le plan doit justifier où l'argent est investi.

Étape 5 : rédiger les procédures et organiser la cellule de crise

Le document final doit pouvoir être utilisé par une personne fatiguée, stressée, à trois heures du matin. Il contient les critères de déclenchement, l'arbre de décision, les procédures de bascule et de retour arrière, les annuaires de contacts (internes, prestataires, assureur cyber, autorités), les modèles de communication et la composition de la cellule de crise avec des suppléants désignés. Une version doit exister hors du système d'information, sur papier ou sur un support déconnecté, puisqu'il est possible que les serveurs qui l'hébergent soient justement ceux qui sont tombés.

RTO et RPO : chiffrer la tolérance à l'interruption de chaque service

Ces deux indicateurs structurent tout plan de continuité informatique, et leur confusion produit des plans mal calibrés.

• RTO (Recovery Time Objective) : la durée maximale d'interruption acceptable avant que le service ne soit rétabli. Un RTO de 4 heures signifie que l'application doit être de nouveau utilisable quatre heures après l'incident.
• RPO (Recovery Point Objective) : la quantité maximale de données que l'on accepte de perdre, exprimée en temps. Un RPO de 15 minutes impose que les données soient sauvegardées ou répliquées au moins tous les quarts d'heure.

Pour rester gérable, on regroupe généralement les services en trois ou quatre niveaux de criticité, par exemple : critique (RTO inférieur à 1 heure, RPO quasi nul), important (RTO de quelques heures, RPO de quelques heures), standard (RTO de 24 à 72 heures, RPO d'une journée). Un point mérite l'attention : le RTO annoncé n'a de valeur que s'il a été mesuré lors d'un test. Restaurer plusieurs téraoctets depuis une sauvegarde distante prend du temps, et ce temps est souvent sous-estimé de moitié sur le papier.

Cloud, rançongiciel, finance et assurance : les cas qui changent la donne

Le cloud ne dispense pas de plan. Héberger ses applications chez un grand fournisseur améliore la disponibilité de l'infrastructure, mais la responsabilité des données, des configurations et des accès reste partagée avec le client. Les contrats précisent rarement des engagements de reprise compatibles avec les besoins métiers, et la question de la responsabilité en cas d'incident reste un terrain mouvant. La justice française interroge la responsabilité des intégrateurs cloud dans des affaires récentes, ce qui rappelle l'intérêt de documenter précisément qui fait quoi dans le PCI, y compris la réversibilité et la récupération des données en cas de rupture du contrat.

Le rançongiciel impose des sauvegardes réellement isolées. Les attaquants ciblent désormais les sauvegardes en priorité, avant de chiffrer la production. La règle dite 3-2-1-1-0 sert de repère : trois copies des données, sur deux supports différents, dont une hors site, une immuable ou déconnectée, et zéro erreur constatée lors des tests de restauration. Le scénario cyber implique aussi des étapes que les plans classiques ignorent : isolement du réseau, investigation avant redémarrage, réinitialisation des identités compromises, déclarations auprès des autorités compétentes. L'analyse de l'impact orange lors de la cyberattaque visant l'opérateur illustre à quel point la réaction et la communication pèsent autant que la technique.

Les secteurs régulés ont des obligations formalisées. Pour les banques, assureurs, sociétés de gestion et une large partie des acteurs financiers, le règlement européen DORA, applicable depuis le 17 janvier 2025, exige une politique de continuité des activités liées aux technologies de l'information et de la communication, des plans de réponse et de rétablissement, et des tests réguliers documentés. La directive NIS2 étend par ailleurs des exigences de gestion des risques cyber, dont la continuité, à de nombreuses entités d'autres secteurs ; son application en France dépend de la transposition nationale et des textes d'application, dont l'état est à vérifier auprès d'un conseil spécialisé ou des autorités compétentes. Suivre ces exigences devient vite fastidieux, et des outils de pilotage de la conformité comme Nimonik aident à rattacher chaque obligation aux preuves correspondantes, dont les rapports de test du PCI.

Tester et faire vivre le plan de continuité informatique dans la durée

Un plan jamais testé est une hypothèse. Les tests se pratiquent à plusieurs niveaux de profondeur, à combiner au fil de l'année :

1. La revue documentaire : vérifier que contacts, versions, schémas et procédures correspondent à la réalité du moment.
2. L'exercice sur table : réunir la cellule de crise autour d'un scénario déroulé pas à pas, sans toucher aux systèmes, pour éprouver la prise de décision.
3. Le test technique partiel : restaurer une application ou une base sur un environnement isolé et chronométrer l'opération.
4. La bascule réelle : basculer la production vers le site de secours, puis revenir, sur un créneau planifié.

Une fréquence annuelle constitue un minimum pour les services critiques, et tout changement majeur (migration, nouveau prestataire, fusion) doit déclencher une mise à jour. La supervision joue ici un rôle discret mais décisif : détecter tôt une dégradation laisse le temps d'activer le plan avant la panne franche. Notre dossier Piloter son entreprise à 360° grâce aux solutions cloud de supervision détaille les approches disponibles pour centraliser ces alertes. Côté exécution, un outil de Gestion intervention bien paramétré permet de tracer les actions menées pendant la crise, d'assigner les tâches de reprise et de conserver un historique exploitable pour le retour d'expérience.

Les erreurs qui sabotent un plan de continuité informatique

Les audits de PCI font remonter des défauts récurrents, souvent simples à corriger une fois identifiés :

• Un plan rédigé par la seule DSI. Sans arbitrage métier, les priorités reflètent la vision technique et non la réalité du chiffre d'affaires. Associer les directions dès le BIA évite ce biais.
• Des sauvegardes jamais restaurées. Une sauvegarde qui n'a pas été relue est une promesse. Programmer des restaurations de contrôle régulières, avec un compte rendu.
• Une dépendance cachée à une seule personne. Mots de passe d'administration, connaissance d'un vieux logiciel : prévoir un coffre-fort numérique accessible en situation de crise et documenter les savoir-faire critiques.
• Un document inaccessible en cas de sinistre. Stocker le plan uniquement sur l'intranet le rend inutilisable au moment où il sert. Garder des copies hors ligne.
• Des prestataires absents du dispositif. Vérifier que les contrats d'infogérance, d'hébergement et de SaaS comportent des engagements de reprise cohérents avec les RTO fixés, et que ces partenaires participent aux exercices.
• Un plan figé. Le système d'information évolue chaque trimestre ; un PCI non révisé depuis deux ans décrit une infrastructure qui n'existe plus.

Le meilleur indicateur de maturité reste le retour d'expérience : après chaque test ou incident réel, consigner ce qui a fonctionné, ce qui a coincé, et transformer chaque écart en action datée avec un responsable.