PSI plan de secours informatique pour protéger la continuité de l’entreprise

Un PSI plan de secours informatique sert à préparer l’entreprise à une interruption majeure de son système d’information. Incendie, cyberattaque, panne générale, dégâts des eaux, vol d’équipements ou indisponibilité d’un site, les scénarios capables de bloquer l’activité sont nombreux. Quand les applications critiques, les données ou les réseaux tombent, la reprise ne peut pas reposer sur l’improvisation.

Le PSI regroupe des stratégies, ressources, procédures et responsabilités pour restaurer le SI dans un temps défini, avec un niveau de service acceptable. Il s’inscrit dans une logique plus large de continuité d’activité et de sécurité des systèmes d’information. Bien conçu, il réduit les pertes financières, protège l’image de marque et permet de reprendre les services essentiels avec méthode.

Qu’est-ce qu’un PSI plan de secours informatique

Le plan de secours informatique, souvent abrégé PSI, est un dispositif formalisé qui organise la réponse de l’entreprise lorsqu’un sinistre affecte son système d’information. Selon les sources, il peut aussi être rapproché du PCI, pour plan de continuité informatique. Sa finalité reste la même, garantir la continuité informatique sans perte de service, ou avec une dégradation limitée et acceptable.

Concrètement, un PSI décrit :

• les services et applications critiques à maintenir ou à redémarrer en priorité,
• les moyens techniques de secours,
• les procédures de bascule, de restauration et de retour à la normale,
• les rôles de chaque équipe en situation de crise,
• les conditions de déclenchement du plan,
• les modalités de test, de maintenance et d’amélioration continue.

Le PSI est donc un maillon central de la politique de sécurité informatique. Il ne se limite pas à la sauvegarde des données. Il couvre aussi l’infrastructure, les réseaux, la téléphonie, les accès, le reroutage, la logistique et la coordination humaine nécessaire à une reprise efficace.

Quelle place occupe le PSI dans un PCA

Le PSI ne vit pas seul. Il fait partie du PCA, le plan de continuité d’activité, qui couvre un périmètre bien plus large que l’informatique. Le PCA s’intéresse à la capacité globale de l’organisation à continuer à fonctionner malgré une crise. Il prend en compte le repli des utilisateurs, la communication de crise, l’organisation de gestion de crise, les risques sanitaires et l’ensemble des dépendances métiers.

Le PSI traite un volet plus ciblé, la continuité et la reprise du système d’information. Il détaille les ressources, les procédures et les priorités nécessaires pour remettre en route les composants numériques indispensables à l’activité.

Quelle différence entre PSI et PCA

La différence principale tient au niveau de couverture. Le PCA englobe la continuité de l’entreprise dans son ensemble. Le PSI se concentre sur le SI, ses applications, ses données et ses infrastructures.

Le PCA répond à des questions comme :

• comment faire travailler les équipes si les locaux sont indisponibles,
• comment informer les clients, partenaires et autorités,
• quelles activités métiers doivent être maintenues en priorité,
• quelle gouvernance de crise mettre en place.

Le PSI répond à d’autres sujets :

• comment restaurer les serveurs et les applications critiques,
• comment récupérer les données selon les objectifs fixés,
• comment rétablir les accès réseau et la téléphonie,
• comment faire fonctionner un site ou un environnement de secours.

Une erreur fréquente consiste à traiter le PCA sans intégrer réellement la dimension informatique. Cette déconnexion crée des plans métiers irréalistes, incapables de fonctionner lorsque le SI reste indisponible.

Quelle différence entre PSI et PRA

Le PRA, plan de reprise d’activité, vise surtout la reprise après sinistre. Il décrit la manière de redémarrer un système d’information minimal, souvent sur un autre site, après un événement majeur. Le PSI peut intégrer cette logique de reprise, mais son périmètre est souvent plus large lorsqu’il inclut les dispositifs de secours, la documentation, la gouvernance, les tests et la maintenance du plan.

Dans la pratique, les termes PSI, PRA et PCI sont parfois employés de manière proche. Pour éviter les ambiguïtés, l’essentiel consiste à définir clairement le contenu du dispositif, son périmètre, ses déclencheurs et ses objectifs de reprise.

À quoi sert un PSI pour l’entreprise

