RTO et RPO en PME : chiffrer l'arrêt que votre parc IT supporte

Deux indicateurs suffisent à piloter l'informatique d'une PME : le RTO, durée d'interruption maximale tolérable, et le RPO, volume de données que vous acceptez de perdre. Tant qu'ils ne sont pas écrits, validés par la direction et testés, votre parc et vos sauvegardes reposent sur une hypothèse, pas sur un plan.

Le symptôme : personne ne sait répondre à la question

Demandez à votre prestataire informatique combien de temps il faut pour remettre votre serveur de fichiers en service après une panne disque. Si la réponse commence par « ça dépend » et se termine sans chiffre, vous avez identifié le problème.

Ce flou se reconnaît à quelques signes très concrets. Le serveur principal est dans un placard, sous garantie expirée, et personne ne sait exactement ce qui tourne dessus. Les postes des collaborateurs ont entre cinq et huit ans, certains démarrent en plusieurs minutes. Une sauvegarde s'exécute la nuit, un voyant vert le confirme, mais aucun test de restauration n'a jamais été mené de bout en bout. Et la personne qui a tout installé, souvent un prestataire historique ou un salarié débrouillard, est la seule à savoir où sont les mots de passe.

Un parc informatique vieillissant ne tombe pas en panne d'un coup : il se dégrade par incidents isolés, que l'on traite un par un, jusqu'au jour où l'un d'eux arrête l'entreprise.

Ce que coûte réellement l'attente

Le coût d'un temps de reprise d'activité non maîtrisé ne se lit pas sur une facture, ce qui le rend facile à ignorer. Il se répartit ailleurs.

D'abord, sur l'activité commerciale. Pendant une interruption, les devis ne sortent pas, les commandes ne sont pas saisies, les appels entrants ne sont pas traités. La demande n'est pas reportée, elle est souvent captée ailleurs.

Ensuite, sur le temps interne. Chaque incident mobilise un dirigeant ou un responsable administratif pendant des heures sur des sujets qui ne relèvent pas de son métier. Ce temps ne se récupère pas.

Sur le plan juridique, un incident entraînant une perte ou une divulgation de données personnelles déclenche les obligations du RGPD, notamment la notification à la CNIL prévue par son article 33 dans un délai de 72 heures après la prise de connaissance. Sans journalisation ni inventaire, cette notification est très difficile à instruire correctement.

Enfin, il y a la dépendance. Quand une seule personne détient la configuration réelle du système d'information, vous ne négociez plus vos conditions : vous les subissez. C'est l'un des effets les plus coûteux d'une infrastructure IT de PME non documentée.

La méthode : fixer vos RTO et RPO, puis dimensionner le parc

L'ordre compte. On ne choisit pas un matériel ou une solution de sauvegarde avant d'avoir défini ce que l'entreprise doit encaisser.

1. Inventorier ce qui existe réellement

Listez chaque serveur, poste, équipement réseau, licence et service en ligne, avec son âge, sa garantie, sa version de système d'exploitation et son responsable. Les postes dont le système n'est plus mis à jour par l'éditeur passent immédiatement en priorité haute : l'obsolescence matérielle et logicielle est la porte d'entrée la plus courante.

2. Construire une matrice de criticité des applications

Classez chaque service selon l'impact d'une indisponibilité. Il s'agit d'un arbitrage de direction, pas d'une décision technique.

| Classe | Exemples typiques | Question à trancher | |---|---|---| | Vital | ERP, messagerie, téléphonie, accès aux dossiers clients | Combien d'heures avant perte de chiffre d'affaires ou rupture de service client ? | | Important | Outils de production interne, partage documentaire secondaire | Peut-on travailler en mode dégradé une journée ? | | Différable | Archives, postes de test, outils annexes | Peut-on attendre plusieurs jours sans conséquence ? |

3. Écrire les RTO et RPO, classe par classe

