Votre ERP tombe un lundi matin à 8h30. Les commandes ne partent plus, la facturation est figée, les approvisionnements sont aveugles. Combien de temps votre entreprise peut-elle tenir ? Selon l’Uptime Institute (Annual Outage Analysis 2024), 54 % des pannes majeures coûtent plus de 100 000 $ et près d’une sur cinq dépasse le million de dollars. Pour une PME dont l’ERP est le système nerveux central, chaque heure d’arrêt se traduit directement en chiffre d’affaires perdu et en désorganisation opérationnelle.
Le Plan de Continuité d’Activité (PCA) et le Plan de Reprise d’Activité (PRA) ne sont plus des luxes réservés aux grands groupes. Avec la directive NIS2 dont la date limite de conformité totale est fixée au 17 octobre 2026, ces dispositifs deviennent une obligation réglementaire pour un nombre croissant d’entreprises européennes.
Ce guide vous donne une méthodologie concrète pour construire un PRA et un PCA adaptés à votre ERP, avec des modèles de gouvernance, des indicateurs clés et un calendrier de mise en place réaliste.
PCA et PRA : deux dispositifs complémentaires, pas interchangeables
La confusion entre PCA et PRA est fréquente, y compris chez des DSI expérimentés. Elle mène à des choix d’architecture inadaptés et à des budgets mal calibrés.
Le PCA maintient l’activité sans interruption
Le Plan de Continuité d’Activité vise à empêcher toute rupture de service. Il repose sur la redondance : serveurs en miroir, réplication temps réel des bases de données, bascule automatique vers un site secondaire. L’utilisateur final ne devrait idéalement pas percevoir l’incident.
En contexte ERP, un PCA typique implique :
- une infrastructure en haute disponibilité (cluster actif/actif ou actif/passif)
- une réplication synchrone de la base de données ERP
- un basculement réseau automatique (DNS failover, load balancer)
- des procédures dégradées documentées pour les processus critiques (saisie manuelle de commandes, factures d’attente)
Le PRA redémarre après une interruption
Le Plan de Reprise d’Activité intervient après une interruption. L’activité s’est arrêtée, les systèmes sont indisponibles, et le PRA définit comment et en combien de temps on revient à un fonctionnement normal.
En contexte ERP, un PRA comprend :
- des sauvegardes régulières (complètes et incrémentales) stockées hors site
- un environnement de reprise préconfiguré (serveur de secours, VM cloud, infrastructure as code)
- une procédure de restauration testée avec des temps de reprise garantis
- un plan de rattrapage des données perdues entre la dernière sauvegarde et l’incident
Comment les articuler pour votre ERP
Dans la pratique, les deux sont nécessaires. Le PCA couvre les incidents mineurs à modérés (panne serveur, corruption disque, coupure réseau locale). Le PRA prend le relais quand le PCA a échoué ou quand l’incident est majeur (destruction du site, ransomware généralisé, catastrophe naturelle).
| Critère | PCA | PRA |
|---|---|---|
| Objectif | Zéro interruption | Reprise rapide |
| Déclenchement | Automatique | Manuel ou semi-automatique |
| Perte de données cible | Aucune (RPO = 0) | Minutes à heures (RPO > 0) |
| Coût d’infrastructure | Élevé (redondance) | Modéré (secours à froid/tiède) |
| Complexité de test | Haute | Moyenne |
RTO et RPO : les deux métriques qui pilotent tout
Avant de concevoir votre dispositif, vous devez répondre à deux questions fondamentales.
RTO : combien de temps pouvez-vous rester à l’arrêt ?
Le Recovery Time Objective (RTO) est la durée maximale d’interruption acceptable pour chaque processus métier supporté par l’ERP.
Un RTO de 4 heures signifie que votre ERP doit être de nouveau opérationnel dans les 4 heures suivant l’incident, quel que soit sa nature. Ce chiffre ne se décrète pas au doigt mouillé : il se calcule à partir de l’impact financier de l’arrêt.
Méthode de calcul du RTO :
- Identifiez les processus ERP critiques (saisie commande, facturation, production, paie)
- Estimez le coût horaire de l’interruption par processus (CA perdu, pénalités contractuelles, coûts salariaux improductifs)
- Déterminez le seuil au-delà duquel l’impact devient inacceptable
- Ce seuil donne votre RTO cible
Pour une PME industrielle de 100 salariés, un arrêt ERP complet coûte typiquement entre 5 000 et 20 000 € par heure (arrêt de production + salaires + pénalités de retard). Le RTO acceptable se situe souvent entre 2 et 8 heures.
RPO : combien de données pouvez-vous perdre ?
Le Recovery Point Objective (RPO) est la quantité maximale de données que vous acceptez de perdre, mesurée en temps écoulé depuis la dernière sauvegarde exploitable.
Un RPO de 1 heure signifie qu’en cas d’incident, vous perdez au maximum les transactions ERP de la dernière heure. Un RPO de 0 (réplication synchrone) signifie aucune perte de données, mais le coût est nettement plus élevé.
Grille de décision RPO par module ERP :
| Module ERP | RPO recommandé | Justification |
|---|---|---|
| Comptabilité / Finance | 15 min à 1 h | Données financières critiques, contraintes d’audit |
| Production / MES | 1 h à 4 h | Ordres de fabrication reproductibles, capteurs IoT souvent indépendants |
| CRM / ADV | 1 h à 2 h | Commandes client à ressaisir si perdues |
| RH / Paie | 4 h à 24 h | Traitements de paie mensuels, données moins volatiles |
| Achats / Stock | 1 h à 4 h | Mouvements de stock conciliables avec inventaire physique |
Construire votre PRA/PCA en 6 étapes
Étape 1 : cartographier les dépendances de votre ERP
Votre ERP ne fonctionne pas en isolation. Il dépend de dizaines de composants techniques et organisationnels. Avant de concevoir la moindre solution de reprise, cartographiez :
Dépendances techniques :
- Serveur(s) applicatif(s) et base(s) de données
- Interconnexions avec d’autres systèmes (EDI fournisseurs, banque, e-commerce, CRM externe)
- Infrastructure réseau (VPN site à site, accès distant, pare-feu)
- Composants tiers (serveur de messagerie, plateforme de signature électronique, service de géolocalisation)
Dépendances humaines :
- Administrateur ERP (interne ou prestataire)
- DBA (administration base de données)
- Équipe infrastructure / hébergeur
- Intégrateur ERP (pour les incidents applicatifs nécessitant une expertise métier)
Représentez ces dépendances dans un diagramme et affectez à chacune un niveau de criticité (vital, important, secondaire). Cette cartographie servira de base pour dimensionner le budget et prioriser les efforts.
Étape 2 : définir les scénarios de sinistre
Ne préparez pas un plan générique. Préparez des réponses à des scénarios précis :
Scénarios techniques :
- Panne serveur ERP principal (matériel ou hyperviseur)
- Corruption de la base de données (erreur humaine, bug applicatif)
- Ransomware chiffrant le serveur ERP et les sauvegardes locales
- Panne de l’hébergeur cloud (indisponibilité de la zone ou du datacenter)
Scénarios environnementaux :
- Perte du site principal (incendie, inondation, panne électrique prolongée)
- Coupure internet prolongée (indisponibilité de l’ERP cloud)
- Défaillance d’un prestataire critique (intégrateur en liquidation, éditeur racheté)
Pour chaque scénario, documentez la probabilité estimée, l’impact métier (en heures d’arrêt et en euros) et la stratégie de réponse (PCA, PRA, ou procédure dégradée manuelle).
Étape 3 : choisir l’architecture de reprise
Le choix se fait selon un arbitrage coût/temps de reprise :
Site de secours froid (cold site)
- Infrastructure de base, pas de données chargées
- RTO : 24 à 72 h
- Coût annuel : 5 000 à 15 000 €
- Adapté aux ERP non critiques avec un RPO de 24 h acceptable
Site de secours tiède (warm site)
- Serveurs préconfigurés, données répliquées quotidiennement
- RTO : 4 à 12 h
- Coût annuel : 15 000 à 40 000 €
- Bon compromis pour la majorité des PME
Site de secours chaud (hot site)
- Réplication temps réel, basculement automatique
- RTO : quelques minutes à 1 h
- Coût annuel : 40 000 à 100 000 €+
- Indispensable pour les ERP critiques (production continue, e-commerce 24/7)
Cloud DRaaS (Disaster Recovery as a Service)
- Infrastructure de reprise à la demande chez un cloud public (Azure Site Recovery, AWS Elastic Disaster Recovery, OVHcloud DRP)
- RTO : 1 à 4 h selon la configuration
- Coût annuel : 10 000 à 30 000 € (paiement à l’usage)
- Option de plus en plus populaire car elle élimine l’investissement initial en matériel
Étape 4 : documenter les procédures de bascule
Une procédure de bascule ERP doit être exécutable par une personne qui n’est pas l’expert habituel (car cet expert peut être indisponible le jour du sinistre). Le document doit contenir :
Pour chaque scénario de sinistre :
- Critères de déclenchement (quand bascule-t-on ?)
- Chaîne de décision (qui autorise la bascule ?)
- Actions techniques pas à pas (avec copies d’écran et commandes exactes)
- Vérifications post-bascule (checklist de validation : accès utilisateurs, intégrité des données, interfaces actives)
- Procédure de retour à la normale (failback)
- Communication interne et externe (qui prévient qui, avec quel message)
Point critique : la procédure de failback (retour au site principal après l’incident) est souvent négligée. Or le retour est au moins aussi risqué que la bascule initiale, car il faut resynchroniser les données modifiées pendant la période de fonctionnement en mode dégradé.
Étape 5 : tester, tester, encore tester
Un PRA non testé est un PRA qui ne fonctionne pas. L’ANSSI recommande explicitement des tests réguliers et la directive NIS2 impose des tests annuels pour les entités essentielles et importantes.
Types de tests par niveau de maturité :
| Niveau | Type de test | Fréquence | Ce qu’il valide |
|---|---|---|---|
| 1 | Revue sur table (tabletop) | Trimestriel | Les procédures sont à jour, les responsables connaissent leur rôle |
| 2 | Test de restauration isolée | Semestriel | Les sauvegardes sont exploitables, le RTO technique est tenu |
| 3 | Bascule partielle (1 module) | Annuel | Le site de secours fonctionne sur un périmètre réduit |
| 4 | Bascule complète (tout l’ERP) | Annuel | Le RTO et le RPO réels correspondent aux objectifs |
| 5 | Exercice de crise (avec métiers) | Annuel | Les équipes métier savent travailler en mode dégradé |
Règle d’or : chaque test doit produire un rapport écrit avec les écarts constatés, les temps mesurés et un plan d’action correctif. Sans ce retour d’expérience formalisé, le test n’a aucune valeur durable.
Étape 6 : maintenir le dispositif dans le temps
Le PRA/PCA est un document vivant. Il doit être révisé :
- à chaque montée de version de l’ERP (nouveau module, migration cloud, changement d’hébergeur)
- à chaque changement d’infrastructure (nouveau serveur, nouveau réseau, nouvelle interconnexion)
- à chaque évolution organisationnelle (nouveau site, acquisition, externalisation)
- au minimum une fois par an, même sans changement apparent
Désignez un responsable PRA/PCA (souvent le DSI ou le RSSI) avec un mandat clair et un budget dédié. Un plan sans propriétaire est un plan mort.
PRA/PCA et ERP cloud : ce qui change
Si votre ERP est hébergé en SaaS (Odoo Online, SAP S/4HANA Cloud Public, NetSuite, Sage Intacct), une partie de la responsabilité PRA/PCA incombe à l’éditeur. Mais attention : une partie seulement.
Ce que l’éditeur SaaS prend en charge
- Redondance de l’infrastructure (datacenters, réplication base de données)
- Sauvegardes applicatives régulières
- Plan de reprise en cas de panne de leur plateforme
- SLA contractuel (disponibilité annuelle, typiquement 99,5 % à 99,9 %)
Ce qui reste de votre responsabilité
- Données métier : l’éditeur sauvegarde l’infrastructure, pas nécessairement vos paramétrages spécifiques, vos rapports personnalisés ou vos données de configuration
- Intégrations : si votre ERP SaaS est connecté à un EDI, un e-commerce ou un BI, la continuité de ces flux est votre problème
- Accès réseau : si votre connexion internet tombe, votre ERP SaaS est inaccessible, même s’il fonctionne parfaitement chez l’éditeur
- Processus dégradés : que font vos équipes si l’ERP est indisponible pendant 4 heures ? Ce scénario doit être documenté et répété
- Portabilité des données : en cas de défaillance majeure de l’éditeur (cessation d’activité, incident de sécurité grave), avez-vous un export récent et exploitable de vos données ?
Questions à poser à votre éditeur cloud
Avant de signer ou de renouveler un contrat ERP SaaS, exigez des réponses écrites sur ces points :
- Quel est le RPO garanti contractuellement (pas dans la documentation marketing) ?
- Le PRA de la plateforme est-il testé ? À quelle fréquence ? Puis-je voir le dernier rapport ?
- En cas de sinistre datacenter, quel est le RTO mesuré lors du dernier test ?
- Mes données sont-elles répliquées dans un datacenter géographiquement distant ?
- Puis-je exporter l’intégralité de mes données dans un format exploitable (SQL dump, CSV structuré) ?
- Que se passe-t-il si votre entreprise cesse son activité ? (clause d’escrow, accès au code source)
Pour approfondir le sujet du choix entre cloud et on-premise, consultez notre comparatif ERP cloud vs on-premise.
Conformité réglementaire : NIS2 et au-delà
Ce que NIS2 exige concrètement
La directive NIS2, dont la transposition française vise une conformité totale au 17 octobre 2026, impose aux entités essentielles et importantes un ensemble de mesures de gestion des risques cybersécurité, parmi lesquelles :
- des politiques relatives à la continuité des activités, incluant la gestion des sauvegardes et la reprise après sinistre
- des procédures de gestion des incidents avec notification obligatoire dans les 24 heures (alerte initiale) et 72 heures (rapport détaillé)
- une évaluation de l’efficacité des mesures de gestion des risques, ce qui implique des tests réguliers du PRA/PCA
Les sanctions en cas de non-conformité peuvent atteindre 10 millions d’euros ou 2 % du chiffre d’affaires annuel mondial pour les entités essentielles.
Au-delà de NIS2
D’autres réglementations renforcent l’exigence de continuité :
- DORA (Digital Operational Resilience Act) pour le secteur financier : tests de résilience opérationnelle numérique obligatoires, avec des scénarios de stress incluant les prestataires tiers ICT
- RGPD (article 32) : obligation de garantir la disponibilité et la résilience des systèmes traitant des données personnelles
- ISO 22301 : norme internationale pour les systèmes de management de la continuité d’activité, souvent exigée par les donneurs d’ordre dans les appels d’offres
Pour une vue d’ensemble de la cybersécurité appliquée à l’ERP, lisez notre guide ERP et cybersécurité.
Budget : combien investir dans votre PRA/PCA ERP
Le budget dépend de votre RTO cible et de la taille de votre infrastructure ERP. Voici des fourchettes indicatives pour une PME de 50 à 200 salariés :
Investissement initial
| Poste | Fourchette |
|---|---|
| Audit de risques et BIA (Business Impact Analysis) | 5 000 à 15 000 € |
| Conception du PRA/PCA (cabinet conseil ou RSSI interne) | 10 000 à 25 000 € |
| Infrastructure de secours (selon cold/warm/hot) | 5 000 à 60 000 € |
| Mise en place technique (configuration, réplication, scripts) | 8 000 à 20 000 € |
| Formation des équipes et premier test | 3 000 à 8 000 € |
| Total initial | 31 000 à 128 000 € |
Coûts récurrents annuels
| Poste | Fourchette |
|---|---|
| Hébergement site de secours / DRaaS | 5 000 à 40 000 € |
| Maintenance et mise à jour des procédures | 3 000 à 10 000 € |
| Tests annuels (2 à 4 tests/an) | 5 000 à 15 000 € |
| Licences logicielles de réplication/backup | 2 000 à 8 000 € |
| Total annuel | 15 000 à 73 000 € |
Règle de proportionnalité : le budget PRA/PCA représente typiquement 5 à 15 % du budget IT annuel. Si votre ERP supporte un chiffre d’affaires de 10 M€ et qu’une journée d’arrêt coûte 50 000 €, un investissement de 50 000 €/an en continuité est un arbitrage rationnel.
Les erreurs qui rendent votre PRA inutile
Voici les erreurs les plus fréquentes, observées sur le terrain :
1. Sauvegardes jamais testées en restauration Avoir des sauvegardes qui tournent chaque nuit est rassurant. Mais 30 % des restaurations de sauvegardes échouent lors du premier essai, selon les retours d’expérience des prestataires d’infogérance. Testez la restauration complète de votre base ERP au moins une fois par trimestre.
2. PRA qui n’inclut pas les interconnexions Votre ERP redémarre en 2 heures, mais l’EDI avec vos fournisseurs met 48 heures à se reconnecter. Résultat : l’ERP tourne à vide. Le PRA doit couvrir l’écosystème complet, pas seulement le serveur applicatif.
3. Procédures obsolètes Le PRA mentionne un serveur qui a été décommissionné il y a 6 mois. Le contact d’astreinte a quitté l’entreprise. Le VPN de secours utilise un certificat expiré. Un PRA non maintenu est pire qu’un PRA inexistant : il donne une fausse assurance.
4. Aucune procédure dégradée métier Le PRA technique est parfait, mais personne n’a expliqué aux commerciaux comment saisir une commande sur papier en attendant le retour de l’ERP. Les processus dégradés doivent être documentés, imprimés (oui, sur papier) et accessibles sans accès informatique.
5. RTO et RPO définis par l’IT sans validation métier L’IT décrète un RTO de 24 heures parce que c’est faisable techniquement. Le directeur commercial découvre le jour du sinistre que 24 heures sans ERP signifie 200 000 € de commandes perdues. Le RTO est une décision de direction générale, pas un paramètre technique.
Passer à l’action : votre feuille de route sur 3 mois
Mois 1 : diagnostic et cadrage
- Cartographier les dépendances ERP (technique + humaines)
- Réaliser un Business Impact Analysis (BIA) par processus
- Définir les RTO/RPO cibles avec la direction
- Choisir l’architecture de reprise (cold/warm/hot/DRaaS)
Mois 2 : conception et implémentation
- Rédiger les procédures de bascule et de failback
- Mettre en place l’infrastructure de secours
- Configurer la réplication et les sauvegardes
- Documenter les processus dégradés métier
Mois 3 : test et officialisation
- Exécuter un premier test de restauration complète
- Mesurer le RTO et le RPO réels vs objectifs
- Former les équipes (IT et métier)
- Officialiser le PRA/PCA avec signature de la direction
Pour valider votre approche sur un périmètre réduit, partez sur un POC 3 mois ciblé sur 1 processus critique (facturation ou production). Budget typique : 15 à 30 K€. Résultat : une mesure réelle de votre RTO et RPO, pas une estimation théorique.
Pour approfondir la structuration de votre projet ERP et la répartition des rôles, consultez notre guide sur la composition de l’équipe projet ERP et notre guide complet d’implémentation ERP.
