Résilience informatique : définition et mise en œuvre

La résilience informatique est la capacité d’une organisation à continuer de fonctionner pendant un incident, puis à revenir à la normale dans un délai maîtrisé. Elle ne cherche pas à éviter la panne, la cyberattaque ou la coupure : elle organise l’entreprise pour que ces événements ne la mettent pas à l’arrêt.

La distinction avec la sécurité est nette et souvent brouillée. La sécurité réduit la probabilité qu’un incident survienne ; la résilience réduit ses conséquences. Une entreprise très bien protégée mais incapable de restaurer ses données a traité un seul des deux problèmes, et pas celui qui décide de sa survie.

Les quatre piliers

1. La redondance de ce qui est critique. Un second lien internet chez un opérateur différent, une alimentation de secours, un serveur capable de reprendre le rôle d’un autre. Elle ne se justifie que sur les éléments dont l’arrêt suspend l’activité, pas partout.
2. Une sauvegarde réellement restaurable. Hors site, hors de portée d’un compte d’administration compromis, et vérifiée par des restaurations d’essai. C’est le pilier le plus souvent déclaré et le moins souvent testé, sujet développé sur nos pages sauvegarde externalisée et stratégie 3-2-1.
3. Un plan écrit et exercé. Qui décide, qui prévient qui, dans quel ordre on remonte les services, et comment on travaille pendant l’interruption. Un plan jamais joué est une intention, pas un plan.
4. Les dépendances externes maîtrisées. Le pilier oublié, traité juste après.

Les deux chiffres qui structurent tout

Deux décisions de direction, pas deux paramètres techniques : combien de temps l’entreprise peut rester à l’arrêt, et combien de travail elle accepte de refaire. La première commande l’architecture de reprise, la seconde la fréquence des sauvegardes. Tant qu’elles ne sont pas écrites et validées par la direction, la conception technique se fait au jugé et sera contestée le jour de l’incident. Le calcul du coût associé est développé sur notre page coût d’un arrêt informatique, et les engagements correspondants sur notre page GTI et GTR.

Les dépendances que personne ne recense

Une entreprise peut avoir tout prévu chez elle et rester à l’arrêt à cause de quelqu’un d’autre. Trois dépendances reviennent systématiquement, et aucune n’apparaît dans un inventaire technique classique :

• L’opérateur télécom. Un seul lien internet, et l’entreprise entière dépend d’une pelleteuse. C’est la dépendance la plus facile à réduire et la plus souvent négligée.
• Les services en ligne. Votre logiciel métier hébergé chez un éditeur : que se passe-t-il s’il est indisponible trois jours, ou s’il disparaît ? Vos données sont-elles extractibles, dans quel format et à quel coût ?
• Le prestataire informatique lui-même. S’il est votre unique détenteur des accès et de la documentation, il constitue un point unique de défaillance. Exiger la réversibilité, c’est-à-dire la restitution des accès, des données et de la documentation, relève de la résilience autant que du droit.

Ce que DORA appelle résilience opérationnelle numérique

Pour les entités financières européennes, cette exigence est devenue réglementaire. Le règlement DORA impose un cadre formel : recenser les fonctions critiques, gérer les risques liés aux prestataires informatiques, tester régulièrement la capacité de reprise, notifier les incidents majeurs dans des délais courts et prévoir une stratégie de sortie pour chaque fournisseur essentiel.

La logique est exactement celle décrite plus haut, avec deux différences : elle est écrite, et elle est contrôlable. C’est le sujet de notre page infogérance en finance régulée. Pour les entreprises non soumises au texte, il constitue une grille de lecture utile, à laquelle s’ajoutent les demandes croissantes des clients et des assureurs. Et le risque n’a rien de théorique dans ce secteur : notre analyse de la menace d’espionnage sur les PME de la finance détaille ce que cherchent réellement les attaquants.

Hors finance, la même logique arrive pour plus de 15 000 organisations : périmètre, calendrier français et préparation sont sur notre page directive NIS2.

Comment on la vérifie

Par un exercice, pas par un document. La forme la plus simple tient en deux heures : on choisit un scénario, la salle serveurs est inaccessible ou les données sont chiffrées, et on déroule. Qui appelle-t-on, avec quel annuaire si la messagerie est tombée, quel service remonte en premier, comment continue-t-on à facturer entre-temps. Les manques apparaissent en quelques minutes, et ce sont rarement ceux qu’on attendait. Le cadre complet est décrit sur nos pages continuité et reprise d’activité et BCDR.

Questions fréquentes sur la résilience informatique

Qu’est-ce que la résilience informatique ?

C’est la capacité d’un système d’information à absorber un incident sans interrompre l’activité de façon prolongée, puis à revenir à un fonctionnement normal dans un délai défini à l’avance. Elle combine redondance, sauvegarde restaurable, plan de crise exercé et maîtrise des dépendances externes.

Quelle différence entre sécurité et résilience ?

La sécurité vise à empêcher l’incident, la résilience à en limiter les conséquences. Elles se complètent : aucune protection n’est totale, et une entreprise qui n’a travaillé que la prévention découvre au pire moment qu’elle n’a pas de plan.

Quelle différence entre résilience et plan de reprise d’activité ?

Le plan de reprise est l’un des instruments de la résilience : il décrit comment redémarrer après une interruption. La résilience est plus large, puisqu’elle englobe la capacité à continuer de fonctionner pendant l’incident, la robustesse de l’architecture et la maîtrise des dépendances aux tiers.

DORA concerne-t-il notre entreprise ?

Le règlement s’applique aux entités financières européennes et à leurs prestataires informatiques critiques. Une PME hors du secteur financier n’y est pas soumise directement, mais elle peut l’être indirectement si elle fournit un service à une entité concernée, et elle rencontrera les mêmes exigences par la voie des questionnaires clients et des assureurs.

Par où commencer ?

Par deux chiffres et une liste. Les deux chiffres sont le temps d’arrêt acceptable et la quantité de travail que vous acceptez de refaire, à faire valider par la direction. La liste est celle de vos dépendances externes, opérateurs, éditeurs et prestataires compris. Le reste, y compris le budget, découle de ces trois éléments.

Éprouver votre capacité à redémarrer

Un exercice de deux heures révèle davantage qu’un document de cinquante pages. Prenez 30 minutes avec un ingénieur : nous partons de vos deux chiffres et de vos dépendances réelles, et vous ressortez avec les écarts constatés.