PME en Guadeloupe et en Guyane : PCA, PRA — anticiper la continuité IT avant la saison cyclonique

Une saison qui revient chaque année, un sujet trop souvent traité dans l'urgence

La saison cyclonique en zone Antilles-Guyane s'étend de juin à novembre, avec un pic entre août et octobre. Ce n'est pas un risque exceptionnel à anticiper une fois pour toutes — c'est un rendez-vous annuel, connu à l'avance, avec une fenêtre de préparation qui se referme chaque année à peu près à la même période. Pourtant, la continuité informatique reste, pour beaucoup de PME du territoire, un sujet traité au moment de l'alerte plutôt qu'en amont — quand il ne reste plus le temps de faire les bons choix, seulement celui d'appliquer ceux qu'on aurait dû faire des mois plus tôt.

PCA, PRA : deux plans distincts, souvent confondus

Le vocabulaire lui-même entretient la confusion, et cette confusion a un coût : elle fait souvent croire qu'un seul document couvre tout le sujet, alors qu'il s'agit de deux plans complémentaires, à des échelles différentes.

• Le PCA (plan de continuité d'activité) couvre l'ensemble de l'entreprise, pas seulement l'informatique : comment l'activité continue — même en mode dégradé — pendant la crise. Il répond à la question « qui fait quoi, avec quels moyens, pendant que le SI n'est pas pleinement disponible ? ».
• Le PRA (plan de reprise d'activité) est le volet technique, spécifiquement IT, souvent inclus dans le PCA comme un de ses composants. Il répond à une question plus étroite mais plus précise : « comment et en combien de temps restaure-t-on les systèmes une fois l'incident passé ? ».

Une PME qui n'a qu'un PRA (des sauvegardes et une procédure de restauration technique) mais pas de PCA sait comment relancer ses serveurs — mais pas comment ses équipes continuent à facturer, payer les salaires ou répondre aux clients pendant les heures ou les jours où ce n'est pas encore le cas. À l'inverse, un PCA sans PRA solide repose sur des bonnes intentions sans garantie que les données existent encore pour les exécuter. Les deux plans se construisent ensemble, pas l'un après l'autre.

La question qui compte le plus : combien de temps l'entreprise peut-elle tenir ?

C'est la question centrale d'un PRA, et la plupart des dirigeants de PME n'ont jamais mis de chiffre dessus. Deux indicateurs suffisent à cadrer la réponse :

• le RTO (recovery time objective) — combien de temps l'entreprise peut rester sans accès à un système avant que l'impact devienne critique ;
• le RPO (recovery point objective) — jusqu'à quelle ancienneté de données une perte serait acceptable en cas de restauration.

Sans ces deux réponses, la fréquence des sauvegardes et le choix de l'hébergement sont fixés arbitrairement — souvent par défaut, rarement par une décision consciente du niveau de risque que l'entreprise accepte réellement de porter. Et ces deux indicateurs ne sont pas uniformes : une PME n'a presque jamais un seul RTO, mais plusieurs, selon la fonction concernée.

Des solutions dimensionnées par niveau de criticité, pas un plan unique

L'erreur la plus fréquente est de vouloir appliquer le même niveau d'exigence à toute l'activité — ce qui conduit soit à sur-investir partout, soit, plus souvent, à ne rien faire faute de budget pour tout couvrir. Trois niveaux suffisent généralement à structurer les choix :

• Fonctions vitales (RTO de quelques heures) — facturation, paiement des salaires, communication client. Ces fonctions justifient une réplication continue ou quasi continue vers un hébergement hors zone cyclonique, avec bascule testée, pas seulement documentée.
• Fonctions importantes (RTO de 24 à 48 heures) — ce qui peut attendre un jour ou deux sans dommage grave. Une sauvegarde quotidienne, effectivement testée par une restauration réelle et pas seulement programmée, suffit dans la plupart des cas.
• Fonctions différables (RTO au-delà de 48 heures) — le confort ou la modernisation pure. Une sauvegarde hebdomadaire classique couvre le besoin, sans justifier d'investissement supplémentaire.

Ce séquençage évite l'écueil le plus courant : consacrer le même effort à protéger un outil accessoire qu'à protéger la facturation, faute d'avoir hiérarchisé les fonctions en amont.

Pourquoi l'hébergement hors zone ne suffit pas à lui seul

Le réflexe le plus courant, une fois le risque identifié, est d'héberger les données hors zone cyclonique — par exemple sur une région cloud européenne, ce qui a aussi l'avantage de rester cohérent avec les exigences RGPD. C'est une bonne pratique, mais elle ne répond qu'à la moitié du problème : si la connectivité internet du territoire est elle-même dégradée après un événement, un hébergement à distance ne sert à rien tant que l'accès réseau local n'est pas rétabli. Les données sont en sécurité, mais inaccessibles au moment où l'entreprise en aurait besoin pour reprendre son activité sur place.

Deux risques distincts appellent donc deux réponses distinctes :

• la perte de données — traitée par une réplication ou un hébergement hors zone, avec un RPO défini et vérifié ;
• la perte de connectivité locale — traitée par un mode dégradé qui ne dépend pas d'un accès réseau permanent, ou par une liaison de secours indépendante du réseau fixe principal (un boîtier 4G/5G de secours, voire une liaison satellite pour les activités qui ne peuvent tolérer aucune coupure prolongée).

Un dispositif qui ne couvre que le premier risque donne un faux sentiment de sécurité : techniquement conforme, mais inutile le jour où c'est justement l'accès au réseau, pas les données, qui fait défaut.

Ce qui distingue une entreprise préparée d'une entreprise qui découvre le sujet en pleine alerte

La différence ne se joue presque jamais sur la sophistication technique du dispositif — elle se joue sur trois habitudes prises avant le début de la saison plutôt que pendant :

• chiffrer le RTO et le RPO de chaque fonction, même approximativement — un chiffre discuté vaut mieux qu'aucun chiffre ;
• tester le plan une fois par an, avant juin, par une restauration réelle et une simulation de bascule, plutôt que de se fier à un document rédigé une fois et jamais revérifié ;
• désigner à l'avance qui fait quoi en cas d'alerte — qui déclenche le mode dégradé, qui informe les clients, qui a l'autorité pour prendre ces décisions en l'absence du dirigeant.

Cadrer ces trois points se fait généralement à l'occasion d'un diagnostic initial de l'existant, qui sert de base pour dimensionner un PCA/PRA réaliste plutôt que théorique. Une entreprise qui a posé ce cadrage avant le mois de juin aborde une alerte cyclonique très différemment d'une entreprise qui découvre, l'alerte déjà déclenchée, qu'elle n'a jamais vérifié si ses sauvegardes fonctionnaient réellement.