Bulletin sur la récupérabilité n° 3

Vous pouvez restaurer tous les serveurs sans pour autant pouvoir faire fonctionner l'entreprise

À l’issue d’une opération de reprise qui s’est déroulée sans encombre d’un point de vue informatique, une centaine de machines ont peut-être été restaurées, les hyperviseurs sont opérationnels et tous les voyants de la console sont au vert. Mais essayez maintenant d’envoyer une facture. Le système ERP est opérationnel, mais l’intégration logistique à laquelle il alimente est toujours hors service, le service fiscal auquel il fait appel n’a pas encore été reconnecté et le fournisseur d’identité qui authentifie l’équipe de facturation n’est toujours pas considéré comme fiable. Les serveurs ont été restaurés. L’activité, elle, ne l’a pas été.

Le rapport 2026 de Fenix24 sur l'état de la capacité de reprise attribue cet écart à la manière dont les organisations définissent une reprise réussie. La plupart évaluent ce qui a été restauré. Très peu évaluent ce que l'entreprise est capable de faire.

La capacité de reprise n'est pas la résilience, et la différence entre les deux porte un nom

Un serveur peut être restauré. Il en va de même pour une base de données, une tâche de sauvegarde ou une image. Mais cela ne signifie pas pour autant que l'activité soit elle-même restaurée, car une entreprise ne fonctionne pas grâce à des composants. Elle fonctionne grâce à des services, et un service n'est restauré que lorsque tous les éléments dont il dépend sont de nouveau opérationnels, en ordre et fiables. Cette norme s'appelle la « restaurabilité opérationnelle », c'est-à-dire la capacité à rétablir le fonctionnement de l'activité plutôt que simplement les systèmes qui la sous-tendent, et c'est à ce niveau que se joue la résilience.

Il est important de bien distinguer ces deux termes, car chacun d’entre eux, pris isolément, flatte l’organisation qui l’utilise. La « récupérabilité » sans la notion d’« opération » n’est qu’un simple décompte de serveurs. La résilience sans la capacité de reprise est une simple politique. La capacité réelle se situe à l’intersection des deux, prouvée en conditions réelles et non pas supposée. Un conseil d’administration à qui l’on dit « nous sommes résilients » et une équipe de sauvegarde qui affirme que « tout est récupérable » peuvent tous deux dire la vérité, alors que l’entreprise reste incapable de reprendre ses activités après une attaque.

Le temps de récupération est déterminé par le maillon le plus lent

Un service métier est une chaîne de dépendances qui relie les applications, les bases de données, les systèmes d’identité, les chemins réseau, l’infrastructure de sauvegarde, les plateformes cloud, les intégrations tierces et les personnes qui les exploitent. Le service redevient opérationnel lorsque la chaîne est rétablie dans son intégralité, dans l’ordre, et pas un instant avant. Un système de paie ne peut être rétabli tant que le fournisseur d’identité chargé de son authentification n’est pas à nouveau considéré comme fiable.

Le temps de reprise correspond donc à un scénario catastrophe plutôt qu’à une moyenne. Restaurer 95 % des dépendances d’un service en un temps record ne sert à rien si les 5 % restants comprennent le maillon sans lequel le service ne peut fonctionner. Et le maillon le plus lent est souvent celui que personne n’a pris en compte dans le plan, car il ne s’agit pas du tout d’un logiciel. L’espace de stockage vient à manquer dans 82 % des interventions de Fenix24, ce qui laisse les données restaurées sans endroit où être stockées sans écraser les traces d’investigation. Dans 38 % des cas, le réseau ne peut pas acheminer les données à l’échelle de la restauration, car une dorsale dimensionnée pour une journée de travail n’a jamais été conçue pour gérer des pétaoctets de données de restauration arrivant en une seule fois. Parfois, la liaison ne peut être rétablie à aucune vitesse, car il s’agit d’un système d’exploitation ou d’une version d’application obsolète qui ne peut plus être obtenue une fois l’original disparu. Chacun de ces problèmes peut être détecté en l’espace d’un après-midi de mesures rigoureuses, mais chacun d’entre eux surgit au contraire en plein milieu d’un incident, facturé au tarif horaire de la restauration.

Zéro sur 800

La chaîne n’est gérable que si quelqu’un l’a dessinée, ce qui nous amène au chiffre le plus frappant du rapport sur l’état de la récupérabilité. Sur plus de 800 missions menées par Fenix24 auprès de ses clients, aucune organisation n’est parvenue à la phase de reprise en disposant d’une vue d’ensemble complète de ses applications et de leurs dépendances. Les approximations les plus proches se trouvaient soit dans une base de données de configuration qui a été détruite lors de l’attaque, soit elles ont été constituées en cours de reprise, une fois que la violation a contraint l’entreprise à décider des éléments à restaurer en priorité, puis révisées au fur et à mesure que la restauration progressait.

Il convient de s’attarder sur ce « zéro », car ces organisations n’ont pas fait preuve de négligence. Beaucoup disposaient de bases de données de gestion de la configuration (CMDB), d’inventaires des actifs et de schémas d’architecture. Le problème est que tous ces éléments répondent à la question « que possédons-nous ? », alors que la restauration en pose une autre : de quoi ce service métier a-t-il besoin pour fonctionner à nouveau, dans quel ordre, et de quoi chacun de ces éléments a-t-il besoin à son tour ? La documentation de déploiement ne précise pas l’ordre de restauration. Les connaissances sur les dépendances qui existent se trouvent dans la tête des ingénieurs qui ont mis en place les intégrations ; or, certains d’entre eux ont quitté l’entreprise, et les autres peuvent ne pas être disponibles au moment précis où ces connaissances sont nécessaires. De plus, l’environnement évolue à chaque migration et à chaque nouveau contrat SaaS, de sorte que même une cartographie précise devient obsolète en quelques mois. Une cartographie des dépendances n’est pas un document. Elle devrait être un modèle évolutif.