Un PSI sert d’abord à reprendre l’activité le plus rapidement possible après un incident majeur. Il permet de limiter la désorganisation et d’éviter que chaque équipe improvise dans l’urgence. Il apporte aussi une méthode éprouvée pour restaurer la capacité à délivrer les produits et services clés.

Ses bénéfices sont concrets :

• réduction du temps d’arrêt,
• maîtrise des pertes de chiffre d’affaires,
• protection de l’intégrité, de la disponibilité et de la confidentialité des données,
• préservation de la satisfaction client,
• réduction du risque réputationnel,
• amélioration de la résilience face aux crises.

Cette approche répond aussi à des attentes de conformité et de gouvernance. Les entreprises structurent souvent leur démarche en cohérence avec leur politique SSI et avec des référentiels comme ISO 27001, ISO 27002 ou encore les pratiques historiques associées à BS25999. Dans certains secteurs, la pression réglementaire renforce encore le besoin de continuité, avec des sujets comme le RGPD, NIS2 ou DORA.

Quels sont les risques si l’entreprise n’a pas de PSI

Sans PSI, un sinistre informatique se transforme vite en crise globale. Les impacts dépassent largement la DSI. Les métiers se retrouvent sans outils, les délais clients ne sont plus tenus, la facturation s’arrête, la production ralentit et les équipes perdent un temps précieux à chercher des solutions de contournement.

Les risques les plus fréquents sont les suivants :

• pertes directes, comme la baisse de chiffre d’affaires ou les frais de restauration en urgence,
• pertes indirectes, comme l’atteinte à l’image de marque et la perte de clients,
• perte ou dégradation de données, avec parfois des conséquences juridiques ou contractuelles,
• désorganisation opérationnelle, faute de rôles, procédures et priorités claires,
• reprise trop lente, incompatible avec les exigences métiers.

Les retours d’expérience montrent aussi des problèmes récurrents, absence d’analyse des risques, documentation insuffisante, plans non testés, incohérence entre plans métiers et plans informatiques, faible implication de la direction générale. Ces lacunes expliquent pourquoi de nombreuses organisations disposent de documents, sans disposer d’une capacité de reprise réellement opérationnelle.

Quels incidents doivent déclencher un PSI

Le PSI doit définir précisément ses conditions de déclenchement. Cette étape évite les hésitations au moment critique. Le plan n’est pas réservé aux catastrophes spectaculaires. Il peut être activé dès qu’un incident menace durablement les services essentiels ou les données.

Les incidents couramment couverts sont :

• incendie,
• dégâts des eaux,
• cambriolage ou vols d’ordinateurs,
• panne générale ou panne majeure,
• cyberattaque,
• perte, vol ou dégradation des données,
• intempéries et sinistres climatiques,
• catastrophes naturelles,
• crise sanitaire,
• conflit social,
• attentat,
• défaillance d’un responsable clé de la sécurité ou de l’exploitation.

Le plus utile consiste à relier chaque scénario à un niveau de gravité, à un décideur habilité au déclenchement, et à un mode de fonctionnement précis. Le document doit indiquer qui décide, à partir de quels critères, et dans quelles conditions l’entreprise bascule vers les moyens de secours.

Quels sont les objectifs de reprise à fixer

Un PSI efficace repose sur des objectifs de reprise mesurables. Sans seuils chiffrés, les arbitrages techniques restent flous et les investissements peuvent être mal orientés. La question centrale n’est pas seulement de savoir s’il faut redémarrer, mais dans quel délai et avec quelle perte de données acceptable.

Les objectifs de reprise doivent être définis service par service, en croisant les besoins métiers, la criticité opérationnelle, les obligations contractuelles, les exigences réglementaires et les coûts de secours. Une application de paie, un ERP, un outil de relation client ou une plateforme e-commerce n’ont pas nécessairement le même niveau d’exigence.

DMIA, DIMA, RTO et RPO : quels indicateurs intégrer

Quatre indicateurs reviennent régulièrement dans un PSI :

• DMIA, durée maximale d’interruption admissible, soit la durée au-delà de laquelle l’activité subit un impact inacceptable,
• DIMA, délai d’indisponibilité maximal admissible, proche dans l’esprit de la tolérance métier à l’arrêt,
• RTO (Recovery Time Objective), délai cible de remise en service après l’incident,
• RPO (Recovery Point Objective), volume maximal de données que l’entreprise accepte de perdre, exprimé en durée.

