Rédiger un plan de continuité prend quelques semaines. Le rendre actionnable le jour où tout s'arrête, c'est un autre métier. Notre méthode produit un dispositif vivant, daté, rattaché à votre parc réel — et opposable devant un auditeur, un assureur ou un donneur d'ordre.
Un plan de continuité qui dort dans un classeur partagé donne un sentiment de sécurité sans en produire les effets. Le jour de l'incident, trois choses manquent presque toujours : on ne sait pas qui décide, on ne sait pas dans quel ordre redémarrer, et on découvre que les sauvegardes ne couvraient pas ce qu'on croyait.
La difficulté n'est pas d'écrire le document. Elle est de le maintenir en cohérence avec un système d'information qui change chaque mois, et de prouver qu'il fonctionne avant d'en avoir besoin.
Un plan non éprouvé est une hypothèse, pas un dispositif.
Les serveurs et applications cités n'existent plus, ou ont changé de rôle.
« Tout le monde » est responsable, donc personne ne décide.
Chaque étape produit un livrable daté et vérifiable. Aucune ne repose sur une affirmation qu'on ne peut pas contrôler.
Nous identifions les processus métier qui ne peuvent pas s'arrêter, puis nous remontons vers les applications, serveurs, liens et prestataires dont ils dépendent réellement. Chaque actif reçoit un niveau de criticité, une durée d'interruption acceptable (RTO) et une perte de données tolérable (RPO).
Le point de départ est votre parc tel qu'il est, pas tel qu'il a été documenté il y a trois ans.
Qui déclenche le plan, qui pilote, qui parle aux clients, qui appelle l'assureur. Des personnes nommées, avec suppléants, coordonnées personnelles et canal de repli si la messagerie d'entreprise est indisponible — ce qui est précisément le cas lors d'un rançongiciel.
Nous incluons également les contacts externes utiles : hébergeur, opérateur, assurance cyber, autorités.
Pour chaque scénario retenu — perte du site, indisponibilité applicative, compromission, défaillance d'un prestataire — une procédure ordonnée, écrite pour être suivie sous pression par quelqu'un qui n'en est pas l'auteur.
L'ordre de redémarrage est établi à partir de la cartographie de l'étape 01, pas à l'intuition.
C'est l'étape qui distingue un dispositif d'un document. Chaque test est planifié, exécuté, daté, et son résultat consigné — y compris les échecs, qui sont les plus instructifs. Restauration réelle, bascule, exercice sur table de la cellule de crise.
Le registre devient la pièce que vous présentez quand on vous demande de prouver que votre plan fonctionne.
Chaque incident réel est consigné : chronologie, impact, décisions prises, durée effective de reprise. On compare ensuite le constaté à l'objectif, et on corrige la cartographie et les procédures en conséquence.
C'est ce qui empêche le plan de vieillir. Un PCA qui n'apprend pas de ses incidents redevient un document mort en douze mois.
À l'issue de la démarche, vous disposez d'un dossier complet exportable en PDF, structuré pour être lu par un tiers : auditeur, assureur, commissaire aux comptes, donneur d'ordre dans un appel d'offres.
Demander un exemple de sommaireAvec criticité, RTO et RPO par processus.
Rôles, suppléants, contacts internes et externes.
Ordonnées, avec modes dégradés.
Historique daté, écarts et actions correctives.
Chronologies et retours d'expérience.
Le dossier complet, à date, prêt à transmettre.
Nous avons conçu et nous maintenons notre propre interface de gestion, parce qu'aucun tableur ne survit à trois ans de mises à jour. Vous disposez d'un tableau de bord, d'une traçabilité complète et d'un pilotage en continu de votre résilience.
Les actifs critiques pointent vers les équipements et contrats réellement inventoriés, pas vers une liste recopiée.
Tests et incidents saisis au même endroit que le plan, donc jamais désynchronisés de lui.
Le dossier complet, horodaté, généré à la demande pour un audit ou un appel d'offres.
Chaque filiale ou site conserve son périmètre, avec une vision consolidée au niveau groupe.
La démarche est construite pour bâtir un PCA, un PRA et un PCI sur mesure, adaptés à la réalité opérationnelle de chaque structure, tout en respectant les exigences réglementaires applicables — au premier rang desquelles la norme ISO 22301 pour la continuité d'activité et le RGPD pour la disponibilité et l'intégrité des données personnelles.
Sur le volet identitaire et technique, l'articulation avec votre environnement Microsoft 365 et vos sauvegardes est traitée conjointement avec les équipes d'exploitation SPHERIS.
Continuité d'activité
Disponibilité & intégrité
Bonnes pratiques
Métier & informatique
La démarche de continuité est portée par SF Soli, entité juridiquement distincte de SPHERIS qui exploite les infrastructures. Ce n'est pas une subtilité administrative : c'est ce qui garantit qu'un audit de vos sauvegardes ou de votre dispositif de reprise ne soit pas conduit par l'équipe qui les a mis en place.
Vous conservez un interlocuteur unique et un support unique. L'indépendance, elle, est structurelle.
Comprendre notre organisation →Un premier échange suffit à situer votre niveau de couverture et à identifier ce qui vous expose le plus. Sans engagement, et sans jargon.