Protocoles de reprise après sinistre (DRP) : réinstallation complète de 15 postes de travail

fiche rédigée le 02 octobre 2026infrastructure

Période 2022 → aujourd'hui

Expérience un site de production pharmaceutique (avril 2022 → décembre 2026)

Contexte

Je réalise des DRP, des « Disaster Recovery Protocols », depuis 2022. Le principe est brutal et volontaire : on détruit un poste de travail au niveau système, on le reconstruit entièrement, et on remet en place les données de l’ancien poste par restauration. (fait)

Le périmètre est le laboratoire d’analyses, côté contrôle qualité. Le parc compte quinze postes, chacun portant ses propres applications de métier et ses appareils raccordés. Derrière ces postes, il y a des machines et des robots d’analyse qui ont besoin d’un PC pour tourner, et c’est l’équipe qui les gère. Rien n’est standardisé, et c’est précisément ce qui fait l’intérêt de l’exercice. (fait)

L’enjeu est direct : une interruption de l’analyse retarde la libération des lots produits. (fait)

Objectif

Le protocole poursuit deux buts. Le premier est business : démontrer que l’équipe sait réinstaller un poste de bout en bout et rester autonome face à un sinistre. Le second est une mesure : établir combien de temps il faut réellement pour remettre un poste en service, et le traduire en RTO. (fait)

Origine

La campagne de 2022 m’a été confiée. Les DRP prévus cette année-là n’avaient pas encore été faits, et je les ai réalisés avec les responsables des équipements du laboratoire. (fait)

Le système réinstallé est un Windows dédié au laboratoire, un build spécifique aux postes applicatifs et aux machines d’analyse. (fait)

Le robot qu’on n’a pas pu migrer

Un robot d’analyse présent sur le site depuis une vingtaine d’années devait lui aussi passer son DRP. Il ne l’a pas eu. Ses contrôleurs moteurs ne disposent de pilotes que pour Windows 7 et Windows XP, et le passage à Windows 10 aurait rendu la machine inutilisable. Le poste reste donc sous Windows 7, où le logiciel de pilotage tourne en mode de compatibilité Windows XP. (fait)

Analyse de risques

Quatre risques ont été cotés, sur une échelle de 25. (fait)

La défaillance d’un poste d’analyse arrive en tête, à 20, parce qu’elle s’est déjà produite sur les équipements les plus utilisés. La perte de données GMP suit à 10 : la probabilité est faible, mais l’impact réglementaire est maximal. L’incompatibilité des équipements anciens vient à 9, et la défaillance du réseau du laboratoire à 8. (fait)

Rôle

J’intervenais seul sur le build du PC, c’est-à-dire la reconstruction du poste elle-même, et sur la mise en place du système de sauvegarde. Le reste se faisait en équipe : la finalisation, la remise en place des données de l’ancien poste, et la validation par l’utilisateur final. (fait)

Actions

L’exercice suit toujours le même chemin. Je détruis d’abord le PC au niveau système, sans filet. Je réinstalle ensuite Windows, puis les applications de métier une à une. Il reste enfin à raccrocher les appareils métiers, à vérifier que le poste rejoue son rôle, et à restaurer les données de l’ancien poste. (fait)

Les sauvegardes ont été mises en place avec DataProtector, en sauvegardes progressives, dans un environnement de production critique. Les scripts sont écrits en VBScript et en XML, et ils tournent dans les tâches planifiées Windows. Chaque script copie les répertoires utiles, exporte la clé de registre, extrait les groupes utilisateurs, compresse l’archive avec WinZip, puis purge les versions de plus de sept jours. (fait)

Défis

Le parc n’est pas homogène. Comme les applications diffèrent d’un poste à l’autre, il n’existe pas d’image unique à redéployer : chaque poste a sa propre procédure de réinstallation. (fait)

À cela s’ajoute une difficulté de disparité : certains postes sont nettement plus compliqués que d’autres à remettre en service. Les équipements d’analyse ont parfois des spécifications particulières, ce qui a demandé une documentation complète et une procédure dédiée par équipement. (fait)

Résultats / Impact