Ces indicateurs servent à arbitrer les solutions techniques. Un RPO de 24 heures peut convenir pour certaines archives. Un RPO de quelques minutes impose des mécanismes bien plus exigeants, comme la réplication rapprochée ou la duplication de services.

Comment construire un PSI efficace pas à pas

La construction d’un PSI ne commence pas par l’achat d’une solution technique. Elle démarre par une phase amont structurée, souvent plus longue que prévu lorsque le SI est complexe ou que les volumes de données sont élevés. Une méthode solide repose sur le diagnostic, l’analyse des dépendances, le choix d’une cible réaliste et la formalisation de procédures utilisables en situation de stress.

Identifier les activités et services critiques

La première étape consiste à cartographier ce qui doit absolument continuer ou redémarrer rapidement. Cette analyse s’appuie sur les métiers, les processus, les applications, les flux, les données et les infrastructures associées.

Les éléments à inventorier incluent :

• les activités critiques de l’entreprise,
• les applications indispensables à ces activités,
• les bases de données associées,
• les dépendances techniques, réseaux, annuaires, téléphonie, accès distants,
• les prestataires externes et services cloud,
• les ressources humaines clés pour la reprise.

Cette logique rejoint les travaux souvent menés dans un BIA (bilan d’impact sur l’activité). D’ailleurs, plusieurs formations professionnelles récentes structurent la démarche autour de ces livrables. La formation PLB SPSI, annoncée avec une session garantie le 08/10/2026, propose par exemple la réalisation d’un BIA, d’un PCM informatique, d’un PCI et d’un PRI de bout en bout.

Analyser les risques et les scénarios de sinistre

Un PSI sérieux découle d’une analyse des risques. Cette étape permet de confronter les vulnérabilités réelles de l’entreprise aux scénarios de crise plausibles. Sans ce travail, les dispositifs de secours restent théoriques ou mal dimensionnés.

L’analyse peut inclure :

• une étude fonctionnelle,
• une étude de vulnérabilité,
• une analyse des menaces internes et externes,
• l’inventaire des dépendances critiques,
• la définition de scénarios de sinistre réalistes.

Les prestataires spécialisés accompagnent souvent cette phase, en aidant à auditer l’existant, mener des ateliers transversaux, sensibiliser la direction et confronter les attentes métiers aux capacités réelles du SI.

Définir les besoins de reprise et de secours

Une fois les priorités et les risques identifiés, l’entreprise peut définir sa cible de continuité. C’est à ce stade que se décident les niveaux de service attendus, les moyens de secours et les investissements associés.

Les arbitrages portent notamment sur :

• le niveau de disponibilité requis par application,
• le type de sauvegarde et la fréquence,
• la nécessité d’un site de secours,
• le besoin de duplication partielle ou totale,
• les solutions de reroutage réseau et téléphonique,
• le mode opératoire de retour à la normale.

Pour certaines organisations, un environnement de secours minimal suffit. D’autres, notamment dans des secteurs où l’interruption est difficilement acceptable, choisissent de doubler l’infrastructure pour transférer rapidement les utilisateurs vers un autre site identique. Le secteur bancaire illustre bien ce niveau d’exigence.

Rédiger les procédures de bascule et de restauration

La documentation opérationnelle doit rester claire, séquencée et exploitable pendant une crise. Un bon PSI décrit non seulement les principes, mais aussi les gestes à exécuter, l’ordre des actions, les contacts et les critères de validation.

Le document couvre généralement :

• la procédure de déclenchement,
• les rôles et responsabilités,
• les procédures de raccordement au réseau,
• les opérations de reroutage et de routage,
• les étapes de restauration des données,
• la remise en route des serveurs et applications,
• les moyens téléphoniques de secours,
• la logistique et les conditions de fonctionnement après déclenchement,
• les critères de retour à la normale,
• les engagements, priorités, aspects financiers et évolutions prévues.

La qualité documentaire reste un point faible récurrent dans les organisations. Un plan trop théorique ou trop volumineux devient inutilisable au moment critique.

Les moyens de secours à prévoir dans un PSI