Pour chaque classe, fixez une durée d'arrêt acceptable et une perte de données maximale admissible. Un RPO de vingt-quatre heures signifie que vous acceptez de ressaisir une journée de travail. Formulé ainsi, l'arbitrage redevient compréhensible pour un dirigeant. Ces deux valeurs deviennent le cahier des charges de tout le reste.

4. Cartographier les dépendances

Un ERP restauré ne sert à rien si l'annuaire d'authentification, le DNS interne ou le lien opérateur ne sont pas revenus avant lui. La cartographie des dépendances définit l'ordre de redémarrage. C'est elle qui transforme une liste de sauvegardes en procédure de reprise.

5. Aligner la sauvegarde sur le RPO, pas l'inverse

Fréquence, rétention, isolation hors ligne ou immuable, séparation des sites : chaque paramètre découle du RPO retenu. Sur la structure d'un dispositif de sauvegarde réellement restaurable, l'article Sauvegardes : Pourquoi la Vôtre Ne Vous Sauvera Peut-Être Pas détaille les écarts les plus fréquents entre ce que l'on croit sauvegarder et ce que l'on peut rejouer.

6. Décider ce qui reste sur site et ce qui part en ligne

Un serveur unique en fin de vie dans un local non climatisé rend tout RTO court illusoire. L'arbitrage entre renouvellement sur site, hébergement mutualisé ou cloud privé se tranche avec les RTO en main et non par principe. La démarche est décrite dans Migration cloud PME : quitter un serveur local sans coupure.

7. Étaler le renouvellement sur plusieurs exercices

Un plan de renouvellement du parc informatique se construit par vagues : d'abord les équipements qui portent un service vital et sortent de support, ensuite les postes les plus lents, enfin le reste. Un budget IT lissé sur trois ans évite la dépense de crise, toujours plus chère qu'un remplacement programmé, et rend l'investissement prévisible.

Comment vérifier que c'est bien fait

Quatre contrôles permettent de juger la qualité du travail, qu'il soit réalisé en interne ou par un prestataire.

Le test de restauration chronométré. Demandez la restauration complète d'un service vital sur un environnement isolé, montre en main. Le résultat se compare au RTO annoncé. Tout écart est une information exploitable, y compris quand il est défavorable.

La documentation opposable. Inventaire daté, schéma réseau, procédure de reprise avec ordre de redémarrage, registre des accès et des comptes à privilèges. Si un technicien extérieur ne peut pas redémarrer votre système d'information avec ces documents, ils sont incomplets.

La preuve d'isolation des sauvegardes. Une copie accessible depuis les mêmes identifiants que la production ne protège pas d'un rançongiciel. Exigez la démonstration qu'au moins une copie est hors ligne ou immuable.

La réversibilité. Les accès administrateurs, noms de domaine, comptes d'hébergement et licences doivent être au nom de votre société. C'est le critère qui distingue un audit d'infrastructure IT honnête d'une relation de dépendance. Pour la couverture des aspects sécurité associés, le guide d'audit de cybersécurité IT pour PME complète utilement ces vérifications.

Ces quatre contrôles sont ce que la direction d'une PME peut exiger sans compétence technique particulière. Ils constituent la base d'une continuité d'activité vérifiable plutôt que déclarative.

Passez à l'action

Tant que vos RTO et RPO ne sont pas écrits, chaque arbitrage sur le matériel, la sauvegarde ou l'hébergement se prend à l'aveugle, et la facture arrive au pire moment : pendant la panne.

Securium Agency réalise des audits d'infrastructure pour les PME d'Île-de-France : inventaire du parc, matrice de criticité, définition des RTO et RPO avec la direction, test de restauration réel et plan de renouvellement échelonné. Demandez votre audit d'infrastructure gratuit : vous recevez un diagnostic écrit de votre parc, la liste des correctifs classés par criticité et une trajectoire budgétaire étalée sur plusieurs exercices.