Sans protocole, une panne de poste d’analyse coûte de quatre à huit heures d’arrêt. Une fois la documentation et le protocole de suivi en place, le même poste repart en deux à quatre heures, et c’est un résultat relevé. Les deux chiffres portent sur le poste, pas sur une moyenne de parc. (fait)

L’exercice démontre la capacité à réinstaller un poste, et par là l’autonomie de l’équipe côté business. (fait)

La fréquence est faible, un DRP tous les deux ans, ce qui rend chaque exercice d’autant plus utile. Le protocole ne sert pas qu’à l’exercice : quand un incident touche un poste en production, la même procédure s’applique, en réel. (fait)

Les procédures et les matrices de validation, étape par étape, facilitent les audits réglementaires. (fait)

L’impact chiffré agrégé, nombre d’incidents ou disponibilité du parc, reste (non mesuré, assumé). (fait)

Apprentissages

Sur un parc hétérogène, le RTO ne se mesure pas au niveau du parc mais poste par poste : la moyenne masque les cas difficiles. (déduit)

Un exercice de reprise a deux publics. La technique veut savoir si ça redémarre, le business veut savoir en combien de temps. (déduit)

Une sauvegarde ne vaut que par la restauration qui va avec : c’est la procédure de remise en service qui donne son sens au script. (déduit)

Un poste peut être irremplaçable pour une raison matérielle. Ici, ce sont les pilotes des contrôleurs moteurs qui tiennent la machine en vie, pas le système d’exploitation. (déduit)

Preuves

Les livrables existent, mais côté entreprise : documentation de qualification, procédures de reprise, scripts de sauvegarde et relevés d’exercice. Ils ne sont pas versés ici et restent (preuves confidentielles, non versées). (fait)

Sources

Propos verbatim (2026-10-02).

« Ensuite j’effectue des DRP, donc ce que l’on appelle des Disaster Recovery Protocols Le but de ce protocole est de détruire un PC entièrement au niveau système, de réinstaller le Windows, réinstaller les applications et le refaire fonctionner avec les appareils métiers qui sont à côté. Et ce qui est installé dessus, c’est des applications de métier. Le but, c’est de démontrer d’un point de vue business que nous sommes capables de réinstaller et donc d’être autonomes. Et en plus de ça, ça démontre combien de temps on peut répondre à un incident avec le temps de RTO et tout ce qui va bien dans le détail de ce truc-là. »

« 15 postes applications differentes / robots danalyses

C’est ce qui est mesuré, je pense qu’on peut parler de 4 à 6 heures ou 6 à 8 heures pour remettre en ordre un post. »

« Yes, ça dépend du type de poste, il y a des postes qui sont bien plus compliqués que d’autres. On fait le DRP une fois tous les deux ans. »

« Oui, tu peux créer la fiche. Depuis 2022 »

Précisions (2026-10-07) :

« Même chantier, c’est une suite logique, en gros on pète on refait le poste et on remet les données avec la restauration sur le nouveau poste »

« labo c’est laboratoire d’analyses, contrôle qualité »

« 4 à 8 heures sans protocole, avec protocole maintenant on est sur 2 à 4 heures »

« c’est un exercice et aussi un incident lié à la produciton, tous les 2 ans on fait l’exercice mais il peut arriver d’avoir des incidents et de faire ce même “exercice” mais en réel »

Précisions tirées du rapport d’alternance licence ASR, sur la période 2022-2023 :

« Cette tâche de DRP pour l’année 2022 m’a donc été confiée, j’ai donc réalisé, à l’aide des responsables équipements du laboratoire, tous les DRP qui étaient prévus pour 2022, et qui n’avaient pas encore été complétés. »

« Un Robot d’analyse présent depuis une vingtaine d’années sur site avait aussi pour but de subir un DRP. Cependant, il nous a été impossible de réaliser celui-ci en effectuant un upgrade du PC windows 7 vers un PC windows 10. En effet, les contrôleurs utilisés pour piloter les moteurs du robot fonctionnant avec des drivers développés spécifiquement pour Windows 7 et Windows XP. »