Les moyens de secours doivent correspondre aux objectifs de reprise fixés. Il n’existe pas de modèle unique. Une PME avec un SI limité ne retiendra pas le même dispositif qu’un groupe multisite. Le bon niveau de secours est celui qui équilibre criticité métier, faisabilité technique et budget.

Les solutions de sauvegarde et de restauration

La sauvegarde reste un socle indispensable, mais elle doit être conçue selon les contraintes réelles de l’entreprise. Les stratégies peuvent combiner plusieurs formats :

• sauvegardes physiques,
• sauvegardes logiques,
• sauvegardes complètes,
• sauvegardes incrémentales,
• sauvegardes applicatives.

Le choix dépend des volumes de données, de la fréquence des mises à jour, des délais de restauration et du RPO visé. Un PSI peut aussi intégrer des mécanismes de duplication, de réplication ou de restauration automatisée pour accélérer la reprise.

Les sites de secours et environnements de repli

Selon le niveau d’exigence, la continuité peut reposer sur :

• un autre site de l’entreprise,
• un site distant dédié,
• un hébergement externe,
• un environnement de repli partiel pour les seules applications critiques.

Le choix dépend surtout du temps de reprise attendu. Plus le RTO est court, plus l’environnement de secours doit être prêt à l’emploi. Il faut aussi anticiper les modalités d’accès des équipes, les conditions réseau, les droits d’administration et la disponibilité des équipements.

Le secours des réseaux, de la téléphonie, des serveurs et des applications

Le PSI ne peut pas se limiter au stockage des données. Une reprise crédible suppose aussi de traiter l’écosystème complet :

• secours des liens réseaux,
• raccordement au réseau sur site de secours,
• routage et reroutage,
• moyens téléphoniques de secours,
• serveurs physiques et virtuels,
• annuaires, authentification et accès distants,
• applications métiers et middleware,
• postes critiques ou équipements spécialisés.

Les formations professionnelles récentes confirment cette approche. La formation Aston Institut, code P-PSI, proposée en 2025 sur 14 heures pour un prix public de 2 050 €, met justement l’accent sur les typologies de secours, le raccordement réseau, les moyens téléphoniques, le routage, les sauvegardes et les tests. Elle vise notamment les DSI, RSSI, responsables PCA, risques et organisation.

Qui doit rédiger un PSI

Le PSI doit être rédigé par une équipe transversale. La DSI ne peut pas le construire seule, car les priorités de reprise dépendent des métiers. À l’inverse, un document piloté uniquement côté métier oublie souvent les dépendances techniques et la réalité de l’exploitation.

Les contributeurs habituels sont :

• la direction générale, pour arbitrer les priorités et les budgets,
• la DSI, pour l’architecture, l’exploitation et les procédures techniques,
• le RSSI, pour l’angle sécurité et résilience,
• les responsables métiers, pour la criticité des activités,
• les équipes infrastructure, réseau, applicatif et support,
• les prestataires clés, lorsque certaines briques sont externalisées.

Dans les TPE et PME, le PSI est souvent initié et piloté par le dirigeant, car il connaît les activités vitales et les exigences de disponibilité du SI. Dans des structures plus grandes, la responsabilité est plus formalisée, avec un sponsor de direction, un responsable continuité et une gouvernance de crise.

Qui pilote un PSI en cas de crise

Au moment du sinistre, le pilotage doit être clair avant même le déclenchement. Le PSI s’articule généralement avec une organisation de crise comprenant :

• un comité de crise, chargé des décisions stratégiques,
• une cellule de coordination, chargée du suivi opérationnel,
• des équipes d’intervention, pour l’exécution technique,
• les services utilisateurs, pour la validation de la reprise et la priorisation métier.

Chaque rôle doit être documenté, avec des remplaçants identifiés. Une crise survient parfois quand la personne clé n’est pas joignable. C’est précisément pour cette raison que le plan doit intégrer la continuité humaine, pas seulement la continuité technique.

À quelle fréquence tester un PSI

Un PSI non testé reste une hypothèse. Les organisations les plus exposées planifient des exercices réguliers, du simple test documentaire jusqu’à la bascule technique complète. La fréquence dépend de la criticité du SI, des évolutions techniques et des exigences réglementaires ou contractuelles.

Un rythme réaliste comprend souvent :

