Le 26 septembre 2025, une batterie lithium-ion prend feu dans le datacenter gouvernemental de Daejeon, en Corée du Sud. En quelques heures, 647 services publics tombent. Le numéro d’urgence, le site des impôts, l’authentification des citoyens, le système postal : tout s’arrête. Les 125 000 fonctionnaires qui stockaient leurs documents sur le cloud gouvernemental découvrent que le système n’avait aucune sauvegarde externalisée. 858 téraoctets de données perdus. Définitivement.
Trois mois plus tôt, une mise à jour défectueuse de CrowdStrike avait paralysé 8,5 millions de machines Windows à travers le monde. Des hôpitaux ont reporté des opérations, des aéroports ont fermé leurs guichets, des banques ont suspendu leurs transactions. Coût estimé pour les seules entreprises du Fortune 500 : 5,4 milliards de dollars, selon l’assureur Parametrix.
Ces deux événements n’ont rien d’exceptionnel. Ils sont le symptôme d’une fragilité structurelle que la plupart des organisations ignorent jusqu’au jour où elle se manifeste. Cet article décrit ce que nous entendons par robustesse du SI, et comment nous aidons les DSI à la construire concrètement.
Des systèmes d’information conçus pour un monde stable
La majorité des SI d’entreprise reposent sur une hypothèse implicite : les ressources sont disponibles, les fournisseurs livrent, l’énergie coule, les réseaux fonctionnent. Toute l’architecture est optimisée autour de cette hypothèse. On mutualise pour réduire les coûts, on centralise pour simplifier, on externalise pour gagner en flexibilité. Quand le monde coopère, ça marche très bien.
Le problème, c’est que le monde coopère de moins en moins.
Les tensions sur les semi-conducteurs ont rappelé que les composants ne sont pas un flux garanti. Le rachat de VMware par Broadcom a montré qu’un éditeur peut, du jour au lendemain, multiplier ses tarifs par cinq et réduire ses canaux de distribution. La panne CrowdStrike a prouvé qu’un seul fournisseur de sécurité peut immobiliser une partie du tissu économique mondial en 79 minutes. Et Daejeon a illustré ce qui se passe quand un gouvernement entier dépend d’un unique point de stockage sans plan B.
Chacun de ces événements, pris isolément, ressemble à un accident. Mis bout à bout, ils dessinent un schéma : nos SI sont optimisés pour la performance, pas pour l’incertitude. La performance fragilise. C’est une loi de la biologie que le chercheur Olivier Hamant rappelle dans ses travaux : les systèmes les plus optimisés sont aussi les plus vulnérables aux perturbations.
Deux principes, une boussole
Chez Nuageo, la robustesse va bien au-delà d’un catalogue de bonnes pratiques de continuité d’activité. Nous la concevons comme un cadre de pensée qui repose sur deux principes hiérarchisés.
Le premier : la non-régression technologique. Le numérique doit renforcer les capacités existantes d’une organisation, jamais les remplacer au point de créer une dépendance irréversible. Le test est simple : si l’outil numérique disparaît demain matin, l’organisation se retrouve-t-elle en pire posture qu’avant son adoption ? Si oui, il y a régression. Daejeon est un cas d’école. Les fonctionnaires coréens avaient reçu la consigne de tout stocker sur le cloud gouvernemental plutôt que sur leurs postes. Le cloud a brûlé. Plus rien.
Le second principe est subsidiaire : la résilience contrainte. Quand le recours au numérique est inévitable (et il l’est souvent), il faut intégrer la capacité de résistance dès la conception. Pas en ajoutant une couche de PRA après coup, mais en concevant le système pour fonctionner en mode réduit quand les conditions se dégradent.
Cette hiérarchie compte. On commence par se demander si on a vraiment besoin de cette brique numérique. Si la réponse est oui, on s’assure qu’elle ne deviendra pas un point de fragilité.
Diagnostiquer avant de transformer
La plupart des DSI que nous accompagnons n’ont pas une vision claire des fragilités de leur SI. Pas par négligence. Par manque d’outil et de méthode pour poser le sujet.
C’est pour ça que nous avons conçu Fluctu’IT.
Fluctu’IT est un atelier collaboratif d’une heure trente à deux heures qui réunit les équipes métiers et IT autour de scénarios concrets de perturbation. On ne parle pas de risques abstraits. On simule : votre fournisseur cloud principal est indisponible pendant 72 heures, que se passe-t-il ? Votre prestataire ERP double ses tarifs au renouvellement, quelles sont vos options ? Un incident de cybersécurité vous coupe l’accès à votre messagerie et à vos fichiers partagés pendant une semaine, comment fonctionne l’entreprise ?
Ce que l’atelier met en évidence, en général, surprend. Les participants constatent la concentration de dépendances autour d’un ou deux fournisseurs. Ils découvrent que certains processus critiques reposent sur une seule personne qui connaît le système (le fameux « facteur de bus »). Ils se rendent compte que le PRA, quand il existe, n’a pas été testé depuis trois ans.
Fluctu’IT ne produit pas un rapport de 80 pages. Il produit une cartographie partagée des fragilités, une liste d’actions prioritaires, et surtout une prise de conscience collective. C’est la porte d’entrée de la démarche.
Construire la robustesse, pas la décréter
Après le diagnostic, le travail commence. Notre approche suit cinq étapes, adaptées au contexte et à la maturité de chaque organisation.
- Mobiliser d’abord. Sans adhésion des équipes, aucune transformation ne tient. Les ateliers Fluctu’IT et Robustesse par Conception servent à ça : mettre les gens autour de la table, leur faire toucher du doigt les fragilités, et construire ensemble l’envie d’agir. « Robustesse par Conception » va plus loin que Fluctu’IT : on y travaille en sprints de crise cumulatifs, avec un exercice prospectif (« Carte postale 2030 ») pour ancrer la démarche dans un horizon désirable.
- Diagnostiquer ensuite, de façon plus structurée. On évalue la maturité sur six leviers opérationnels : l’autonomie stratégique (dépendance fournisseurs, réversibilité), la sobriété (surface applicative, dark data, dimensionnement des infrastructures), la low-technisation (complexité réelle vs complexité nécessaire), la résilience technique (modes dégradés, PRA, tests), la gouvernance et les compétences (facteur de bus, documentation, binômes), et l’acceptabilité sociale (les utilisateurs sont-ils prêts à fonctionner autrement quand la situation l’exige ?).
- Transformer, c’est passer aux actes. Modulariser l’architecture, diversifier les fournisseurs sur les briques critiques, définir et tester des modes dégradés pour les services vitaux, documenter ce qui ne l’est pas. On ne parle pas de tout refaire. On parle de restaurer des marges de manœuvre là où elles ont été supprimées au nom de l’optimisation.
- Piloter signifie inscrire la robustesse dans la durée. Intégrer des indicateurs de robustesse aux côtés des indicateurs de performance et de coût dans les comités d’architecture et les arbitrages budgétaires. Anticiper les effets domino avant qu’ils ne se produisent.
- Approfondir, enfin, pour les organisations qui veulent aller plus loin : planification de réponse aux incidents, gouvernance de crise, plan de continuité d’activité réévalué à l’aune des nouvelles menaces.
L’intelligence artificielle s’invite dans cette réflexion. Les services d’IA générative (ChatGPT, Copilot, Gemini) créent de nouvelles dépendances, parfois sans que la DSI en ait pleinement conscience. On cadre les usages, on mesure l’empreinte, et surtout on se pose la question : que se passe-t-il si ce service devient indisponible ou trop cher ? C’est un volet transversal de notre accompagnement.
Le bon moment, c’est avant la crise
Cinq questions suffisent pour estimer où vous en êtes. Combien de fournisseurs représentent plus de 50 % de votre budget SI ? Quand avez-vous réellement testé votre PRA pour la dernière fois ? Combien de personnes peuvent intervenir en urgence sur votre ERP ? Avez-vous une procédure documentée en cas de panne de Microsoft 365 ? Quel pourcentage de vos services vitaux dispose d’un mode dégradé défini et testé ?
Si trois de ces réponses vous mettent mal à l’aise, ce n’est pas un problème. C’est un point de départ.
Notre conviction, chez Nuageo, c’est que la robustesse est le prix de la viabilité. Les entreprises qui investissent dans leur capacité d’adaptation ne le font pas par précaution morale : elles le font parce qu’elles ont compris que dans un monde où les crises se superposent, l’optimisation sans marge est un pari perdant. La finalité de cette démarche, au fond, c’est d’équilibrer la recherche de performance en acceptant une part de sous-optimisation. Perdre quelques points de rendement pour gagner la capacité de continuer à fonctionner quand les conditions se dégradent. Ça ressemble à un renoncement. C’est peut-être juste de l’arithmétique.
Sources :
- CIO Online, « CrowdStrike 9 mois après : les leçons d’une panne majeure », 2025
- LeMagIT, « Datacenters en feu : le gouvernement coréen a lui aussi négligé les sauvegardes », octobre 2025
- DCmag, « Un incendie majeur lié à une batterie lithium-ion a paralysé le datacenter de l’état de Corée du Sud », septembre 2025
- Parametrix, estimation des coûts de la panne CrowdStrike pour les entreprises Fortune 500
- Olivier Hamant, Antidote au culte de la performance, Gallimard, 2024
- CIGREF / INR, « L’approche low-tech au service de la résilience numérique des organisations », février 2026
Testez votre niveau de robustesse : autodiagnostic gratuit →
Laisser un commentaire