En 2024, les interruptions critiques chez les trois principaux fournisseurs de cloud public ont progressé de 18 %, pour un total de 221 heures de downtime cumulé (Parametrix Cloud Outage Report). Selon le Greyhound CIO Pulse 2025, les organisations avec plus de 60 % de workloads en cloud subissent 7,4 fois plus de pertes de revenus par heure de panne que celles en hybride ou on-premise.
Les réponses réglementaires avancent. Le Data Act impose aux fournisseurs cloud de faciliter le changement de prestataire. La loi SREN encadre les frais de transfert de données. L’Arcep pousse l’interopérabilité et la portabilité des services cloud. Le multicloud progresse, mais la promesse de portabilité reste largement illusoire : les interfaces de pilotage des hyperscalers (API, Terraform providers) sont incompatibles entre elles, et maintenir plusieurs versions d’infrastructure en parallèle est un gouffre de complexité. Pour autant, tout ça reste dans une logique d’atténuation : on réduit le coût de sortie, on diversifie les fournisseurs, mais on ne questionne pas la dépendance elle-même. La question opérationnelle est ailleurs : comment construire un SI qui intègre le cloud là où il apporte de la valeur, et qui continue de fonctionner quand le cloud s’arrête ?
C’est la question que pose l’approche robustesse. Nous avons posé ses fondements conceptuels et ses principes opérationnels dans deux articles précédents. Celui-ci est le mode d’emploi. Mais avant le comment, il faut comprendre ce qui rend le problème si difficile à traiter.
Comment devient-on dépendant à une infrastructure cloud ?
Le verrouillage cloud opère sur trois registres.
Le premier est cognitif. Une organisation dont les communications passent par Teams, les documents par SharePoint, les processus RH par un SaaS unique, a progressivement désappris à fonctionner autrement. Adoption, intégration, dépendance, atrophie. Elle ne s’en rend compte qu’au moment où ça casse. On appelle ça la dépendance au sentier.
Le deuxième est juridique et géopolitique. Le Cloud Act et la FISA 702 permettent aux agences américaines d’accéder aux données hébergées par AWS, Azure ou GCP, y compris sur des serveurs situés en Europe. Le Data Protection Framework négocié après l’arrêt Schrems.II a été partiellement fragilisé par les executive orders de janvier 2025. Et quand la géopolitique bascule, les conséquences sont immédiates : en 2022, après l’invasion de l’Ukraine, AWS et Azure ont suspendu leurs services en Russie. Des entreprises entières ont perdu l’accès à leurs données, leurs applications, leurs systèmes de production. Une décision politique, unilatérale, qu’aucun PRA n’avait modélisée.
Le troisième est technique et invisible. En 2024, l’ouragan Helene a inondé la mine de Spruce Pine en Caroline du Nord. Cette mine fournit la quasi-totalité du quartz ultra-pur nécessaire à la fabrication des semi-conducteurs, ceux-là mêmes qui font tourner les serveurs des datacenters cloud. Pendant quelques semaines, toute la chaîne d’approvisionnement du cloud mondial dépendait d’un site dont la plupart des DSI ignoraient l’existence.
Qu’est-ce qu’ « autonomie stratégique du SI » veut dire en pratique ?
Le Cigref définit l’autonomie stratégique numérique comme la capacité à maîtriser ses risques, conserver une marge de manœuvre et ne pas laisser des positions dominantes freiner l’innovation. Au niveau d’un SI, ça se traduit par trois questions.
- Combien de temps pour migrer un service critique vers un autre fournisseur cloud ? Si la réponse est « plusieurs années », la marge de manœuvre est théorique. Un repère raisonnable : moins de six mois, à calibrer selon la criticité.
- Combien de temps vos processus vitaux tiennent en mode dégradé sans cloud ? La plupart des organisations que nous accompagnons ne l’ont jamais mesuré.
- Est-ce que vos équipes savent encore faire tourner les alternatives, ou est-ce que cette compétence est partie avec le dernier prestataire ?
L’enjeu, c’est que le cloud reste un choix, et que ce choix puisse évoluer sans que ça paralyse l’organisation.
Avant de commencer : tout usage Numérique ne mérite pas d’être rendu robuste
Rendre un SI robuste a un coût. Redondance, compétences maintenues, marges conservées. Appliquer cette logique à tous les services numériques serait absurde.
Nous utilisons un filtre, parfois difficile à nommer : bien commun, raison d’être de l’organisation ou simplement valeur d’usage. (article complet ICI)
Un service cloud qui gère l’attribution de logements sociaux mérite une robustesse maximale. Un outil de reporting interne hébergé en SaaS peut tolérer plusieurs jours d’indisponibilité. Un chatbot IA déployé à la hâte sur un service public, sans alternative humaine, pose une question d’un autre ordre : faut-il le rendre robuste, ou faut-il d’abord se demander s’il devrait exister sous cette forme ?
Un test simple avant d’investir dans la robustesse d’un service. Le projet répond-il à un besoin défini, utile à long terme, aligné avec la raison d’être de l’organisation ? Le numérique est-il la réponse la plus adaptée ? Un fonctionnement plus simple serait-il envisageable ?
Ce filtre posé, voici les six leviers qui construisent l’autonomie stratégique. Les deux premiers (autonomie stratégique, résilience technique) agissent directement sur la dépendance cloud. Les quatre suivants (sobriété, low-technisation, gouvernance, acceptabilité) créent les conditions pour que l’autonomie tienne dans la durée.
Six leviers pour rendre votre SI plus robuste
1. Autonomie stratégique – réduire le verrouillage
Quand Broadcom rachète VMware, les licences perpétuelles disparaissent et les tarifs augmentent de 300 à 500 % selon le Cigref. Résultat : des organisations migrent en urgence vers le cloud public pour fuir les coûts VMware, ce qui renforce leur dépendance aux hyperscalers. Le verrouillage crée du verrouillage.
Le levier commence par une matrice de dépendance brique par brique : pour chaque composant du SI, quel est le fournisseur, existe-t-il un équivalent ouvert, quel est le coût de sortie ? La réponse dépend de la nature du verrouillage. Si c’est une dépendance géopolitique (données chez un hyperscaler soumis au Cloud Act), migrer vers un fournisseur européen peut suffire. Si c’est une dépendance économique à un éditeur en situation de monopole (VMware, Oracle), changer de fournisseur ne résout rien – il faut changer de technologie. Si c’est une dépendance à un logiciel propriétaire sans équivalent, le recours à un commun numérique (logiciel libre maintenu par une communauté industrielle) est souvent la seule sortie durable. L’affaire XZ Utils en 2024 l’a rappelé : un logiciel open source maintenu par une seule personne reste fragile. La solidité vient de la communauté qui contribue, pas du seul fait que le code soit ouvert.
Containeriser pour devenir agnostique de l’infrastructure cloud. Docker, Kubernetes. C’est ce que fait Action Logement pour pouvoir basculer entre fournisseurs cloud sans réécrire les applications. Effort : un sprint d’architecture pour les applications prioritaires.
Limiter le PaaS propriétaire. Les services managés d’AWS, Azure, GCP créent du lock-in invisible via des API non standard. Chaque service managé adopté est un coût de sortie supplémentaire. Privilégier les équivalents open source quand ils existent (PostgreSQL plutôt que Aurora, Redis plutôt que ElastiCache). Attention cependant : utiliser une brique standard ne suffit pas. Les outils de provisioning, de configuration, de monitoring qui entourent cette brique sont rarement interopérables d’un cloud à l’autre. C’est souvent dans cette couche d’intégration, pas dans le logiciel lui-même, que le verrouillage se joue.
Préparer la sortie dès l’entrée. Clauses de réversibilité systématiques dans les cahiers des charges. Escrow management (mise en séquestre du code source chez un tiers de confiance) pour les SaaS et ERP critiques. L’objectif est un score de verrouillage inférieur à 5 sur 10 pour chaque service vital.
Effort global : 3 à 5 jours pour la matrice initiale avec l’équipe architecture. Gain : une photo claire de votre liberté de mouvement, et un plan de déverrouillage priorisé.
2. Résilience technique – tenir quand ça tombe
En atelier FluctuIT, on pose une question simple : « votre cloud principal est indisponible pendant une semaine, quels services continuent de fonctionner ? » Silence. Un DSI sort son tableau de dépendances. 14 lignes rouges sur 18. Un autre cherche la date du dernier test de son ERP en mode dégradé. Cinq ans.
Architecture hybride par criticité. Répartition adaptée au contexte : 70 % sur un cloud principal, 20 % sur un cloud de secours, 10 % en local pour le plus sensible. Le multi-cloud modulaire (on-prem pour les services vitaux, cloud public pour le reste) isole les incidents. Découpler les macroprocessus via API et files d’attente réduit l’effet domino : si la facturation tombe, les commandes continuent d’entrer.
Sous-optimalité volontaire. Sur l’infrastructure que vous maîtrisez (on-prem, IaaS), maintenir un taux d’occupation maximal autour de 70 % en nominal. Ce jeu absorbe les pics imprévus. Redondance sélective sur les services de la zone critique, avec sauvegardes sur des sites physiquement séparés (la leçon OVHcloud Strasbourg, 2021 : sauvegardes et production brûlaient au même endroit).
Faire du mode dégradé une fonctionnalité. Dans la culture IT dominante, le mode dégradé est un aveu d’échec. L’approche robustesse inverse la logique : défini à l’avance, testé régulièrement, accepté par les métiers. Contractualiser les niveaux de service en situation de crise. Un guide opérationnel « panne M365 » avec des procédures alternatives, un PRA pragmatique priorisé par criticité, des exercices de bascule trimestriels. Du chaos engineering limité sur un ou deux systèmes non critiques pour vérifier que les bascules fonctionnent autrement que sur un diaporama.
Effort global : cartographie des interdépendances en 2-4 semaines. Architecture hybride sur 6-12 mois. Tests de bascule : une demi-journée par trimestre.
3. Sobriété et frugalité – consommer moins, dépendre moins
Chiffres ADEME (janvier 2026) : les usages numériques français consomment 10 TWh en France et 14 TWh à l’étranger, sur les infrastructures cloud des hyperscalers. Scénario tendanciel : x3,7 d’ici 2035, les deux tiers de la hausse à l’étranger, dans des pays aux mix électriques carbonés. Chaque workload déporté dans le cloud, c’est de la dépendance énergétique qui s’ajoute à la dépendance technique.
Le levier ici, c’est de passer du FinOps (optimiser la facture cloud) au GreenOps : piloter conjointement coûts, consommation et empreinte carbone des services cloud. Les deux ne vont pas toujours ensemble : un serveur spot en Pologne coûte moins cher, mais le mix électrique polonais émet plus de dix fois plus de CO2 par kWh que le français.
Right-sizing et quotas. Fixer des plafonds de compute et de stockage par projet. Dimensionner les instances cloud sur la consommation réelle, pas sur le pic théorique. VDI quand le poste lourd ne se justifie pas. Gain typique : 15 à 30 % sur la facture cloud.
On/Off et nettoyage. Programmer l’extinction des environnements cloud hors production (dev, test, staging qui tournent 24h/24 pour rien). Nettoyer les données ROT (redondantes, obsolètes, triviales). Décommissionner les SaaS et services cloud que plus personne n’utilise.
Effort : le right-sizing est un quick win à un sprint. Le nettoyage ROT prend plus de temps (gouvernance de données) mais chaque téraoctet supprimé allège la facture et la dépendance.
4. Low-technisation – justifier la complexité avant de l’adopter
En 2024, plusieurs hôpitaux ont perdu simultanément l’accès à leurs applications cloud et à leurs serveurs locaux après des attaques par ransomware. Ceux qui avaient préparé des procédures papier de secours ont tenu. Les autres ont improvisé dans le chaos.
Le Cigref parle de « techno-discernement ». L’idée : est-ce que ce workflow a besoin de sept micro-services cloud interconnectés, ou est-ce qu’un tableur partagé fait le travail ? Est-ce que cette application doit fonctionner uniquement en ligne sur un SaaS, ou peut-elle prévoir un mode hors-ligne avec synchronisation différée ? Chaque service cloud supprimé est une dépendance en moins à gérer.
En pratique : maintenir des procédures papier testées (pas un classeur poussiéreux) pour les processus critiques, en cas de panne cloud prolongée. Concevoir un PCA low-tech avec des plages horaires de fonctionnement des services numériques en cas de contrainte énergétique. Privilégier les OS allégés pour les postes qui n’ont besoin que d’un navigateur.
Effort : une demi-journée d’audit de complexité par service critique. Combien de fonctionnalités réellement utilisées, combien de dépendances cloud, combien de personnes comprennent le fonctionnement.
Si plus de la moitié des fonctionnalités sont inutilisées ou si personne ne sait faire tourner le service sans son fournisseur cloud : complexité à traiter.
5. Gouvernance et compétences – décider vite quand ça dérape
En 2018, la banque TSB rate sa migration IT et prive 1,9 million de clients de l’accès à leurs comptes pendant des semaines. Les compétences critiques avaient été entièrement déléguées à un prestataire. La gouvernance de crise n’existait que dans un classeur.
Un RACI de crise clair. Des boucles de pilotage courtes intégrant budget carbone et indicateurs de continuité. Contenir le nombre d’outils cloud et urbaniser le SI : chaque SaaS adopté hors gouvernance DSI est une dépendance non cartographiée, un fournisseur cloud de plus sans clause de réversibilité. Développer le recouvrement de compétences entre équipes (SecOps, FinOps, Data) pour ne pas être nu quand le prestataire cloud part. Et pour les organisations qui utilisent de l’IA en cloud : gouvernance frugale avec audits d’usage et contrôle des biais.
Effort : le RACI de crise se fait en une journée. Le recouvrement de compétences est un chantier RH de fond (6-12 mois).
6. Acceptabilité sociale – préparer les usagers au mode dégradé
Un service public 100 % dématérialisé, hébergé en cloud, qui tombe : ce sont des citoyens qui perdent l’accès à leurs droits. Point.
- Maintenir des canaux alternatifs (guichet, téléphone, courrier) pour les publics éloignés du numérique.
- Préparer une communication de crise proactive : messages prêts, canaux identifiés, porte-parole désignés.
- Corriger en priorité le top 10 % des écarts RGAA sur les services les plus utilisés.
- Et co-construire les priorités de mode dégradé avec les usagers eux-mêmes.
Dans un atelier FluctuIT récent, les locataires d’un bailleur social ont priorisé très différemment des équipes IT. Ce décalage, mieux vaut le découvrir en atelier qu’en crise.
Effort : la communication de crise se prépare en 2-3 jours. L’audit RGAA ciblé en une semaine. La co-construction avec les usagers : un atelier de 3 heures qui change la perspective.
Pourquoi ça avance mieux quand on parle de risque
« On ne peut pas mettre la robustesse SI à l’ordre du jour du Comex, c’est trop technique. »
Pour autant, « éviter un CrowdStrike chez nous » ou “assurer notre souveraineté numérique / autonomie stratégique” parle à tout le monde. « Sécuriser nos approvisionnements face aux tensions sur les composants » passe en comité stratégique. La robustesse est un cheval de Troie pour les enjeux de soutenabilité : elle les traduit dans le langage du risque opérationnel. Et dans les faits, réduire la dépendance cloud force à simplifier le SI, ce qui réduit aussi l’empreinte. Le cercle est vertueux, même s’il ne résout pas tout.
Reste la question de fond : qu’est-ce qui fait basculer une direction ? Le rapport RSE qu’elle n’a (presque) pas lu, ou l’incident cloud qu’elle a subi ?
Les organisations qui commencent maintenant intègrent ces principes à coût maîtrisé. Les autres attendront la prochaine panne.Si votre dépendance vous inquiète, on en parle.
Sources :
- Cloud Outage Risk Report 2024 – Parametrix, mars 2025
- Prospective d’évolution des consommations des data centers de 2024 à 2060 – ADEME 2026
- Recommandation interopérabilité et portabilité des services cloud – Arcep, septembre 2025
- L’approche low-tech au service de la résilience numérique des organisations – Cigref, février 2026
Laisser un commentaire