La chaîne passe désormais par des sociétés que vous ne contrôlez pas

Chaque année, ces liens de dépendance se situent de plus en plus souvent en dehors de l’entreprise. Selon les chiffres de l’Identity Theft Resource Center, les tiers sont désormais impliqués dans environ 30 % des violations de données, soit le double de leur part en 2021. Les données d’Allianz relatives aux sinistres montrent que les pertes d’exploitation indirectes liées à des incidents chez les fournisseurs et prestataires sont passées de 6 % à 15 % de la valeur des sinistres importants en l’espace d’une seule année, ce qui représente plus du double de leur part dans les indemnités versées par les assureurs. Les dirigeants les plus avancés dans cette réflexion l’ont bien remarqué. Parmi les PDG d’organisations hautement résilientes cités dans les perspectives 2026 du Forum économique mondial, 78 % désignent la chaîne d’approvisionnement et les dépendances vis-à-vis de tiers comme leur principal défi restant à relever.

Le renforcement de la sécurité de votre propre environnement ne fait que déplacer le risque ; il ne l’élimine pas. L’enquête 2026 d’Accenture évalue directement cet angle mort. Soixante et un pour cent des dirigeants affirment que le maintien des opérations critiques dépend de partenaires externes. Seuls 38 % déclarent avoir une vision claire de leur chaîne de valeur et de ses dépendances les plus critiques. Une cartographie des dépendances qui s’arrête au pare-feu ne représente que la moitié de la chaîne.

Conçu pour l'adversaire, utile en cas de panne

Les incidents cybernétiques occupent la première place du classement mondial des menaces opérationnelles établi par DRI International, suivis de près par les perturbations informatiques générales. Les connaissances en matière de dépendances évoquées plus haut s’avèrent utiles dans les deux cas. Une mise à jour logicielle défectueuse ou une panne d’une région cloud entraîne également une perte de chiffre d’affaires et exige de déterminer ce qui doit être rétabli en priorité. Mais ces deux situations sont liées, sans pour autant être interchangeables. Une panne met les systèmes hors service. Une attaque met les systèmes hors service et corrompt les identifiants, les sauvegardes et l’annuaire sur lesquels la restauration serait effectuée. Une capacité de reprise conçue pour faire face à une attaque absorbe au passage les pannes ordinaires. Une capacité conçue uniquement pour les pannes ne permet pas de faire face à un attaquant de manière préparée.

C'est pourquoi nous avons conçu Argos99, notre plateforme d'intelligence de résilience, en nous concentrant sur les services métier plutôt que sur les actifs. La plateforme modélise en continu les services dont dépend l'organisation, les éléments dont dépend chaque service, la couverture de sauvegarde existante tout au long de la chaîne, la séquence de reprise dictée par ces dépendances, ainsi que la faisabilité des objectifs de reprise définis. Cela signifie que le modèle évolue au rythme des changements de l'environnement. L’identification des actifs est un problème résolu. Savoir ce qui doit être remis en service, dans quel ordre, et prouver que c’est possible, voilà le véritable défi que pose la reprise après sinistre.

Demandez la carte correspondant à un service

Prenez le service métier le plus stratégique pour votre chiffre d'affaires et exigez sa cartographie complète des dépendances, tiers compris. Si cette cartographie n'existe pas, aucun délai de reprise associé à ce service n'a de sens, car ce délai a été estimé sur la base d'une chaîne dont personne n'a pu visualiser l'ensemble, de bout en bout.

Pour être validée, une réponse doit franchir quatre barres :

• Tout est complet, depuis l'authentification jusqu'au réseau, en passant par l'infrastructure de sauvegarde et les intégrations externes auxquelles le service fait appel.
• Ces informations sont à jour et reflètent la situation actuelle, et non celle qui prévalait lors de l'examen architectural il y a deux ans.
• On peut s'en sortir ; ces données sont stockées dans un endroit qui n'est pas affecté par l'attaque.
• Ce document est structuré de manière à préciser non seulement les besoins du service, mais aussi l'ordre dans lequel il renvoie les données, ainsi que le temps nécessaire à chaque maillon du réseau, en se basant sur des mesures réelles de capacité de stockage et de bande passante, et non sur des hypothèses.

La plupart des organisations ne répondront à aucun de ces critères dès la première évaluation. Ce résultat n’a rien d’embarrassant. C’est au contraire la conclusion la plus utile qu’un programme de résilience puisse fournir ce trimestre, car chaque lacune identifiée sur la carte correspond à une semaine d’indisponibilité future détectée à un coût nul.

Consultez le rapport complet

Le rapport « The State of Recoverability 2026 » associe les données relatives aux sinistres d’Allianz, les études du Forum économique mondial, d’Accenture et de treize autres institutions aux données de terrain recueillies par Fenix24 lors de plus de 500 interventions concrètes de restauration après une attaque par ransomware, ce qui constitue la base d’expérience la plus complète au monde en matière de restauration. Si vous souhaitez comprendre ce qui détermine la durée d’indisponibilité d’une entreprise, voici les éléments qui le prouvent.

Cliquez ici pour télécharger le rapport 2026 de Fenix24 sur l'état de la recouvrabilité.