Comment préparer un plan de reprise informatique dans une PME ?
Un plan de reprise informatique pour PME doit préciser quels services redémarrer en premier, sous quel délai, avec quelle perte de données acceptable et qui pilote les opérations. Il associe des sauvegardes exploitables, une procédure accessible pendant la panne et un test de restauration validé par les équipes métier. Commencez par un processus critique, puis élargissez le périmètre après avoir mesuré la reprise réelle.
Votre ERP est sauvegardé chaque nuit. Mais demain matin, si personne ne peut s’y connecter, savez-vous comment reprendre les commandes et préparer les livraisons ? Une sauvegarde réussie ne répond pas à cette question. Le sujet concerne autant la direction et les opérations que le prestataire informatique : il faut décider ce que l’entreprise doit pouvoir faire pendant l’arrêt, puis organiser le retour à un fonctionnement fiable.
Sauvegarde, PRA et PCA : trois besoins différents
La sauvegarde conserve une copie permettant de récupérer des données ou un système. Le plan de reprise d’activité informatique, ou PRA, organise le redémarrage des services après leur interruption. Le plan de continuité d’activité, ou PCA, prévoit comment poursuivre les activités essentielles pendant la perturbation, éventuellement avec des moyens dégradés.
Dans une PME, ces démarches peuvent tenir dans un ensemble documentaire court. Leur valeur vient de leur utilisation possible pendant un incident : contacts disponibles, décisions préparées, accès de secours et étapes vérifiables. Un dossier très complet mais inaccessible sans le serveur en panne ne rendra aucun service.
La CNIL recommande de formaliser les plans de continuité et de reprise, même sommairement, et d’en tester l’application. Le périmètre technique doit ensuite découler des activités à protéger.
1. Partir des opérations qui ne peuvent pas attendre
Réunissez la direction, un représentant des opérations et le responsable informatique ou son prestataire. Prenez un scénario simple : les outils habituels deviennent indisponibles au début d’une journée chargée. Quelles tâches s’arrêtent immédiatement ? Lesquelles peuvent attendre ? Qui sait reconnaître que le service est réellement revenu ?
Raisonnez en activités : enregistrer une commande, expédier un produit, accéder à un dossier d’intervention ou facturer. « Restaurer le serveur » est une action technique ; « permettre aux préparateurs de retrouver les commandes à livrer » est un résultat métier contrôlable.
| Activité | Dépendances à vérifier | Solution temporaire à préparer |
|---|---|---|
| Traiter les commandes | ERP, identités, catalogue, connecteur commercial | Collecte contrôlée des nouvelles demandes avec référence unique |
| Préparer les livraisons | Stock, commandes validées, étiquettes, accès réseau | Liste limitée et datée des expéditions autorisées |
| Assurer les interventions | Planning, dossiers clients, application mobile | Accès sécurisé aux informations strictement nécessaires |
| Facturer | ERP, prestations réalisées, pièces justificatives | Report organisé, puis rapprochement des opérations |
Ces pistes sont à adapter : une copie de planning obsolète peut devenir dangereuse, et un fichier partagé improvisé peut exposer des données clients. Chaque mode temporaire doit avoir un responsable, une durée d’utilisation et une règle de réintégration. Si les dépendances restent floues, un audit SI orienté priorités métier constitue un point de départ utile.
2. Fixer deux objectifs compréhensibles : délai et perte de données
Le RTO : combien de temps pouvez-vous rester à l’arrêt ?
Le RTO est l’objectif de délai de remise en service. Il doit correspondre à une activité et à un niveau de fonctionnement : consulter les commandes prioritaires n’est pas équivalent à rétablir tous les tableaux de bord. Le délai technique annoncé par un fournisseur ne couvre pas forcément la détection, la décision, la remise en place des accès et la validation métier.
Le RPO : jusqu’où pouvez-vous revenir en arrière ?
Le RPO exprime la perte de données maximale visée, mesurée dans le temps. Avec une copie quotidienne, les modifications intervenues après le dernier point récupérable peuvent manquer. Il faut également examiner les pièces jointes, les échanges entre logiciels et les opérations effectuées pendant la panne.
Exemple fictif : une PME vise une reprise des commandes sous quatre heures et une perte maximale d’une heure de saisie. Une sauvegarde nocturne seule ne permet pas de tenir ce second objectif. L’équipe doit adapter la protection, revoir l’objectif ou préparer un moyen fiable de reconstituer les commandes manquantes. Ces chiffres illustrent un arbitrage, sans constituer une recommandation universelle.
Évitez de demander le délai le plus court pour tous les outils. La direction doit comparer le coût du dispositif au coût de l’arrêt : activité bloquée, travail à refaire, engagements clients et mobilisation des équipes. L’objectif retenu reste une cible à éprouver ; il ne devient pas une garantie parce qu’il figure dans un document.
3. Vérifier ce qui est réellement récupérable
Une ligne verte dans une console de sauvegarde prouve qu’une tâche s’est terminée selon ses critères. Elle ne prouve pas qu’un utilisateur pourra travailler dans l’application restaurée. Demandez la liste des éléments couverts et celle des exclusions : bases de données, documents, configuration, pièces jointes, droits, secrets techniques et versions nécessaires au redémarrage.
La fiche CNIL sur les sauvegardes recommande notamment une copie géographiquement distincte, une sauvegarde hors ligne et des contrôles réguliers de restauration. Elle rappelle aussi de protéger les copies au même niveau que les données exploitées. Ces principes doivent être traduits en mesures vérifiables dans votre environnement.
Vérifiez les comptes capables de supprimer les copies, les moyens de déchiffrement et la disponibilité des accès de secours. Une copie indépendante perd son intérêt si le même compte compromis permet de l’effacer. La durée de conservation doit aussi permettre de retrouver un état exploitable lorsque l’anomalie est découverte tardivement.
Inclure les logiciels en ligne dans le périmètre
Pour chaque application SaaS, vérifiez contractuellement et techniquement ce qui peut être restauré : élément supprimé, compte entier, version antérieure, configuration et relations entre objets. Une fonction d’export n’équivaut pas forcément à une restauration complète. La synchronisation peut également reproduire une suppression ou une erreur sur plusieurs appareils.
Pour un logiciel développé sur mesure, conservez la procédure de déploiement, les dépendances et les paramètres nécessaires. Cybermalveillance.gouv.fr rappelle de prévoir aussi les logiciels indispensables à l’exploitation des données. Posséder les fichiers ne suffit pas si l’application capable de les ouvrir ne peut plus être remise en service.
4. Écrire une procédure utilisable pendant la panne
Préparez une fiche de reprise pour chaque service prioritaire. Elle doit permettre à une personne désignée d’avancer sans dépendre de la mémoire d’un seul technicien. Conservez une version accessible en dehors du système concerné, avec une protection adaptée aux informations qu’elle contient.
- Le scénario couvert et les conditions de déclenchement du plan.
- Le décideur, son remplaçant et les coordonnées des intervenants.
- Les dépendances et l’ordre de redémarrage.
- Le point de restauration à sélectionner et les contrôles préalables.
- Les étapes techniques et les critères de validation métier.
- Le traitement des opérations saisies pendant l’arrêt.
- Les conditions de retour au fonctionnement normal et de clôture.
Distinguez les scénarios. Une panne matérielle connue et une suspicion de compromission n’appellent pas la même reprise. En cas d’attaque, reconnecter précipitamment un environnement restauré peut réintroduire la menace. La remise en service doit être coordonnée avec les personnes chargées de contenir l’incident et de vérifier l’environnement.
Clarifiez les responsabilités avec le prestataire : qui lance la restauration, qui fournit les accès, qui vérifie les données et qui autorise la reprise ? Un contrat de support doit être rapproché des objectifs attendus, des horaires d’intervention et des exclusions. Lorsque plusieurs fournisseurs interviennent, un pilotage IT externalisé peut aider à organiser ces arbitrages.
5. Tester une activité complète, pas seulement un fichier
Commencez dans un environnement isolé pour limiter l’impact sur la production. Désignez un pilote, prévoyez l’arrêt du test et empêchez les envois réels : courriels clients, commandes fournisseurs ou écritures déclenchées automatiquement. Les données restaurées et les comptes de test doivent rester protégés.
- Choisir une activité critique et un scénario d’interruption précis.
- Chronométrer la mobilisation, la restauration et la remise en place des accès.
- Faire exécuter un parcours représentatif par un utilisateur métier.
- Comparer les données récupérées au point de reprise attendu.
- Vérifier les droits, les pièces jointes et les échanges avec les autres outils.
- Consigner les écarts, attribuer les corrections et recontrôler les points bloquants.
Pour une entreprise qui connecte son CRM à son ERP, le test doit aussi vérifier la reprise des flux : une opération déjà traitée ne doit pas créer une deuxième commande. Documentez comment rapprocher les états des deux outils avant de relancer les synchronisations.
Le compte rendu peut tenir sur une page : périmètre, date, durée observée, données manquantes, validations et corrections. Prévoyez de nouveaux exercices selon la criticité et après les changements importants d’application, d’hébergement ou de prestataire. La fréquence choisie doit correspondre à vos risques et à vos moyens.
Quel premier périmètre confier à un accompagnement externe ?
Un cadrage utile produit des livrables concrets : liste des activités prioritaires, dépendances, objectifs de reprise, couverture des sauvegardes, responsabilités et protocole de test. Il doit faire apparaître les limites actuelles avant de proposer de nouveaux équipements. Vous pourrez alors distinguer une amélioration de configuration, une procédure manquante et un investissement d’architecture.
Préparez votre inventaire d’applications, les contrats de support, les comptes rendus de sauvegarde disponibles et le récit du dernier incident. Ces éléments permettent de travailler sur vos conditions réelles, sans transformer le premier échange en comparaison abstraite de solutions.
Vous ne savez pas combien de temps votre PME mettrait à redémarrer son CRM, son ERP ou son application métier ? Échangeons avec Vezerance sur vos activités critiques pour cadrer les priorités, les responsabilités et un premier test de reprise exploitable.
