En 2026, disposer d’un PCA ou d’un PRA est devenu une exigence réglementaire forte sous l’influence de NIS2 et DORA. Pourtant, de nombreuses entreprises découvrent trop tard que leur plan, bien que documenté, ne fonctionne pas lorsqu’il est mis à l’épreuve.
Dans cet article, nous nous concentrons exclusivement sur les erreurs techniques liées à la composante backup et reprise d’activité du PRA/PCA :
choix de l’infrastructure, stratégie de sauvegarde, immuabilité, RTO/RPO, tests de restauration et maintenance.
Nous ne traiterons pas ici des aspects métier, organisationnels ou de gouvernance du PCA.
Ces erreurs techniques sont particulièrement dangereuses car elles sont souvent invisibles tant qu’un incident réel ne survient pas.
Un PRA qui paraît solide sur papier peut s’effondrer en quelques heures si les sauvegardes sont compromises, si les temps de restauration sont trop longs ou si les tests n’ont jamais été réalisés en conditions réalistes.
À travers ce guide, nous allons identifier les 8 erreurs techniques les plus fréquentes et surtout expliquer comment les éviter ou les corriger efficacement.
Que vous soyez RSSI, DSI ou dirigeant impliqué dans la résilience de votre entreprise, ces éléments vous permettront de renforcer considérablement la fiabilité de votre PRA/PCA.
Pour une vue d’ensemble sur les définitions, les différences entre PCA et PRA ainsi que les obligations réglementaires, nous vous recommandons notre guide complet PCA et PRA 2026.
Même un PRA/PCA bien documenté peut s’avérer inutile voire dangereux si la partie technique (backup, restauration et infrastructure) comporte des failles. En 2026, ces erreurs techniques ne sont plus de simples imperfections : elles peuvent compromettre l’ensemble du plan de reprise et exposer l’entreprise à des conséquences graves.
Les raisons sont multiples et convergentes :
Les ransomwares modernes ciblent systématiquement les sauvegardes. Lorsqu’elles ne sont pas immuables, isolées ou correctement protégées, les attaquants parviennent souvent à les rendre inutilisables. Résultat : même si le plan existe sur le papier, la restauration devient impossible ou trop lente pour limiter les dommages.
NIS2 et DORA ne se contentent plus d’exiger l’existence d’un PRA/PCA.
Ils demandent une résilience démontrée et des tests probants. Un plan dont la partie backup et restauration n’a jamais été vérifiée en conditions réalistes risque de ne pas passer un audit ou, pire, de s’effondrer lors d’un incident réel.
Un RTO mal maîtrisé ou un RPO trop élevé peut entraîner des pertes financières importantes (arrêt de production, perte de commandes, pénalités contractuelles). Selon un rapport conjoint de la Cour des comptes et de l'ANSSI (2025), le coût moyen d'une cyberattaque atteint 466 000 € pour une PME, sans compter les dommages indirects sur la réputation et la confiance clients. Pour les ETI et grandes entreprises, ce montant est structurellement plus élevé.
Contrairement aux erreurs organisationnelles, beaucoup d’erreurs techniques restent invisibles tant qu’un test complet ou un incident réel ne survient pas. Une sauvegarde qui semble fonctionner en routine peut s’avérer corrompue ou trop lente lorsqu’on en a vraiment besoin.
C’est pourquoi identifier et corriger ces erreurs techniques n’est pas une simple optimisation : c’est une mesure de protection essentielle pour la continuité de l’activité et la conformité réglementaire.
Dans les sections suivantes, nous détaillons les erreurs les plus fréquentes et surtout les solutions concrètes pour les éviter.
Voici les erreurs techniques les plus fréquentes et les plus coûteuses observées chez les entreprises françaises.
Chacune est accompagnée de ses conséquences réelles et des solutions concrètes pour la corriger.
Toutes ces erreurs ne se valent pas. Certaines sont bloquantes : elles rendent la restauration techniquement impossible et font s'effondrer l'ensemble du PRA. D'autres sont des erreurs de performance : elles dégradent la qualité de la reprise sans l'annuler complètement.
Nous les avons classées en conséquence.
C’est l’erreur la plus répandue et la plus dangereuse.
Beaucoup d’entreprises utilisent encore des sauvegardes classiques qui peuvent être supprimées ou chiffrées par un ransomware si l’attaquant obtient
des droits administrateur.
Conséquences :
Perte totale des sauvegardes → impossibilité de restauration → PRA inefficace.
Comment la corriger :
Mettre en place une vraie immuabilité (Write Once Read Many) avec une période de rétention verrouillée et une détection comportementale active sur les sauvegardes elles-mêmes.
Les sauvegardes restent connectées en permanence au réseau de production.
Conséquences :
Si le réseau est compromis, les sauvegardes le sont aussi.
Comment la corriger :
Maintenir au moins une copie des sauvegardes isolée (air-gapped ou hors-ligne) et accessible uniquement en cas de besoin contrôlé.
Les objectifs de temps de reprise (RTO) et de point de reprise (RPO) sont fixés sans jamais être testés avec les volumes de données réels.
Conséquences :
Écarts majeurs entre le théorique et le réel lors d’un incident → temps d’arrêt beaucoup plus long que prévu.
Comment la corriger :
Réaliser régulièrement des tests complets de restauration et mesurer précisément les RTO/RPO obtenus. Ces tests doivent inclure une restauration bare-metal complète sur au moins un système critique, avec mesure documentée des RTO/RPO réels obtenus.
Se contenter de tests de table ou de restaurations partielles sans jamais tester une reprise complète.
Conséquences :
Découverte des problèmes uniquement lors d’un vrai sinistre.
Comment la corriger :
Instaurer un calendrier de tests annuels complets, avec simulation de ransomware et mesure réelle des performances. Le scénario de test doit inclure une reprise depuis une sauvegarde hors-site, pour valider l'ensemble de la chaîne de restauration et pas uniquement la composante locale.
Pour une méthodologie complète sur la fréquence, les scénarios et les critères de validation des tests, consultez notre guide : Comment tester son PRA selon l'ANSSI en 2026 ?
Beaucoup d'entreprises sauvegardent leurs systèmes sans avoir modélisé l'ordre dans lequel ils doivent être restaurés. Or, un ERP ne peut pas redémarrer si la base de données n'est pas disponible. Un outil de messagerie peut dépendre d'un serveur d'authentification qui lui-même dépend d'un contrôleur de domaine.
Conséquences : Des blocages en cascade lors de la reprise, chaque système attend un autre, les équipes improviseront sous pression, et le RTO réel explose par rapport au RTO théorique.
Comment la corriger : Construire une matrice de dépendances applicatives avant de rédiger le runbook de reprise. Cette matrice doit définir l'ordre précis de restauration et être validée lors des tests — pas seulement sur le papier. Un changement d'infrastructure (migration, ajout d'application) doit déclencher une mise à jour systématique de cette matrice.
Beaucoup d'entreprises construisent leur BIA et définissent leurs RTO/RPO sans consulter leur prestataire backup. La stratégie de sauvegarde est ensuite choisie pour s'adapter au plan existant, plutôt que d'en être le fondement.
Conséquences : Des objectifs RTO/RPO fixés sans savoir s'ils sont techniquement atteignables avec l'infrastructure en place. Des écarts majeurs apparaissent lors des premiers tests.
Comment la corriger : Intégrez le prestataire backup dès la phase BIA. Les contraintes techniques (volumétrie, latence, architecture réseau, criticité des données) doivent alimenter la définition des RTO/RPO, pas l'inverse.
Une sauvegarde qui s'exécute sans erreur apparente n'est pas nécessairement une sauvegarde utilisable. Les corruptions silencieuses, les sauvegardes incomplètes dues à des fichiers verrouillés, ou les espaces disque saturés passent souvent inaperçus pendant des semaines.
Conséquences : Découvrir lors d'un incident que les dernières sauvegardes valides datent de plusieurs semaines. Le RPO réel est alors bien supérieur au RPO contractuel, avec un impact direct sur les données perdues et les délais de reprise.
Comment la corriger : Mettre en place un monitoring actif avec alertes sur chaque job de sauvegarde: succès, échec, durée anormale, taux de déduplication inhabituel. Les rapports doivent être lus et validés régulièrement, pas seulement archivés. Idéalement, le prestataire inclut cette surveillance dans son SLA avec escalade automatique en cas d'anomalie.
Tester uniquement sur le même matériel que la production.
Conséquences : Incapacité à restaurer en cas de destruction physique des serveurs.
Comment la corriger : Réaliser au moins un test par an sur du matériel différent ou en environnement virtuel. Ce type de test valide la résilience opérationnelle réelle de votre PRA, c'est-à-dire sa capacité à fonctionner dans des conditions dégradées, pas seulement en environnement nominal.
Corriger chaque erreur individuellement n'est pas suffisant.
Ce qui fait la différence entre un PRA qui se dégrade progressivement et un PRA qui reste opérationnel dans la durée, c'est une approche structurée de maintenance et de pilotage. Voici les principes qui permettent de tenir dans le temps.
Le prestataire backup doit être impliqué avant que les RTO/RPO soient fixés, pas après.
C'est lui qui peut valider si les objectifs sont techniquement atteignables avec l'infrastructure envisagée.
Le choix entre on-premise, hybride et cloud doit être revu à chaque évolution majeure de l'infrastructure, pas seulement à l'initialisation du PRA.
Une migration vers le cloud ou l'ajout d'un site distant change les hypothèses de restauration.
Ces critères ne doivent pas rester des bonnes pratiques informelles. Ils doivent figurer explicitement dans le SLA du prestataire,
avec des mécanismes de vérification régulière et des pénalités en cas de non-conformité.
Action concrète :
Choisissez un prestataire qui inclut les tests assistés et la production de rapports auditables dans son SLA.
La plupart des erreurs techniques proviennent d’une mise en œuvre ou d’une maintenance insuffisante.
Un prestataire qui prend en charge l’installation, la configuration, les tests et la maintenance proactive réduit considérablement ces risques.
Action concrète :
Privilégiez les offres qui incluent du matériel préconfiguré, une installation plug & play, un datacenter souverain français avec un niveau de disponibilité certifié (Tier 3 minimum) et un SLA clair sur les tests et le support
Un PRA n’est jamais figé. Il doit être revu après chaque changement majeur (nouveau système, migration, évolution des processus).
Action concrète :
Mettez en place une revue annuelle obligatoire avec mise à jour des RTO/RPO et nouvelle campagne de tests.
En appliquant ces principes, vous passez d’un PRA théorique à un plan techniquement résilient, testable et aligné sur les exigences de 2026.
Tout changement majeur (migration, ajout d'application, évolution réseau) doit déclencher une mise à jour du plan de test et une vérification des dépendances applicatives.
Les erreurs techniques dans un PRA/PCA sont plus que de simples détails : elles sont souvent la principale raison pour laquelle un plan de reprise, pourtant bien documenté, échoue lorsqu’il est réellement sollicité.
En 2026, avec la montée en puissance des ransomwares et les exigences croissantes de NIS2 et DORA, un PRA ne peut plus se contenter d’exister sur le papier. Il doit être techniquement robuste, testé régulièrement et reposant sur des sauvegardes fiables, immuables et rapides à restaurer.
Les 8 erreurs les plus fréquentes que nous avons détaillées : sauvegardes non immuables, absence d’isolation, RTO/RPO théoriques, tests insuffisants, dépendances mal cartographiées, choix d’architecture inadapté, manque de maintenance et absence de tests sur matériel différent sont toutes évitables avec une approche rigoureuse et le bon accompagnement.
La clé réside dans une stratégie claire :
Un PRA techniquement solide ne vous protège pas seulement en cas d’incident : il renforce votre conformité, votre crédibilité et votre continuité d’activité.
Vous souhaitez mettre en place un PRA ou challenger votre PRA actuel ? découvrez nos solutions de PRA dynamique :
