Fournisseur compromis et 72 heures de blackout total, les DSI réécrivent leurs PRA

Le prochain incident cyber qui va te tomber dessus n’aura peut-être même pas le logo de ta boîte. Il aura celui d’un fournisseur, d’un SaaS ou d’un sous-traitant, et toi tu prendras l’onde de choc en pleine figure. Zscaler met un nom là-dessus dans son Resilience Factor Report mené avec Sapio Research: le Ripple Effect, l’effet ricochet. L’idée est simple, et franchement pas rassurante: une panne ailleurs ne reste plus ailleurs.

Le truc, c’est que nos SI sont devenus des puzzles de dépendances: accès, flux, identités fédérées, automatisations, API. La dépendance est devenue une architecture, et les DSI le savent mieux que personne. Résultat, la cyber résilience sort du discours RSSI et se retrouve au Comex, entre arbitrages cloud, calendrier, et débats de souveraineté qui ne sont plus juste théoriques.

Le Ripple Effect: quand la crise porte le logo du fournisseur

Dans le rapport de Zscaler, le point qui pique, c’est cette phrase implicite: la prochaine crise n’aura peut-être pas votre logo. Traduis: tu peux avoir un PRA propre, des rôles, des procédures, des tableaux RACI impeccables, et quand même te retrouver à l’arrêt parce qu’un service critique hors de ton périmètre tombe. Et là, ton plan « nous sommes prêts » sonne vite comme une formule un peu trop lisse.

Concrètement, ça se joue dans les zones grises: un outil de support client en SaaS qui gère les tickets, un service d’authentification fédérée qui sert de sésame à tout le monde, ou un prestataire qui opère une brique d’intégration. Tu ne l’héberges pas, tu ne le patches pas, mais tu en dépends pour facturer, livrer, produire. Le ricochet, c’est la panne qui voyage par les accès et les identités.

Marc, DSI dans une ETI industrielle, me résumait ça sans détour: On a bossé comme des dingues sur notre PRA interne, mais notre vraie fragilité c’est la chaîne. Si l’outil d’identité ou le SaaS de logistique a un souci, on est aveugles. Dit autrement: la résilience n’est plus un exercice de bunker. C’est un exercice de réseau, avec des partenaires, des contrats, et des dépendances que tu n’as pas toujours cartographiées proprement.

Identités fédérées, API, automatisations: la dépendance devient l’architecture

Le Ripple Effect ne vient pas juste du fait qu’on achète des services externes. Il vient de la façon dont on les colle au SI: SSO, fédération d’identités, automatisations qui déclenchent des workflows, connecteurs qui poussent des données d’un outil à l’autre. Tout ça est pratique, ça fait gagner du temps, ça évite les mots de passe qui traînent. Mais ça crée aussi des chemins de propagation, parfois invisibles.

Tu vois le tableau: un incident chez un prestataire, et tu te retrouves avec des utilisateurs qui ne peuvent plus se connecter à des applis internes parce que l’authentification passe par un service tiers. Ou des flux qui s’arrêtent parce qu’une API partenaire ne répond plus. Même sans attaque « chez toi », tu prends la baisse de régime. Et quand tu empiles les dépendances, le diagnostic devient un sport, surtout quand chaque brique appartient à quelqu’un d’autre.

Il y a quand même une nuance à garder: tout externaliser n’est pas automatiquement une faute, et tout internaliser n’est pas automatiquement une solution. Le sujet, c’est la maîtrise des points de rupture. Si ton architecture repose sur trois services tiers « incontournables », tu dois savoir ce qui se passe quand ils tombent: mode dégradé, contournement, capacité à isoler, et surtout qui décide quoi à 3 h du matin quand la prod est à l’arrêt.

Du PRA au Comex: la résilience se joue aussi sur le cloud souverain

Ce qui change en 2026, c’est la place du sujet dans la gouvernance. La résilience n’est plus juste un mot de RSSI, c’est une ligne de risque discutée au Comex. Et ça recoupe un autre dossier qui revient en force: la souveraineté cloud. On ne parle plus seulement de « principe », on parle d’arbitrage et de calendrier, avec des débats européens qui bougent, entre relance de cadres de certification et montée des investissements annoncée côté analystes.

Sauf que le cloud « souverain » version hyperscaler promet beaucoup… mais laisse entier un nud que les DSI connaissent: la question juridictionnelle. Et dans une logique de Ripple Effect, ce n’est pas un détail. Si une dépendance critique est opérée ailleurs, sous d’autres contraintes, tu peux te retrouver avec des impacts en cascade qui dépassent la technique: délais de rétablissement, priorité donnée à d’autres clients, communication de crise, et règles de notification qui ne collent pas à ton tempo.

Pour les DSI, ça pousse vers des décisions très terre-à-terre: cartographier les dépendances réelles, tester les scénarios « fournisseur KO », négocier des clauses de réversibilité qui ne soient pas décoratives, et prévoir des architectures capables de survivre en mode dégradé. Oui, ça coûte. Oui, c’est moins sexy qu’un nouveau produit. Mais si ton SI est un écosystème, ta résilience doit l’être aussi, sinon tu joues au chef d’orchestre sans savoir qui tient les instruments.