Le serveur est revenu, la page de connexion répond et la base a été restaurée. Pourtant, les équipes ne peuvent toujours pas traiter leurs dossiers : l’annuaire reste indisponible, certains documents manquent et les échanges avec l’ERP attendent une décision. Le rétablissement annoncé ne correspond pas à la reprise de l’activité. Ce blocage empêche de traiter les demandes qui continuent de s’accumuler et les responsables ignorent ce qu’ils peuvent rouvrir.
Après une refonte, le plan de reprise d’activité doit retrouver les opérations dont dépend réellement l’entreprise. Les nouvelles interfaces, les identités, les traitements différés et les règles de données changent parfois l’ordre de redémarrage. Un ancien document de secours peut donc décrire correctement les serveurs tout en laissant le nouveau parcours métier sans solution.
En pratique, la reprise doit couvrir un service métier dont les dépendances sont reçues et les limites connues. Ce guide propose de choisir ces services, construire une séquence de reprise et préparer un exercice avec des critères d’ouverture explicites. Un exemple fictif montre pourquoi une application accessible peut encore devoir rester fermée à certaines opérations.
Dawap intègre ces arbitrages à la refonte d’applications métier sur mesure, avec la DSI, les responsables opérationnels et l’exploitant. Le PRA se construit à partir du fonctionnement livré dans votre SI, que l’application soit hébergée dans un cloud, sur un serveur ou dans votre infrastructure interne.
Pour qui préparer un PRA après une refonte de logiciel ?
La démarche concerne une application dont l’interruption empêche de recevoir une commande, instruire un dossier, produire un document, planifier une intervention ou transmettre une opération à un autre système. Le besoin augmente lorsque plusieurs équipes ou prestataires détiennent chacun une partie des moyens nécessaires à sa reprise.
Une restauration remet des composants dans un état utilisable. Le PRA organise leur remise en service après une interruption majeure, avec des responsables et une séquence de validation. La continuité d’activité couvre aussi la façon de poursuivre les activités essentielles pendant cette interruption, par des moyens dégradés prévus et autorisés.
Une erreur locale corrigible par la procédure habituelle ne demande pas toujours d’activer tout le dispositif. Précisez les critères de déclenchement : périmètre touché, durée prévisible, absence de solution normale ou impact critique. L’organisation doit savoir qui peut décider ce passage et comment joindre cette personne lorsque l’outil habituel ne fonctionne plus.
La préparation peut rester proportionnée. Pour un petit logiciel, une séquence courte, des accès disponibles et un exercice ciblé peuvent apporter davantage qu’un classeur détaillé jamais utilisé. Pour un service critique, les scénarios, moyens de secours et responsabilités demandent une préparation plus large, reliée aux dispositifs existants du client.
Partir des opérations à reprendre et des conséquences de leur arrêt
Décrire un résultat observable par les métiers
Écrivez ce que l’utilisateur doit pouvoir réaliser : consulter les dossiers en cours, enregistrer une demande, approuver un devis ou retrouver un document opposable. Précisez les profils concernés et la preuve du résultat. « Application démarrée » décrit un état technique ; « demande enregistrée et retrouvée par son gestionnaire » décrit un service à recevoir.
Classez ensuite les opérations par conséquence de l’attente. Certaines perdent leur utilité après une échéance ; d’autres peuvent patienter dans une file contrôlée. Les métiers doivent indiquer ce qui ne peut pas être ressaisi, ce qui peut être différé et ce qui nécessite une information particulière des utilisateurs ou partenaires.
Choisir un périmètre dégradé réellement exploitable
La consultation seule peut aider le support sans permettre les mises à jour. La saisie locale peut être utile si les transmissions restent suspendues et si la capacité de rapprochement ultérieur est prévue. Chaque mode dégradé demande des droits, une communication et une règle pour revenir au fonctionnement normal.
Un export préparé avant l’incident peut parfois soutenir une activité limitée, à condition que sa fraîcheur, son accès et ses usages soient acceptés. Il ne faut pas improviser une copie de données sensibles vers un poste personnel pour contourner l’interruption. Le dispositif dégradé appartient au périmètre à cadrer et à recevoir.
Fixer RTO et RPO avec un point de départ et un service de sortie
Le RTO désigne l’objectif de durée de rétablissement ; le RPO désigne l’objectif de perte de données exprimé dans le temps. La présentation AWS des objectifs de reprise explique leur différence. Ces objectifs doivent être définis pour les services concernés, puis confrontés aux capacités et exercices du projet.
Pour mesurer une reprise, convenez du début de la chronologie et du résultat qui en marque la fin. Conservez l’heure de l’interruption connue, de sa détection, de la décision, du rétablissement technique et de l’acceptation métier. Une durée calculée uniquement à partir du démarrage du script masque l’attente des accès ou des intervenants.
| Service | Objectif proposé pour l’atelier | Question à résoudre |
|---|---|---|
| Consulter les interventions ouvertes | Reprise visée en quatre heures ; données âgées de trente minutes au plus. | L’annuaire et les pièces nécessaires peuvent-ils suivre ces objectifs ? |
| Enregistrer une demande urgente | Mode dégradé autorisé avant la reprise complète. | Qui contrôle les doublons lors du rapprochement ultérieur ? |
| Transmettre les écritures à l’ERP | Ouverture différée après rapprochement des accusés. | Comment distinguer une opération déjà reçue d’une opération à rejouer ? |
Si une dépendance ne peut pas respecter le besoin, alors le projet doit modifier le dispositif, négocier un fonctionnement dégradé ou revoir l’objectif avec le métier. Un chiffre inscrit dans le cahier des charges ne crée ni capacité de restauration ni disponibilité du prestataire concerné.
Construire l’ordre de reprise à partir des dépendances du SI
Retrouver les moyens nécessaires avant de démarrer l’application
La carte comprend les identités, réseaux, certificats, secrets, résolution de noms, stockage, base, files, documents et systèmes distants. Pour chaque élément, indiquez où il se trouve, qui peut le rétablir et comment vérifier sa disponibilité. Ajoutez les outils utilisés pour déployer et consulter les consignes : ils peuvent eux-mêmes dépendre du SI indisponible.
Une sauvegarde peut être présente dans un stockage auquel personne ne peut accéder sans l’annuaire en panne. De même, un registre d’images ou un coffre de secrets peut manquer sur le site de secours. Ces dépendances circulaires doivent être résolues avant l’incident, dans le cadre d’accès de secours autorisés et contrôlés par la DSI.
Recevoir les dépendances par parcours
Pour la consultation d’un dossier, le chemin peut comprendre authentification, autorisation, base et document. Pour sa transmission, ajoutez file, identité technique, API et accusé de réception. Les branches ne reprennent pas nécessairement ensemble. Conservez l’état de chacune pour éviter qu’un parcours incomplet déclenche une action non maîtrisée.
La checklist de livraison du logiciel dans le SI client fournit un inventaire initial des prérequis. Le PRA doit aller plus loin : il examine leur disponibilité lorsque l’infrastructure normale, un interlocuteur ou un service transverse manque.
Choisir les scénarios et les moyens de secours adaptés au risque
Une panne de machine, la perte d’un site, une corruption de données et une compromission des identités demandent des réponses différentes. Décrivez la frontière du scénario : ce qui reste accessible, ce qui est supposé perdu et ce qui doit être considéré comme douteux. Cette frontière détermine les moyens réellement utilisables pour reprendre.
Les stratégies cloud peuvent aller de la reconstruction après sauvegarde à des ressources de secours partiellement ou largement préparées. Le guide AWS des options de reprise présente plusieurs approches. Leur choix dépend des objectifs, des coûts et des dépendances ; aucune architecture nommée ne vaut preuve du délai obtenu pour votre application.
Paradoxalement, une réplication plus rapide peut propager plus vite une suppression ou une donnée corrompue. Vérifiez donc quels états historiques restent récupérables et selon quelles protections. Le guide de sauvegarde et restauration après refonte détaille les composants et les contrôles nécessaires avant de recevoir un état applicatif.
En cas de compromission suspectée, la remise en ligne doit suivre la conduite de réponse à incident du client. Une cible disponible peut rester impropre à la reprise si les identités ou les composants réinstallés sont douteux. Les décisions de confinement, d’investigation et de réouverture nécessitent les responsables compétents et un environnement de confiance défini.
Écrire une procédure qui autorise chaque ouverture séparément
Préparer une entrée, une sortie et une condition d’arrêt par étape
Une étape exploitable précise ses prérequis, son intervenant, l’action autorisée et la preuve attendue. Si cette preuve manque, la procédure indique l’état dans lequel rester et la personne à solliciter. « Relancer le service » ne dit pas si les envois doivent partir, si les utilisateurs peuvent écrire ou si le système reste en observation.
Identifiez aussi le lieu des consignes et le moyen de les consulter pendant le scénario. Les références de version, contacts et procédures utiles doivent rester accessibles aux intervenants autorisés sans supposer le retour de l’application concernée. Leur conservation et leurs droits doivent respecter la sensibilité des informations qu’elles contiennent.
Vérifier les actions qui peuvent se poursuivre sur l’ancienne cible
Avant d’activer les écritures du secours, contrôlez ce que l’ancienne cible peut encore exécuter : tâches planifiées, workers, appels partenaires ou sessions déjà ouvertes. Le risque est de laisser deux systèmes produire des décisions concurrentes. La méthode pour empêcher cette concurrence dépend de l’architecture et doit être exercée.
Si l’isolement de la cible précédente n’est pas démontré, alors le décideur doit connaître ce risque avant toute ouverture. Une simple modification d’adresse publique ne prouve pas l’arrêt de tous ses traitements. Le dossier garde les contrôles réalisés et les composants dont l’état reste inconnu.
Matrice de décision fictive : rouvrir les interventions sans doubler les transmissions
L’exemple suivant est un scénario préparé pour un exercice sur table, sans exécution d’une reprise réelle. Un outil inventé conserve des demandes, des pièces jointes et une file d’écritures à transmettre à l’ERP. Après une panne du site principal, la DSI prévoit une cible de secours et le métier souhaite consulter les interventions prioritaires.
| Étape et entrée | Sortie à recevoir | Arrêt ou réserve |
|---|---|---|
| Identifier le sinistre et l’état de la cible normale. | Décision attribuée ; actions concurrentes contenues selon la procédure. | Ne pas ouvrir les écritures si l’ancienne cible peut encore agir. |
| Retrouver version, données, documents et accès autorisés. | Un dossier témoin s’ouvre avec ses droits et ses pièces attendues. | Maintenir fermé le parcours dont une dépendance reste absente. |
| Comparer la file aux accusés connus du destinataire. | Opérations déjà reçues séparées des opérations à examiner. | Garder les transmissions suspendues si leur statut reste ambigu. |
| Faire accepter les usages par le responsable métier. | Périmètre ouvert, limites et surveillance consignés. | Conserver un mode dégradé explicite pour les fonctions non reçues. |
En entrée de cette étape, une opération apparaît dans la file locale alors que l’ERP la connaît déjà ; cette dépendance distante doit être interrogée par son responsable. La rejouer sans vérification peut créer un doublon selon le comportement du destinataire. La journalisation doit permettre de rapprocher les références disponibles ; les modalités d’identification et de reprise sont à convenir avec le propriétaire de l’interface.
Le seuil d’ouverture retenu pour cet exemple autorise en sortie la consultation des dossiers contrôlés et maintient la file de transmissions arrêtée. Le repli consiste à revenir au mode dégradé convenu si un document critique ou un droit manque. Le rapport ne dira donc pas « tout est repris » : il décrira les opérations utilisables et les réserves restantes.
Télécharger le plan d’exercice PRA au format CSV pour adapter cette séquence. Le fichier distingue les hypothèses fictives, les preuves à produire et les décisions à renseigner ; ses lignes ne certifient aucune reprise exécutée.
Attribuer les décisions, les communications et les relais externes
Nommer les pouvoirs de décision avant l’incident
Le responsable de reprise coordonne les actions ; les exploitants rétablissent leurs composants ; les propriétaires d’interfaces confirment leurs possibilités ; les métiers acceptent les usages rouverts. Une même personne peut cumuler certains rôles dans une petite organisation, mais les décisions doivent rester identifiables et disposer d’un relais prévu.
Les contacts doivent couvrir les horaires et scénarios convenus. Un prestataire peut maintenir son infrastructure sans assurer le redémarrage des traitements applicatifs. Vérifiez les frontières contractuelles et les informations qu’il peut réellement fournir. Le choix d’un hébergement après refonte doit donc intégrer ces responsabilités de reprise.
Informer sur le service disponible et la prochaine décision
Le message aux utilisateurs précise les opérations permises, celles à différer et le canal pour signaler un problème. Le point suivant peut annoncer une décision attendue plutôt qu’une heure de résolution non étayée. Les équipes doivent aussi savoir où consigner les demandes reçues pendant le mode dégradé.
L’ANSSI relie préparation, entraînement, coordination métier et réponse technique dans la gestion d’une crise cyber. Le dispositif de reprise applicative doit s’articuler avec celui du client, notamment lorsque les moyens de communication habituels sont indisponibles.
Exercer les dépendances et conserver les résultats réellement observés
Commencer par une simulation, puis vérifier les moyens techniques
L’exercice sur table fait apparaître les contacts manquants, décisions implicites et dépendances circulaires. Il ne mesure pas une restauration de données ni un délai de rétablissement technique. Un exercice sur une cible isolée permet ensuite de confronter les procédures aux accès, volumes et composants réellement disponibles.
Définissez le périmètre autorisé, les protections et les critères d’arrêt avant l’essai. La séparation sandbox, recette et production aide à contenir les effets des essais. Une répétition de PRA ne doit pas envoyer involontairement des commandes, des courriels ou des écritures vers les partenaires réels.
Mesurer toute la chaîne de décision
Le relevé conserve les heures, attentes, actions, résultats et réserves. Distinguez les durées observées des durées estimées ou simplement discutées. Si le périmètre était réduit, indiquez les volumes, populations ou interfaces exclus : un essai partiel ne démontre pas la capacité de reprise complète.
À la fin, attribuez chaque correction à un responsable et un critère de vérification. Un accès absent doit être préparé puis essayé ; une interface ambiguë doit être rapprochée avec son propriétaire. Le prochain exercice reprend ces points pour vérifier que la capacité a réellement progressé.
Préparer le retour à la cible normale et la mise à jour du PRA
Le secours devient temporairement une source d’activité : des utilisateurs peuvent y créer des dossiers et des systèmes distants peuvent recevoir ses opérations. Le retour exige donc un nouveau rapprochement. Déterminez où se trouve l’état de référence, comment les écritures seront suspendues et quelle cible pourra reprendre sans conflit.
Conservez les données et preuves nécessaires avant de retirer les moyens temporaires, selon les règles de conservation du client. Révoquez les accès devenus inutiles par le circuit prévu. Un PRA reste incomplet si personne n’a reçu la procédure qui permet de quitter le secours en conservant les opérations réalisées.
Une nouvelle interface, une migration de base, un changement d’annuaire ou d’hébergeur peut invalider une étape. Reliez ces changements à une revue du plan et à des essais ciblés. Le cahier des charges de refonte métiers et DSI doit prévoir la livraison et l’entretien de ces éléments.
Conserver une chaîne de reconstruction utilisable dans le scénario
Le code frontend et le backend doivent retrouver les versions compatibles avec les données reprises. Préparez les artefacts, leurs références et le pipeline de déploiement qui peut les installer sur la cible prévue. Les tests de démarrage puis les tests du parcours métier permettent de recevoir cette reconstruction ; une compilation réussie ne valide pas les droits ni les échanges distants.
L’observabilité doit également suivre la cible de secours : destination des journaux, accès des intervenants et contrôles sur les traitements. Une alerte qui surveille seulement l’ancien serveur laisse la reprise sans signal utile. Faites exercer la remontée d’un défaut connu et vérifier son arrivée chez le responsable désigné avant de déclarer la surveillance opérationnelle.
Projets liés : les dépendances documentaires et partenaires de Velizen
Un dossier métier qui traverse plusieurs espaces et systèmes
Le projet Velizen, application CEE avec API et back-offices présente des espaces par rôle, des documents et des échanges avec Cyclable, des briques ERP Cegid et le partenaire CertiNergy. Le dossier doit conserver ses pièces et ses étapes entre ces intervenants.
Cette référence illustre les dépendances à inventorier avant de définir une reprise. Elle ne publie pas de délai de rétablissement mesuré ni de résultat d’exercice PRA. L’objectif et les moyens de secours restent à construire pour chaque service avec ses responsables, en distinguant ce que l’application maîtrise de ce qui dépend d’un partenaire.
Guides liés pour préparer puis recevoir la capacité de reprise
Le dossier sur la restauration applicative approfondit la cohérence entre base, documents et effets externes. Il aide à préparer l’état à recevoir avant l’ouverture d’un service, tandis que le PRA organise les décisions et l’ordre de reprise autour de cet état.
Pour inscrire les responsabilités et les essais dans la commande initiale, utilisez le modèle de cadrage métiers et DSI. La disponibilité des moyens de secours et la participation des propriétaires d’interfaces doivent être prévues dans les livrables et le planning.
Erreurs fréquentes : annoncer la reprise avant le retour du métier
- Confondre réponse HTTP et service disponible. Recevoir un parcours avec ses droits, ses données et ses dépendances avant de l’annoncer utilisable.
- Rejouer toutes les opérations en attente. Examiner leurs statuts distants et les possibilités de doublon avant d’autoriser la reprise.
- Prévoir uniquement la perte d’une machine. Décrire aussi les scénarios qui touchent les identités, les données ou les moyens de pilotage utiles.
- Mesurer seulement le temps de restauration. Garder les attentes, décisions et contrôles métier dans la chronologie.
- Oublier le retour du secours. Préparer les rapprochements et l’autorité de chaque cible avant de rouvrir les écritures.
Le coût caché d’un plan trop ambitieux vient des moyens qu’il faut maintenir prêts et exercer. Une capacité de secours annoncée mais jamais entretenue consomme un budget sans donner de certitude. Mieux vaut recevoir un périmètre prioritaire réaliste et rendre visibles les limites qui restent à financer.
Plan d’action : recevoir une première capacité de reprise avec la DSI
- Choisir une opération prioritaire et décrire les conséquences de son interruption.
- Fixer ses objectifs, son mode dégradé et ses critères d’ouverture avec le métier.
- Cartographier ses dépendances, leurs responsables et les moyens accessibles dans le scénario retenu.
- Écrire la séquence, les preuves attendues et les conditions de maintien à l’arrêt.
- Préparer un exercice autorisé puis conserver les résultats et les écarts observés.
- Corriger les blocages, recevoir le retour à la normale et organiser les revues après changement.
Commencez par le chemin qui rend un premier service utile plutôt que par une bascule générale non maîtrisée. L’arbitrage doit rester explicite : opérations reçues, opérations différées, moyens nécessaires et responsables des risques encore ouverts.
Conclusion : reprendre une activité dont les conditions sont connues
Le PRA d’une application refondue relie les priorités métier à une capacité de reprise observable. Il identifie les dépendances, organise leur retour et donne à chaque décideur une preuve du périmètre qui peut être ouvert.
Les objectifs de délai et de perte de données demandent des moyens cohérents. Leur réception passe par des exercices dont les limites sont conservées, avec une chronologie complète et des corrections effectivement reprises dans les procédures.
La reprise peut être progressive : consultation, opérations limitées, puis échanges et traitements reçus. Cette progression doit préserver l’autorité des données et préparer le retour à la cible normale, sans laisser les utilisateurs interpréter seuls les réserves.
Avec son accompagnement de refonte de logiciel intégré au SI, Dawap prépare l’application et les conditions de son exploitation avec vos équipes. La continuité attendue devient un sujet de cadrage, de livraison et de vérification, relié aux usages réellement servis.