• des revues documentaires plusieurs fois par an,
• des tests partiels après chaque changement majeur,
• un exercice de crise annuel,
• des tests de restauration réguliers sur les sauvegardes critiques.

Les formations spécialisées insistent fortement sur cette dimension. L’offre IB Cegos publiée le 19 mars 2025 rappelle que le plan de secours informatique constitue un élément essentiel de la gestion des risques informatiques et de la SSI. Les objectifs mis en avant portent sur la continuité des activités, la protection des données, la maîtrise des coûts et la préservation de l’image de marque. De son côté, la formation Ageris Consulting, intitulée « Elaborer un plan de secours informatique (PSI) », s’inscrit dans un catalogue plus large orienté cybersécurité, RGPD, NIS2, DORA et gestion de crise, ce qui confirme la place du PSI dans les enjeux actuels de résilience numérique.

Organiser la maintenance documentaire du PSI

La maintenance documentaire doit être traitée comme un processus permanent. Un PSI devient vite obsolète si l’entreprise change d’outils, de prestataires, de sites ou d’organisation sans mettre à jour le plan.

La maintenance doit couvrir :

• les contacts et astreintes,
• les inventaires d’applications et de serveurs,
• les dépendances techniques,
• les procédures de restauration,
• les accès et habilitations,
• les évolutions contractuelles avec les fournisseurs,
• les enseignements issus des tests et incidents réels.

Le bon réflexe consiste à intégrer le PSI dans un plan de progrès, avec des versions datées, des responsables identifiés et des points de révision programmés.

Combien de temps faut-il pour mettre en place un PSI

Le délai de mise en place dépend de la maturité de l’organisation, de la complexité du SI et du niveau d’exigence visé. Pour une petite structure avec peu d’applications critiques, un premier cadre peut être formalisé en quelques semaines. Pour une entreprise multisite avec des flux nombreux, des environnements hétérogènes et des contraintes fortes de disponibilité, le chantier s’étale souvent sur plusieurs mois.

Les étapes qui prennent le plus de temps sont généralement :

• la cartographie des activités et dépendances,
• l’analyse des risques et des impacts,
• les arbitrages sur les objectifs de reprise,
• la sélection des solutions de secours,
• la rédaction des procédures détaillées,
• les tests et ajustements.

Pour accélérer la démarche, certaines entreprises s’appuient sur des formations ou un accompagnement externe. Le marché propose des formats courts, souvent sur 2 jours, destinés à donner une méthode et une structure documentaire. C’est le cas de PLB ou d’Ageris. Ces formats ne remplacent pas le projet interne, mais ils aident à cadrer le travail et à aligner les acteurs.

Combien coûte un plan de secours informatique

Le coût d’un PSI varie énormément selon le périmètre retenu. Il faut distinguer le coût de conception et le coût des moyens de secours.

La phase de conception inclut l’analyse des risques, les ateliers métiers, la rédaction documentaire, les tests et la maintenance. À titre indicatif, les formations spécialisées citées sur le marché français se situent autour de 2 050 € pour 2 jours, comme chez PLB ou Aston Institut. Cela donne un ordre de grandeur pour la montée en compétence, mais pas pour la mise en œuvre complète dans une entreprise.

Le coût global dépend ensuite de plusieurs facteurs :

• nombre d’applications critiques,
• volumes de données,
• objectifs RTO et RPO,
• besoin ou non d’un site de secours,
• niveau d’automatisation de la bascule,
• fréquence des tests,
• dépendances à des prestataires externes.

Un arbitrage utile consiste à comparer le budget du PSI avec le coût d’un arrêt prolongé. Perte de chiffre d’affaires, baisse de productivité, pénalités, incident de sécurité, fuite de clients et impact réputationnel pèsent souvent bien plus lourd qu’un dispositif de continuité correctement dimensionné.

Un PSI efficace n’est pas un simple document de conformité. C’est un choix de gestion qui transforme la reprise informatique en capacité opérationnelle réelle. Les entreprises qui avancent le mieux sur ce sujet partent des besoins métiers, fixent des objectifs mesurables, testent régulièrement leurs scénarios et maintiennent leur plan au rythme des évolutions du SI. Ce niveau d’exigence fait la différence entre une interruption subie et une crise maîtrisée.