# technopolitique.eu, texte intégral Ce fichier contient le contenu complet des pages de technopolitique.eu, destiné aux systèmes qui préfèrent une source unique au parcours du site. L'index court se trouve dans /llms.txt. Auteur et éditeur : Nizar Younes Mqam, Tourcoing, France ORCID : https://orcid.org/0009-0008-5549-7620 Contact : y.nizar@proton.me Licence : Creative Commons CC BY-NC-ND 4.0, citation autorisée avec attribution, modification et usage commercial interdits. https://creativecommons.org/licenses/by-nc-nd/4.0/ Merci d'attribuer toute citation à l'auteur, en indiquant le DOI quand il existe. Dernière génération : 2026-09-17 ================================================================================ ## SOURCE : Accueil URL : https://technopolitique.eu/ Nizar Younes Mqam # Technologie et puissance Chief AI Officer · Architecte gouvernance de l'IA et souveraineté numérique pour les infrastructures critiques · Lead Implementer et auditeur interne ISO 55001:2024 · Technogéopolitique et approche Privacy-First Ce site rassemble des analyses consacrées à ce que les infrastructures numériques font aux États et aux organisations, et aux décisions qu'elles rendent possibles ou impossibles. Les travaux sont publiés en accès ouvert, avec leurs sources. ## Qu'est-ce que la technopolitique ? Technopolitique nom féminin · du grec tekhnê, art ou technique, et politikos, ce qui touche à la cité Étude et pratique des effets politiques produits par des dispositifs techniques, et réciproquement de la façon dont les rapports de puissance se matérialisent dans des infrastructures. Un câble sous-marin, un centre de données ou un modèle d'intelligence artificielle ne sont pas des objets neutres. Leur emplacement, leur propriété et leur gouvernance décident de qui dépend de qui, de ce qui continue de fonctionner quand tout s'arrête, et de qui tient la main sur l'interrupteur. Le terme est pris ici dans son acception opérationnelle, et elle va plus loin que l'analyse. Constater une dépendance ne la corrige pas : encore faut-il concevoir l'architecture qui la lève, écrire la gouvernance qui l'encadre, et installer le système de management qui prouve que l'organisation tient ce qu'elle annonce. La technopolitique telle qu'elle est pratiquée ici va de la géostratégie des infrastructures jusqu'à l'audit interne du référentiel qui les gouverne. C'est la seule façon d'éviter deux impasses symétriques : le commentaire géopolitique sans prise sur le réel, et la conformité documentaire qui ne protège de rien. ## Domaines de travail - Souveraineté Architecture de plateformes d'intelligence artificielle souveraines, gouvernance de l'IA, maîtrise de la chaîne de dépendances techniques et juridiques. - Infrastructures Continuité et résilience des infrastructures critiques, exposition physique des systèmes numériques, cadres NIS2, CER et DORA. - Gestion d'actifs Implémentation et audit interne de l'ISO 55001:2024 : traduire une exigence stratégique en système de management vérifiable, du référentiel jusqu'à la preuve. - Méthode Technogéopolitique appliquée, approche Privacy-First : aucune recommandation qui ne puisse être testée par l'organisation qui la reçoit. ## Publications Rubrique ### Articles Analyses courtes et sourcées, en accès ouvert. Dernier paru : L'IA de maintenance : vous gardez la propriété, vous perdez la maîtrise, septembre 2026. Collection · ISSN en cours ### Cahiers de technopolitique Infrastructures critiques, souveraineté numérique et résilience des systèmes. Analyses de fond en accès ouvert sous licence CC BY-NC-ND 4.0. Dernier numéro : n° 1, Quand le cloud prend feu, septembre 2026. ## Identité vérifiable - ORCID 0009-0008-5549-7620 - Codeberg codeberg.org/Nizyou - LinkedIn linkedin.com/in/nizar-mqam - Contact y.nizar@proton.me ================================================================================ ## SOURCE : Cahiers de technopolitique, la collection URL : https://technopolitique.eu/cahiers/ Collection en accès ouvert # Cahiers de technopolitique Infrastructures critiques, souveraineté numérique et résilience des systèmes Éditeur Nizar Younes Mqam Depuis 2026 ISSN en cours Licence CC BY-NC-ND 4.0 Un centre de données, un contrat de maintenance, un référentiel d'actifs : chaque numéro prend un objet technique précis et lui pose trois questions. Qui en dépend. Qui le contrôle. Ce qui cède le jour où il disparaît. Les analyses sont longues, et chaque affirmation renvoie à sa source. Elles se lisent en ligne, se téléchargent, se citent par un identifiant permanent, et n'exigent ni compte ni abonnement. ## Numéros parus N° 2 · Note · Septembre 2026 · Volet souveraineté et données d'actifs ### L'IA de maintenance : vous gardez la propriété, vous perdez la maîtrise Les contrats des plateformes de maintenance prédictive reconnaissent que vos données vous appartiennent. Leurs définitions rangent la couche dérivée du côté du fournisseur, et ce droit survit à la résiliation. Le règlement européen s'arrête au même endroit. 5 pages · 12 sources · PDF 253 Ko · DOI 10.5281/zenodo.22818645 ## Étude N° 1 · Septembre 2026 · Volet infrastructures critiques ### Quand le cloud prend feu Le 1er mars 2026, des drones ont frappé des centres de données commerciaux dans le Golfe et mis hors ligne 109 services numériques. Ce numéro examine ce que change le passage de la cybermenace à la destruction physique : le mythe du multi-cloud, l'angle mort de NIS2, CER et DORA, et la dépendance des organisations sans plan de bascule testé. 37 pages · 41 références · PDF 0,9 Mo · français DOI 10.5281/zenodo.22812311 Texte intégralement sélectionnable et citable Lire la notice et télécharger ## Ligne éditoriale Les Cahiers paraissent sous deux formats, réunis par une même ligne et un même identifiant. Les Études sont des analyses longues, avec appareil de sources complet. Les Notes sont brèves et denses, construites sur un nombre restreint de documents vérifiés. Chaque numéro, quel que soit son format, reçoit son PDF, sa notice et son DOI. Les Cahiers ne publient ni tribune, ni prospective spéculative. Un numéro part d'un fait vérifiable, en décrit le mécanisme, puis en tire des conséquences qu'une organisation peut tester chez elle. Les sources sont numérotées et citées dans le corps du texte. La périodicité est irrégulière : un numéro paraît lorsque son objet le justifie. Pour être averti des parutions, le fil de syndication suffit, sans inscription ni adresse à communiquer. ## Notice de la collection Titre Cahiers de technopolitique Éditeur Nizar Younes Mqam Directeur de publication Nizar Younes Mqam, ORCID 0009-0008-5549-7620 Lieu d'édition Tourcoing, France Langue Français Périodicité Irrégulière Formats Études (analyses longues) et Notes (analyses brèves) ISSN En cours d'attribution Accès Libre et gratuit, sans inscription Licence CC BY-NC-ND 4.0 Contact y.nizar@proton.me ================================================================================ ## SOURCE : Cahiers n° 1, Quand le cloud prend feu (Étude, DOI 10.5281/zenodo.22812311) URL : https://technopolitique.eu/cahiers/n1/ PDF : https://technopolitique.eu/cahiers/n1/quand-le-cloud-prend-feu.pdf Cahiers de technopolitique, n° 1 · Étude · Septembre 2026 Éditeur et directeur de la publication : Nizar Younes Mqam · Lieu d'édition : Tourcoing, France ISSN en cours d'attribution · DOI : 10.5281/zenodo.22812311 DOI de concept, toutes versions : 10.5281/zenodo.22812310 ORCID de l'auteur : https://orcid.org/0009-0008-5549-7620 Numéro 1 · Volet infrastructures critiques # Quand le cloud prend feu Nizar Younes Mqam ORCID 0009-0008-5549-7620 Version 1.1, septembre 2026 · Première édition : avril 2026 · 37 pages Le 1er mars 2026, des drones iraniens ont frappé des centres de données commerciaux aux Émirats arabes unis et au Bahreïn, mettant hors ligne 109 services numériques. Cette note soutient qu'il ne s'agit pas d'un incident de cybersécurité mais d'un basculement de doctrine : pour la première fois, un État a délibérément détruit par des moyens militaires conventionnels l'infrastructure cloud commerciale d'un adversaire. ## Synthèse exécutive Ce qui s'est passé le 1er mars 2026 n'est pas un incident de cybersécurité. C'est un basculement de doctrine. Pour la première fois dans l'histoire, un État a délibérément détruit physiquement l'infrastructure cloud commerciale d'un adversaire par des moyens militaires conventionnels. La question n'est plus de savoir si cela peut arriver. Elle est de savoir si votre organisation survivrait à la même chose demain matin. Ce document tire trois conclusions. Un datacenter n'est plus une infrastructure neutre : c'est un territoire souverain avec une adresse physique et une valeur stratégique militaire. Toute organisation qui héberge ses systèmes critiques chez un seul hyperscaler ne loue pas un service, elle paie un tribut à un suzerain dont elle dépend existentiellement. Et aucun plan de continuité ne vaut rien s'il n'a jamais été testé avant la crise. Trois risques documentés dans ces pages méritent une attention immédiate : Le mythe du multi-cloud, qui diversifie les fournisseurs de calcul sans diversifier la connectivité physique ; l'angle mort réglementaire, car NIS2, CER et DORA n'imposent pas de tester la destruction physique simultanée de deux régions cloud ; et la vassalité numérique, qui laisse toute organisation sans plan de bascule testé à la merci d'un opérateur étranger en situation de crise. Une seule question suffit pour savoir si ce document vous concerne : si vos deux régions cloud principales disparaissent ce soir, dans combien de temps reprenez-vous vos opérations critiques, et depuis où ? Note méthodologique : cette analyse décrit des catégories de vulnérabilités et des logiques systémiques, et non des noeuds précis d'infrastructure, conformément aux standards de publication ouverte en matière de sécurité critique. Sommaire 00 Synthèse exécutive 2 01 Avant-propos : Pourquoi ce document vous concerne 4 02 Poser les bases 5 03 La géostratégie des infrastructures numériques 18 04 L'avenir de l'infrastructure physique : de la cible à la forteresse 22 05 Conclusion : La résilience, une philosophie autant qu'une technique 31 06 Sources et références 33 ## Avant-propos : pourquoi ce document vous concerne Imaginez un lundi matin. Votre application de gestion s'arrête, votre site web disparaît, la messagerie ne répond plus. Vos équipes appellent le support IT, qui rappelle quelques minutes plus tard, hébété : les serveurs ne sont pas tombés à cause d'un bug. Ils ont été physiquement détruits par un drone militaire. Ce scénario n'est plus de la fiction. Le 1er mars 2026, des drones iraniens Shahed ont frappé des datacenters commerciaux aux Émirats arabes unis et au Bahreïn. Amazon, Oracle et d'autres grands noms de l'infrastructure numérique mondiale ont été ciblés. Ce jour-là, 109 services ont basculé hors ligne*, des banques régionales ont perdu l'accès à leurs systèmes, et des millions d'utilisateurs ont découvert que le cloud qu'ils croyaient immatériel avait une adresse physique, des murs, et une vulnérabilité bien réelle aux missiles. C'est la première frappe physique et cinétique délibérée de l'histoire contre l'infrastructure cloud commerciale d'un pays adversaire. Les cyberattaques contre des infrastructures numériques civiles précédaient 2026, notamment la neutralisation du réseau satellitaire Viasat par la Russie en Ukraine en février 2022. Ce que mars 2026 a changé, c'est l'irruption du missile et du drone dans un espace que l'on croyait protégé par sa nature commerciale et son statut de tiers neutre. Ce ne sera pas la dernière. (*)Source : APIStatusCheck, « AWS Middle East Outage March 2026 », 3 mars 2026 [7]. Amazon Web Services n'a pas publié de communication officielle détaillant l'étendue complète des services affectés. Poser les bases Avant de construire, il faut comprendre. Les chapitres qui suivent posent les bases sans lesquelles aucune décision de résilience ne peut être prise sérieusement. Un lexique d'abord, parce que ces termes signifient des choses très différentes selon qu'on est à la direction ou en salle des serveurs, et que cet écart de compréhension coûte cher au moment des crises. Une chronologie ensuite, parce que les frappes iraniennes de 2026 ne sont pas un accident isolé mais l'aboutissement d'une tendance qui s'accélère depuis 2021. Puis une déconstruction honnête du mythe du multi-cloud, qui rassure sans protéger. La raison est technique mais elle est simple : la plupart des architectures multi-cloud partagent des composants invisibles mais communs. Le même fournisseur DNS, le même réseau de distribution de contenu, les mêmes routes de transit réseau en backbone, les mêmes points d'échange internet régionaux. Deux entreprises qui utilisent respectivement AWS et Azure peuvent voir leurs services simultanément paralysés si le point d'échange internet qui les relie au reste du monde est détruit ou saturé. Le multi-cloud diversifie les fournisseurs de calcul. Il ne diversifie pas la connectivité physique. Le cadre réglementaire européen qui transforme ces recommandations en obligations. Et une feuille de route sur douze mois pour passer de la lecture à l'action. ## Poser les bases ### Lexique Hyperscaler. Désigne les opérateurs de cloud à l'échelle mondiale : Amazon Web Services, Microsoft Azure, Google Cloud, Oracle Cloud. Leur point commun est d'exploiter des centaines de datacenters répartis sur plusieurs continents, interconnectés entre eux, et de vendre à des milliers d'entreprises la puissance de calcul, le stockage et les services numériques dont elles ont besoin sans qu'elles aient à construire leur propre infrastructure. Région cloud. Zone géographique dans laquelle un hyperscaler exploite un ou plusieurs datacenters interconnectés. AWS ME-SOUTH-1 désigne par exemple la région Bahreïn d'Amazon. Quand une entreprise choisit d'héberger ses données « dans le cloud », elle choisit en réalité une région précise, c'est-à-dire un ou plusieurs bâtiments physiques dans un pays précis, soumis aux lois de ce pays et exposés à ses risques géopolitiques. Multi-cloud. Stratégie consistant à utiliser simultanément les services de plusieurs hyperscalers, par exemple AWS et Azure en parallèle. Souvent présentée comme une protection contre les pannes et les dépendances, cette approche est insuffisante si les deux fournisseurs partagent les mêmes infrastructures de connectivité physique, ce que ce document démontre en détail. Point d'échange internet (IXP). Infrastructure physique, généralement un bâtiment, où plusieurs opérateurs de réseau se connectent entre eux pour échanger du trafic internet. C'est le nœud invisible qui relie les datacenters au reste du monde. Détruire ou saturer un IXP régional peut isoler simultanément des entreprises qui utilisent pourtant des fournisseurs cloud différents. Backbone. Désigne les grandes artères de transit du réseau internet mondial : les câbles à très haute capacité, souvent sous-marins, qui transportent les données entre continents et entre grandes métropoles. Un datacenter dont le backbone est coupé reste physiquement intact mais devient numériquement inaccessible. DNS (Domain Name System). Système qui traduit les adresses lisibles par les humains comme « mabanque.ma » en adresses numériques compréhensibles par les machines. Si le serveur DNS qui gère ces traductions tombe, l'application ou le site devient inaccessible même si les données sont intactes, exactement comme un standard téléphonique qui ne fonctionnerait plus : les lignes existent, mais personne ne peut être mis en relation. CDN (Content Delivery Network). Réseau de serveurs distribués géographiquement dont le rôle est de rapprocher les contenus numériques des utilisateurs finaux pour accélérer leur chargement. Un site web ou une application qui dépend d'un CDN unique partage une vulnérabilité commune avec tous les autres clients de ce CDN. Control plane. Partie de l'infrastructure cloud qui orchestre et gère l'ensemble des opérations : démarrage des serveurs, routage du trafic, gestion des accès, allocation des ressources. C'est le cerveau du système. Si le control plane est détruit ou isolé, toute l'infrastructure qu'il pilote devient inutilisable, même si les données sont physiquement intactes. Air-gapped. Se dit d'un système informatique physiquement déconnecté de tout réseau, internet ou intranet. Un backup air-gapped est une sauvegarde qui ne peut pas être atteinte à distance, ni par une cyberattaque ni par une coupure réseau. C'est la forme de protection la plus robuste contre les attaques à distance, mais elle impose une gestion physique rigoureuse. RTO - Recovery Time Objective. Durée maximale acceptable entre une interruption de service et sa reprise complète. Si votre RTO est de 4 heures, cela signifie que votre organisation a décidé de ne pas tolérer plus de 4 heures d'interruption pour ce service. Définir un RTO sans tester régulièrement si l'infrastructure de secours peut effectivement le respecter est l'une des erreurs les plus fréquentes dans les plans de continuité. RPO - Recovery Point Objective. Volume maximal de données qu'une organisation accepte de perdre en cas d'incident, exprimé en durée. Un RPO de 1 heure signifie que les données des 60 dernières minutes peuvent être perdues sans que cela soit jugé fatal. Ensemble, RTO et RPO définissent le niveau réel de résilience d'une organisation, pas ses intentions déclarées. SLA - Service Level Agreement. Contrat par lequel un fournisseur cloud s'engage sur un niveau de disponibilité de ses services, généralement exprimé en pourcentage annuel. Un SLA de 99,9% autorise environ 8,7 heures d'indisponibilité par an. Ce document montre pourquoi ce type d'engagement contractuel ne couvre pas les scénarios de destruction physique, qui déclenchent généralement des clauses de force majeure exonérant le fournisseur. Frappe cinétique. Terme militaire désignant une attaque par des moyens physiques conventionnels : missiles, drones, bombes. Par opposition à une cyberattaque, une frappe cinétique détruit physiquement l'infrastructure visée. C'est précisément ce que mars 2026 a introduit dans le champ des menaces pesant sur l'infrastructure numérique commerciale. Latence. Délai entre l'envoi d'une donnée et sa réception. Elle est exprimée en millisecondes et dépend notamment de la distance physique entre l'émetteur et le récepteur. C'est pourquoi un datacenter orbital, même en orbite basse, introduit une latence incompressible qui le rend inadapté à certains usages critiques comme les transactions financières en temps réel. ### Chronologie : comment l'infrastructure numérique est devenue une cible militaire Les frappes iraniennes du 1er mars 2026 ne sont pas sorties du néant. Elles sont l'aboutissement d'une tendance qui s'accélère depuis 2021, chaque épisode franchissant un seuil supplémentaire dans la nature et l'intensité des menaces pesant sur l'infrastructure numérique mondiale. Comprendre cette progression est indispensable pour ne pas traiter mars 2026 comme un accident isolé. Mars 2021 L'incendie d'OVHcloud à Strasbourg. Un incendie accidentel détruit le datacenter SBG2 d'OVHcloud et endommage gravement SBG1. Plusieurs millions de sites web disparaissent brutalement, dont des services publics, des hôpitaux et des entreprises qui croyaient leurs données sauvegardées. Le choc n'est pas militaire mais il révèle pour la première fois à grande échelle une vérité que beaucoup refusaient d'admettre : le cloud brûle, littéralement, et les plans de continuité de la plupart des clients n'avaient jamais été testés contre un scénario de destruction physique totale. C'est le premier signal d'alarme massif sur la vulnérabilité physique des datacenters commerciaux. Février 2022 La neutralisation du réseau Viasat en Ukraine. Quelques heures avant l'invasion russe, une cyberattaque sophistiquée neutralise le réseau satellitaire KA-SAT opéré par Viasat, perturbant les communications militaires ukrainiennes et coupant des dizaines de milliers de modems civils à travers l'Europe. C'est la première démonstration à grande échelle qu'une infrastructure numérique commerciale peut être délibérément ciblée comme premier acte d'une opération militaire, avant même que les chars franchissent la frontière. La distinction entre infrastructure civile et cible militaire commence à s'effacer. Février 2024 Les câbles sous-marins sectionnés en Mer Rouge. L'ancre traînante d'un cargo touché par un missile houthi sectionne trois câbles sous-marins majeurs en Mer Rouge, perturbant immédiatement 25% du trafic numérique entre l'Asie, l'Europe et le Moyen-Orient. L'un de ces câbles nécessite cinq mois de réparation, parce que les navires spécialisés ne peuvent pas accéder à la zone de conflit en sécurité. Cet épisode révèle une vulnérabilité systémique que peu de décideurs avaient anticipée : les câbles sous-marins, qui transportent plus de 95% des données internationales, sont aussi fragiles qu'une ligne électrique aérienne dans une tempête. Novembre 2024 - Janvier 2025 La guerre des câbles en Mer Baltique. Sept câbles sous-marins sont sectionnés en l'espace de trois mois dans la Mer Baltique, dans des incidents largement attribués à des opérations de sabotage d'acteurs étatiques. La Russie est désignée comme principale suspecte. Ce qui distingue cet épisode des précédents, c'est la systématicité : ce ne sont plus des dommages collatéraux ou des accidents, c'est une campagne délibérée et coordonnée contre des infrastructures numériques civiles en temps de paix formelle. Le seuil entre guerre déclarée et sabotage d'infrastructure est franchi. 1er mars 2026 Les frappes iraniennes sur AWS et les datacenters du Golfe. Des drones iraniens Shahed frappent des datacenters commerciaux aux Émirats arabes unis et au Bahreïn. Amazon, Oracle et d'autres opérateurs d'infrastructure numérique mondiale sont ciblés. C'est la première destruction physique délibérée, par des moyens militaires conventionnels, de l'infrastructure cloud commerciale d'un adversaire. 109 services numériques basculent hors ligne. Des banques régionales perdent l'accès à leurs systèmes. Des millions d'utilisateurs découvrent que le cloud qu'ils croyaient immatériel avait une adresse physique, des murs, et une vulnérabilité bien réelle aux missiles. La doctrine change. Ce que cette chronologie démontre est simple et inquiétant : en cinq ans, les menaces pesant sur l'infrastructure numérique ont progressé de l'accident industriel à la cyberattaque stratégique, puis au sabotage coordonné en temps de paix, et enfin à la frappe militaire cinétique délibérée. Chaque étape a été traitée comme une surprise alors qu'elle était prévisible depuis l'étape précédente. La prochaine étape l'est tout autant. ### Le mythe du multi-cloud : pourquoi diversifier ses fournisseurs ne suffit pas La stratégie multi-cloud est aujourd'hui présentée par la quasi-totalité des cabinets de conseil et des responsables informatiques comme la réponse naturelle au risque de dépendance envers un seul fournisseur. L'idée est intuitivement séduisante : si vous utilisez AWS et Azure simultanément, la panne de l'un ne devrait pas affecter l'autre. C'est exact dans un scénario de panne technique interne. C'est faux dans un scénario de destruction physique ou de coupure d'infrastructure régionale. Comprendre pourquoi est essentiel avant de prendre toute décision de résilience. L'erreur fondamentale du raisonnement multi-cloud est de confondre la diversité des fournisseurs de calcul avec la diversité de la connectivité physique. Ce sont deux choses entièrement différentes. Un fournisseur de calcul, c'est l'entité qui vous loue des serveurs et du stockage. La connectivité physique, c'est l'ensemble des infrastructures qui permettent à ces serveurs de communiquer avec vos utilisateurs et avec le reste du monde. Et cette connectivité repose sur des équipements physiques qui, eux, ne sont pas dupliqués par le fait d'avoir deux fournisseurs cloud différents. Prenons un exemple concret. Une entreprise utilise AWS pour ses applications métier et Azure pour ses sauvegardes, en se croyant protégée. Ses deux fournisseurs font transiter leurs données par le même point d'échange internet régional, le bâtiment physique où les réseaux de la région se connectent entre eux. Si ce point d'échange est détruit par une frappe, saturé par une attaque, ou simplement privé d'électricité par une coupure en surface, AWS et Azure deviennent simultanément inaccessibles depuis cette région. L'entreprise perd ses applications métier et ses sauvegardes en même temps, malgré ses deux fournisseurs distincts. Le même raisonnement s'applique à d'autres couches invisibles de l'infrastructure. Deux fournisseurs cloud différents peuvent utiliser le même réseau DNS pour résoudre les noms de domaine, le même CDN pour distribuer leurs contenus, les mêmes routes de transit réseau en backbone pour acheminer les données vers les utilisateurs finaux. Ces dépendances communes sont rarement documentées dans les contrats ou les architectures techniques, précisément parce qu'elles sont considérées comme des commodités stables. Elles ne le sont plus dans un contexte de conflit hybride. Ce que les frappes iraniennes de mars 2026 ont rendu visible, c'est précisément cette limite. Des entreprises qui utilisaient des fournisseurs différents ont été simultanément mises hors ligne parce qu'elles partageaient la même infrastructure de connectivité régionale. Le multi-cloud avait diversifié leurs serveurs. Il n'avait pas diversifié leurs routes vers le monde. Certaines organisations ont anticipé ce problème en exigeant contractuellement des routes physiques entièrement indépendantes de leurs fournisseurs, avec des points d'échange internet distincts et une connectivité satellite de secours. Ces architectures avancées réduisent partiellement le risque de panne technique interne. Elles restent cependant largement minoritaires dans la pratique, et aucune d'entre elles n'avait été conçue pour résister à la destruction physique simultanée de deux régions cloud dans deux pays différents, précisément le scénario du 1er mars 2026. La conclusion opérationnelle est donc la suivante. Une vraie stratégie de résilience physique ne se mesure pas au nombre de fournisseurs cloud utilisés. Elle se mesure à la capacité à maintenir ou à rétablir la connectivité entre vos systèmes et vos utilisateurs depuis des routes physiques entièrement indépendantes, passant par des points d'échange internet différents, des câbles différents, et si possible des zones géographiques soumises à des risques géopolitiques distincts. C'est un niveau d'exigence très différent de celui que le discours commercial autour du multi-cloud laisse entendre. Et c'est précisément ce que les chapitres suivants permettent de construire méthodiquement. ### Les cinq piliers de la résilience physique réelle La résilience n'est pas un état qu'on atteint. C'est une architecture qu'on construit délibérément, couche par couche, en sachant exactement ce que chaque couche protège et ce qu'elle ne protège pas. Les cinq piliers qui suivent ne sont pas des recommandations génériques. Ce sont les conditions minimales sans lesquelles aucun plan de continuité ne résiste à un scénario de destruction physique de l'infrastructure cloud. Premier pilier : identifier le cerveau de votre infrastructure. Toute architecture numérique possède un point de défaillance unique, l'endroit dont la destruction ou l'isolement rend le reste inutilisable. C'est souvent le control plane, parfois un serveur DNS critique, parfois une base de données centrale. La première étape de toute démarche de résilience est de cartographier précisément cet endroit, de le nommer, et de vérifier que votre plan de continuité survit à sa disparition physique totale. Un plan de continuité qui ne répond pas à la question « que se passe-t-il si ce bâtiment précis brûle ce soir » n'est pas un plan de résilience. C'est un document rassurant. Deuxième pilier : diversifier la connectivité physique, pas seulement les fournisseurs. Comme démontré dans le chapitre précédent, utiliser plusieurs hyperscalers ne protège pas si ces fournisseurs partagent les mêmes routes de transit, les mêmes points d'échange internet, ou les mêmes câbles sous-marins. La vraie diversification impose que vos systèmes critiques puissent atteindre vos utilisateurs par au moins deux routes physiques entièrement indépendantes, passant par des points d'échange internet distincts, situés dans des zones géographiques soumises à des risques géopolitiques différents. C'est un niveau d'exigence que la plupart des architectures cloud commerciales actuelles ne satisfont pas. Troisième pilier : protéger les sauvegardes par une isolation totale. Une sauvegarde hébergée dans le même datacenter que les données primaires, ou dans un datacenter connecté aux mêmes réseaux, n'est pas une sauvegarde de résilience physique. C'est une copie. La protection réelle impose des sauvegardes air-gapped : physiquement déconnectées de tout réseau, stockées dans un site géographiquement distinct, et dont la restauration a été testée dans des conditions réelles. La règle minimale reconnue dans l'industrie est dite 3-2-1 : trois copies des données, sur deux supports différents, dont une hors site et déconnectée. Dans un contexte de conflit hybride, on y ajoute désormais l'exigence que ce site hors ligne soit dans une juridiction géopolitiquement distincte. Les cinq piliers de la résilience physique réelle Quatrième pilier : définir et tester les plans de bascule avant la crise. Un RTO et un RPO définis sur le papier mais jamais testés sont des intentions, pas des garanties. La bascule vers une infrastructure de secours, dans des conditions de stress réel, fait apparaître systématiquement des problèmes que personne n'avait anticipés : des dépendances invisibles entre systèmes, des configurations qui n'ont pas été mises à jour, des accès qui ne fonctionnent plus, des équipes qui ne savent plus exactement quoi faire parce que la procédure n'a pas été répétée depuis dix-huit mois. La résilience opérationnelle exige des tests de bascule complets, documentés, et régulièrement répétés, au minimum une fois par an pour les systèmes critiques. Cinquième pilier : ne pas dépendre d'un seul suzerain numérique pour les décisions critiques. Ce pilier est le moins technique et le plus stratégique. Il concerne la gouvernance, pas l'architecture. Toute organisation dont la continuité opérationnelle dépend entièrement d'un contrat avec un seul fournisseur américain, sans alternative activable sous 24 heures, a externalisé une décision souveraine à une entité étrangère soumise à ses propres contraintes légales, géopolitiques et commerciales. La diversification des fournisseurs, des juridictions d'hébergement, et des architectures de repli n'est pas seulement une décision technique. C'est une décision de gouvernance qui appartient aux directions générales et aux conseils d'administration, pas aux équipes informatiques seules. Ces cinq piliers ensemble ne garantissent pas l'invulnérabilité. Aucune architecture n'est invulnérable. Ils garantissent que si l'un de vos systèmes est frappé, détruit ou isolé, les dommages restent contenus, la reprise est possible dans un délai connu et testé, et aucun acteur extérieur ne détient seul les clés de votre continuité. Cadre réglementaire européen : Ce que NIS2, CER et DORA exigent concrètement, et ce qu'ils ne couvrent pas L'Union européenne a produit ces dernières années trois textes majeurs qui transforment la résilience numérique d'une bonne pratique optionnelle en obligation légale contraignante. Comprendre ce que chacun exige et surtout ce qu'aucun des trois ne couvre est devenu indispensable pour tout dirigeant ou régulateur opérant en Europe ou avec des partenaires européens. NIS2 : La directive sur la sécurité des réseaux et des systèmes d'information. Entrée en application en octobre 2024, NIS2 étend considérablement le périmètre de son prédécesseur en élargissant les secteurs concernés et en durcissant les obligations. Elle couvre désormais les opérateurs d'infrastructures critiques dans dix-huit secteurs, dont l'énergie, les transports, la santé, l'eau, les infrastructures numériques et les services cloud. Concrètement, elle impose à ces organisations de mettre en place des mesures de gestion des risques cybernétiques, de notifier les incidents significatifs dans des délais stricts, 24 heures pour une alerte initiale, 72 heures pour un rapport complet, et de démontrer que leurs dirigeants ont suivi une formation adéquate sur les risques numériques. Les sanctions en cas de non-conformité peuvent atteindre 10 millions d'euros ou 2% du chiffre d'affaires mondial annuel pour les entités dites essentielles. CER : La directive sur la résilience des entités critiques. Adoptée en parallèle de NIS2 et également entrée en vigueur en 2024, CER va plus loin sur le plan physique. Elle oblige les opérateurs d'infrastructures critiques à conduire des analyses de risques qui incluent explicitement les menaces physiques : catastrophes naturelles, actes terroristes, sabotages. Elle impose des plans de continuité testés, des procédures de reprise documentées, et une coopération renforcée avec les autorités nationales compétentes. C'est le texte qui se rapproche le plus des enjeux traités dans ce document, puisqu'il reconnaît explicitement que la menace sur une infrastructure critique peut être physique et pas seulement numérique. DORA : Le règlement sur la résilience opérationnelle numérique du secteur financier. Entré en application en janvier 2025, DORA s'adresse spécifiquement aux institutions financières : banques, assurances, gestionnaires d'actifs, infrastructures de marché. Il impose des exigences détaillées sur la gestion des risques liés aux prestataires tiers de services numériques, y compris les fournisseurs cloud. Concrètement, une banque européenne doit désormais cartographier précisément ses dépendances envers ses hyperscalers, tester régulièrement sa résilience opérationnelle, et s'assurer que ses contrats cloud incluent des droits d'audit et des garanties de continuité. DORA introduit également la notion de « prestataire tiers critique », ce qui signifie que des entités comme AWS ou Azure peuvent être directement soumises à la supervision des régulateurs financiers européens. L'angle mort que ces trois textes partagent. Malgré leur ambition et leur portée, NIS2, CER et DORA ont un point commun qui est devenu une vulnérabilité systémique depuis mars 2026 : leurs exigences de tests de résilience sont calibrées sur des scénarios de cyberattaques ou de défaillances techniques internes. Aucun de ces textes n'impose explicitement de tester la résistance à la destruction physique simultanée de deux régions cloud dans deux pays différents, qui est précisément le scénario que les frappes iraniennes ont matérialisé. Une organisation peut être en pleine conformité avec ces trois règlements tout en étant totalement incapable de survivre à ce type d'événement. C'est le chantier réglementaire que les événements de mars 2026 ont ouvert, et que ni les régulateurs ni les opérateurs ne peuvent continuer d'ignorer. Ce que cela signifie concrètement pour un dirigeant est simple : la conformité réglementaire est nécessaire mais pas suffisante. Elle protège contre les sanctions. Elle ne protège pas contre une frappe. Les deux logiques doivent coexister, et c'est précisément ce que la feuille de route du chapitre suivant permet de construire pas à pas. ### Feuille de route sur 12 mois : de la lecture à l'action Lire ce document sans en tirer un plan d'action daté et responsabilisé, c'est transformer une analyse stratégique en exercice intellectuel. Ce qui suit est une séquence directrice à adapter selon votre secteur, votre maturité IT et vos contraintes réglementaires propres. Ce n'est pas un guide d'implémentation clé en main, les réalités d'une PME de cinquante personnes et d'une banque régionale n'appelleront pas les mêmes réponses. C'est un cadre de priorisation conçu pour que chaque organisation puisse identifier, dans sa situation propre, par où commencer et dans quel ordre agir. Mois 1 à 3 Cartographier avant de décider La première erreur des organisations qui réagissent à une crise est de prendre des décisions d'infrastructure sans avoir cartographié ce qu'elles cherchent à protéger. La priorité absolue des trois premiers mois est donc une cartographie complète de vos dépendances numériques critiques. Cela signifie identifier précisément quels systèmes sont hébergés où, par qui, dans quelle région géographique, avec quelles dépendances vers des services tiers comme DNS, CDN, points d'échange internet. Cela signifie également identifier votre point de défaillance unique : l'endroit dont la destruction rend le reste inutilisable. Ce travail doit être conduit conjointement par les équipes techniques et les directions métier, parce que les premières savent où sont les systèmes, et les secondes savent lesquels sont véritablement critiques pour la continuité de l'activité. L'écart entre ces deux perceptions est presque toujours plus grand qu'on ne le croit. Le livrable de cette phase est un document d'une à deux pages, accessible aux dirigeants sans formation technique, qui répond à trois questions : où se trouve le cerveau de notre infrastructure, que se passe-t-il si ce cerveau disparaît ce soir, et combien de temps mettons-nous à reprendre nos opérations critiques dans ce scénario. Mois 4 à 6 Tester ce qu'on croit avoir La plupart des organisations disposent déjà de plans de continuité, de contrats de sauvegarde, et d'architectures multi-sites. Le problème n'est pas leur absence. C'est qu'ils n'ont jamais été testés dans des conditions réelles. La deuxième phase consiste donc à organiser un exercice de bascule complet sur au moins un système critique, en simulant la disparition totale de l'infrastructure primaire de manière réelle. Pas un test technique en salle des serveurs. Un exercice impliquant les décideurs opérationnels, les équipes métier, et si possible les prestataires externes concernés. Cet exercice révélera systématiquement des problèmes que personne n'avait anticipés : des configurations obsolètes, des accès expirés, des dépendances invisibles entre systèmes, des procédures que personne ne sait plus exécuter sous pression. C'est précisément pour cela qu'il faut le faire maintenant, et non au moment d'une crise réelle. Le livrable de cette phase est un rapport d'exercice documentant les écarts entre le RTO et le RPO contractuels et les délais réellement observés pendant le test, assorti d'un plan de correction priorisé. Mois 7 à 9 Corriger les vulnérabilités identifiées Les résultats de l'exercice de bascule définissent l'agenda de cette phase. Les corrections à apporter sont rarement toutes de même nature. Certaines sont techniques et peuvent être traitées rapidement : mettre à jour des configurations, activer des routes de secours, restaurer des accès. D'autres sont contractuelles et prennent plus de temps : renégocier des SLA, intégrer des clauses de résilience physique dans les contrats cloud, exiger des droits d'audit sur les infrastructures de vos prestataires critiques. D'autres encore sont structurelles et impliquent des décisions d'investissement : migrer certaines données vers des juridictions géographiquement distinctes, mettre en place des sauvegardes air-gapped, diversifier les routes de connectivité physique. La priorisation doit suivre un critère simple : commencer par les vulnérabilités dont la matérialisation serait fatale à l'organisation, indépendamment de leur probabilité estimée. Ce que mars 2026 a appris au monde, c'est que les scénarios jugés improbables se matérialisent. Le critère de priorisation n'est donc pas la probabilité, mais l'impact. Mois 10 à 12 Ancrer la résilience dans la gouvernance La résilience physique ne peut pas rester un projet ponctuel confié aux équipes informatiques. Elle doit devenir un attribut permanent de la gouvernance de l'organisation, au même titre que la conformité financière ou la gestion des risques juridiques. Cette dernière phase consiste à institutionnaliser ce qui a été construit. Cela signifie intégrer la revue annuelle des plans de continuité à l'agenda des instances dirigeantes, former les décideurs non techniques aux concepts fondamentaux documentés dans ce lexique, et désigner un responsable explicitement en charge de la résilience physique de l'infrastructure, avec un mandat clair et des ressources dédiées. Cela signifie également actualiser le registre des risques de l'organisation pour y intégrer explicitement le scénario de frappe physique sur infrastructure cloud, avec une évaluation de son impact potentiel et une description des mesures de mitigation mises en place. Dans le cadre de NIS2 et CER, cette documentation n'est pas optionnelle. Elle constitue la preuve de conformité que les régulateurs peuvent demander à tout moment. À l'issue de ces douze mois, votre organisation ne sera pas invulnérable. Aucune organisation ne l'est. Mais elle aura accompli ce que la grande majorité de ses pairs n'a pas encore fait : elle saura précisément ce qu'elle protège, comment elle bascule, depuis où elle reprend, et en combien de temps. C'est cette différence, entre ceux qui savent et ceux qui supposent, que mars 2026 a rendue stratégiquement décisive. La géostratégie des infrastructures numériques : Un nouveau champ disciplinaire Ce que nous avons vécu le 1er mars 2026 à Abu Dhabi ne sera pas classé dans les annales comme un incident de continuité d'activité. Ce sera le moment où un concept qui circulait depuis des années dans les cercles académiques et les think tanks a reçu sa confirmation la plus brutale et la plus visible : la géostratégie des infrastructures numériques existe, elle est réelle, et elle tue des services bancaires. ## La géostratégie des infrastructures numériques ### De la géopolitique classique à la techno-géopolitique La géopolitique classique étudie comment la géographie physique, les montagnes, les fleuves, les détroits, les ressources naturelles, détermine les rapports de puissance entre États. La Mer Rouge était déjà un détroit stratégique sous les Pharaons. Ce qui est radicalement nouveau, c'est que cette même Mer Rouge transporte aujourd'hui simultanément du pétrole et des données. 17 câbles fibre-optique sous-marins y transitent, portant l'essentiel des échanges numériques entre l'Europe, l'Asie et l'Afrique. Couper ces câbles produit le même type de dommage stratégique que bloquer les tankers. La géographie n'a pas changé. Ce qui a changé, c'est ce qui y circule. La techno-géopolitique, terme développé notamment par l'analyste Abishur Prakash, va plus loin. Elle étudie comment la technologie elle-même devient un territoire, avec des frontières, des ressources, des zones d'influence et des conflits d'appropriation. Dans cette lecture, un datacenter n'est pas une usine. C'est un territoire numérique souverain. Localiser ce datacenter sous une montagne norvégienne plutôt qu'à Abu Dhabi, c'est exactement la même décision stratégique que choisir où implanter un port militaire. ### Trois disciplines convergentes Ce que les frappes iraniennes ont révélé, c'est la convergence de trois champs intellectuels qui fonctionnaient jusqu'ici en silos et qui, désormais, ne peuvent plus être pensés séparément. DISCIPLINE CE QU'ELLE ÉTUDIE AUTEUR(S) DE RÉFÉRENCE Géopolitique des Localisation physique du pouvoir numérique : Frédérick Douzet (IFG Paris 8) infrastructures où sont les câbles, les datacenters, les nœuds Chaire Castex de Cyberstratégie critiques internet, et qui les contrôle. Souveraineté Indépendance décisionnelle : qui peut couper Asma Mhalla -Technopolitique numérique l'accès à vos données, qui contrôle les (Seuil, 2023) Émission algorithmes, qui détient les clés de chiffrement. CyberPouvoirs, France Inter Géostratégie Compétition inter-étatique pour la maîtrise des Abishur Prakash - The World is technologique technologies fondamentales : semi-conducteurs, Vertical (2021) - rapports IA/Énergie IA, cloud, quantique dont les datacenters sont l'expression physique la plus visible. ### Le technoféodalisme comme grille d'analyse II existe un quatrième cadre conceptuel, économique celui-là, qui éclaire ce qui s'est passé le 1er mars 2026 d'une façon que les analyses purement techniques ne permettent pas. L'économiste Cédric Durand a développé dans son ouvrage Techno-féodalisme (La Découverte, 2020) une analyse de la rente numérique : les grandes plateformes ne fonctionnent plus comme des marchés capitalistes classiques mais comme des fiefs qui extraient de la valeur de leurs utilisateurs captifs sans produire directement. Sa thèse porte d'abord sur les plateformes de distribution, Google, Apple, Amazon Marketplace. Ce document étend cette logique à l'infrastructure cloud elle-même, une extrapolation que Durand ne formule pas explicitement mais que les événements de mars 2026 rendent difficile à éviter : quand une entreprise héberge l'intégralité de ses systèmes critiques chez un seul hyperscaler, elle ne loue pas un service, elle paie un tribut à un suzerain dont elle dépend existentiellement. Quand une frappe iranienne sur AWS met simultanément hors ligne les systèmes bancaires d'Abu Dhabi, des opérateurs régionaux de livraison et les outils d'analyse financière d'entreprises européennes, c'est exactement cette structure féodale qui se révèle dans toute sa fragilité : un seul suzerain technologique, des milliers de vassaux dispersés sur cinq continents, et quand le château brûle, tout le fief s'effondre. La résilience que je recommande dans ce document n'est pas seulement une mesure technique. C'est un acte de souveraineté politique : s'affranchir partiellement de la vassalité numérique. On ne peut plus parler de cybersécurité sans parler de géographie, et on ne peut plus parler de géopolitique sans parler d'infrastructure numérique. Cette logique de vassalité ne s'applique pas qu'aux hyperscalers américains. Les acteurs chinois comme Alibaba Cloud, Huawei Cloud, Tencent, sont soumis à la loi de sécurité nationale de 2017, qui impose une obligation légale de coopération avec les services de renseignement de Pékin. Une organisation qui migrerait vers ces plateformes chinoises pour « diversifier » sa dépendance créerait une vassalité symétrique sous une juridiction différente. La souveraineté numérique réelle n'est atteignable que par une infrastructure dont la juridiction est politiquement cohérente avec les intérêts propres de l'organisation. La frontière entre attaque militaire et cyberattaque est devenue aussi floue que la frontière entre un datacenter et une cible militaire. Les frappes du 1er mars 2026 à Abu Dhabi ont officiellement marqué ce basculement. ### La perspective MENA/Maghreb Cette grille d'analyse prend une acuité particulière pour les organisations opérant entre l'Europe, le Maghreb et le Golfe, parce que leur exposition structurelle est différente de celle des entreprises européennes ou américaines. Elle est à la fois plus concentrée et moins visible. Plus concentrée parce que le Maghreb ne dispose d'aucune région cloud hyperscaler sur son sol. À ce jour, aucun hyperscaler mondial n'opère de région cloud certifiée sur le sol du Maghreb, ni AWS, ni Azure, ni Google Cloud. Toute organisation maghrébine qui adopte une architecture cloud doit donc, par définition, héberger ses systèmes critiques à l'étranger, et dans la quasi-totalité des cas, le choix s'est orienté vers les régions du Golfe, pour des raisons de latence, de proximité culturelle et de disponibilité des certifications sectorielles exigées par les régulateurs locaux. Cette absence d'ancrage territorial n'est pas un choix stratégique. C'est une contrainte subie, rarement nommée comme telle. Moins visible parce que la dépendance ne s'arrête pas à l'hébergement des données. Elle touche la connectivité elle-même. En Algérie, la loi n°18-04 de 2018 oblige légalement tous les opérateurs à faire transiter leur trafic international via les infrastructures d'Algérie Télécom, dont les routes physiques passent par les nœuds du câble SEA-ME-WE4, c'est-à-dire par Dubaï et Djeddah avant d'atteindre l'Europe [REF-AT]. Pour le Maroc, Maroc Telecom achemine une part significative de son trafic critique via des points d'échange internet situés hors du Maghreb, à Dubaï, Francfort et Londres principalement [REF-ANRT]. La Tunisie dispose d'une connectivité plus diversifiée depuis novembre 2025, le câble Medusa relie désormais Bizerte à Marseille en route directe, sans transit par le Golfe, mais cette diversification reste récente et n'a pas encore été intégrée dans les plans de continuité de la majorité des organisations qui en dépendent [REF-MEDUSA]. Le câble Africa Coast to Europe (ACE), dont le tracé longe la façade atlantique africaine sur 17 000 km en reliant 24 pays, offre théoriquement une route alternative vers l'Europe sans passer par le Golfe [REF-ACE]. Mais pour la plupart des organisations maghrébines, cette route n'a pas été contractualisée comme chemin de secours indépendant. Elle partage des nœuds de transit avec les routes principales, recréant exactement le problème décrit dans le chapitre sur le multi-cloud : la diversité apparente masque une dépendance physique commune. Cette absence de contractualisation n'est pas documentée dans des rapports publics, c'est une lacune précisément parce qu'aucune organisation n'a à ce jour publié ses plans de continuité en détaillant ses routes de secours. Elle est cependant cohérente avec le niveau de peering enregistré au MIXP (CAS-IX sur les registres PeeringDB internationaux) : trois membres actifs sur un nœud techniquement capable d'absorber un basculement régional [REF-CASIX]. Le nœud d'échange internet de Casablanca, le MIXP, est l'actif géostratégique le plus sous-exploité de la région. Il est techniquement capable de servir de nœud de transit alternatif pour le trafic MENA vers l'Europe sans passer par les IXP du Golfe. Mais son niveau de peering actuel reste insuffisant pour absorber un basculement d'urgence régional. Il lui manque les accords d'interconnexion directe avec les opérateurs cloud tier-1, les capacités de bande passante pour traiter un volume de crise, et surtout la reconnaissance contractuelle comme route de secours dans les plans de continuité des organisations qui en auraient le plus besoin. Ce n'est pas un problème technique. C'est un problème de décision politique et réglementaire. C'est précisément là que la géostratégie des infrastructures numériques rencontre la politique industrielle régionale. Renforcer le MIXP, développer des accords de peering direct avec les hyperscalers sur ce nœud, et inciter les entreprises maghrébines à contractualiser des routes de transit indépendantes du Golfe sont des décisions qui appartiennent aux régulateurs nationaux, à l'ANRT au Maroc, à l'ARPCE en Algérie, à l'ATI en Tunisie, et non aux équipes informatiques des entreprises concernées. Le Maroc a amorcé ce mouvement : le référentiel de qualification cloud publié au Bulletin officiel en août 2025 impose désormais aux entités d'importance vitale de ne recourir qu'à des prestataires certifiés par la DGSSI, et le gouvernement a annoncé en juillet 2025 un datacenter souverain de 500 MW dans le cadre de la feuille de route Digital Morocco 2030 [REF-DM2030]. Ces décisions vont dans le bon sens. Elles ne résolvent pas pour autant la question posée par ce document : disposer d'un datacenter souverain ne suffit pas si les routes de connectivité qui y mènent passent encore par les mêmes nœuds de transit. Tant que cette question reste sans réponse testée, la question adressée à tout décideur maghrébin demeure entière : si votre route principale disparaît, avez-vous vérifié que votre route de secours ne passe pas elle-même par le même nœud ? Ces recommandations portent sur les interdépendances entre infrastructure industrielle et continuité opérationnelle dans l'espace MENA. Elles ne constituent pas une ingérence dans les politiques publiques, Une cartographie complète des dépendances numériques secteur par secteur, avec des recommandations opérationnelles adaptées aux contraintes réglementaires et budgétaires propres à chaque juridiction, fera l'objet d'une édition dédiée. L'avenir de l'infrastructure physique : de la cible à la forteresse Les datacenters sont devenus des cibles militaires. Cette phrase, qui aurait semblé exagérée il y a cinq ans, est aujourd'hui un fait documenté, revendiqué, et répété. Elle va transformer la manière dont ces infrastructures sont conçues, localisées et protégées, non pas parce que l'industrie le choisit, mais parce qu'elle n'a plus le choix. Ce qui suit n'est pas de la prospective spéculative. Ce sont cinq trajectoires déjà en cours, certaines opérationnelles depuis des années, d'autres en développement actif, toutes accélérées par les événements de mars 2026. ## L'avenir de l'infrastructure physique : de la cible à la forteresse ### Les datacenters souterrains et fortifiés : une réalité déjà opérationnelle L'idée de placer un datacenter sous une montagne vient directement de la doctrine militaire de la Guerre froide. Les États construisaient des bunkers dans du granit pour y loger leurs centres de commandement : le roc absorbe les ondes de choc, protège des frappes directes et isole naturellement de la chaleur extérieure. Cette logique n'a jamais disparu. Le Pionen Data Center à Stockholm en est la démonstration la plus visible : creusé à 30 mètres de profondeur dans le granit suédois, c'est un ancien bunker militaire reconverti en datacenter de haute sécurité, avec de vraies portes blindées, des générateurs diesel intégrés à la roche, et une architecture conçue pour résister aux frappes conventionnelles. La Suisse a industrialisé ce modèle depuis des décennies. Des entreprises comme Mount10 ou Safe Host vendent la neutralité politique helvétique autant que le granite alpin : deux arguments que mars 2026 a rendus soudainement très concrets pour leurs clients. Ce modèle va s'exporter massivement dans les prochaines années, et pas uniquement vers des pays neutres. L'Islande offre une variante différente mais complémentaire. Plutôt que la protection par la roche, elle propose la protection par l'éloignement géographique, combinée à des avantages énergétiques rares : des sources d'eau souterraine à température stable entre 8 et 15 degrés assurent un refroidissement naturel, tandis que la géothermie fournit une électricité quasi gratuite et décarbonée. Un pays politiquement neutre, géologiquement stable, et situé hors de toute zone de conflit prévisible. Après 2026, ce profil vaut de l'or. La protection par la roche est réelle, mais elle a une limite que l'actualité de 2025 a rendue visible de façon brutale. Les frappes israéliennes sur le site nucléaire souterrain iranien de Natanz n'ont pas détruit les galeries. Elles ont coupé l'alimentation électrique en surface. Les centrifugeuses se sont arrêtées. Un datacenter souterrain dépendant du réseau électrique national partage exactement cette vulnérabilité : la roche protège contre la bombe directe, elle ne protège pas contre la coupure de courant à 50 kilomètres de là sur une sous-station non enterrée. Les générateurs diesel intégrés à la roche de Pionen donnent quelques jours d'autonomie. Dans un conflit prolongé, ce n'est pas suffisant. La vraie résilience souterraine impose donc trois critères simultanés : La protection physique par la roche, une production d'électricité locale ou suffisamment enterrée pour être elle-même protégée, et un système de refroidissement intégré à l'architecture souterraine et non exposé en surface. C'est précisément pourquoi l'Islande représente un niveau de résilience supérieur aux autres modèles : la géothermie produit l'électricité depuis le sous-sol, le refroidissement vient de sources d'eau souterraines, et la chaîne énergétique complète peut être enfouie. Ce n'est pas un avantage de confort énergétique. C'est un avantage géostratégique. Une deuxième vulnérabilité est rarement mentionnée : l'accès humain. Un datacenter nécessite des interventions physiques que l'automatisation ne peut pas entièrement remplacer. En situation de conflit, l'entrée souterraine est un point d'attaque évident et peu coûteux. Les frappes américaines complémentaires sur Natanz n'ont pas nécessairement détruit les galeries : elles ont rendu les entrées inaccessibles, ce qui suffit à immobiliser l'installation à moyen terme sans la détruire physiquement. Un datacenter souterrain dont les accès sont bloqués reste intact, allumé, refroidi. Mais il est inutilisable. La résilience physique doit donc inclure des entrées redondantes, enfouies depuis des directions différentes, et des protocoles d'accès qui ne dépendent pas d'un seul point d'entrée. La troisième vulnérabilité est la connectivité réseau. Les câbles de fibre optique qui relient un datacenter souterrain au reste du monde remontent en surface exactement comme les câbles électriques. Pionen à Stockholm est protégé contre les bombes, mais ses connexions vers les points d'échange internet suédois passent en surface. Couper ces connexions ne détruit pas le datacenter : il reste intact, allumé, refroidi. Mais il est coupé du monde, aussi utile qu'une bibliothèque dont on a verrouillé la porte. La résilience réseau impose des connexions enfouies, redondantes, arrivant de directions géographiques différentes, avec des routes de secours qui ne partagent aucun point de transit commun. Une dernière fragilité systémique mérite d'être nommée franchement : Le paradoxe de la recommandation. Si l'ensemble des acteurs critiques suit la stratégie préconisée dans ce document et migre vers l'Islande, la Norvège et la Suisse, ces trois pays deviennent à leur tour des cibles stratégiques prioritaires. On ne supprime pas la vulnérabilité, on la déplace géographiquement. La vraie résilience systémique n'est pas la concentration dans des juridictions sûres, mais une distribution suffisamment large pour qu'aucune frappe unique, même massive, ne puisse paralyser simultanément plusieurs nœuds critiques. Concrètement, cette distribution mondiale doit intégrer des zones géographiques aux profils de risque véritablement distincts. L'Afrique subsaharienne, notamment le Kenya et le Rwanda qui développent activement leurs infrastructures numériques souveraines, offre une exposition géopolitique radicalement différente de l'Europe du Nord. L'Amérique latine, avec le Brésil et le Chili comme pôles émergents d'infrastructure, représente une troisième zone de diversification crédible. C'est une carte de risques diversifiés, construite sur le même principe que celui que ce document défend depuis sa première page : aucune frappe unique, même massive, ne doit pouvoir atteindre simultanément des nœuds situés sous des juridictions géopolitiquement indépendantes. C'est un déplacement permanent du point de faiblesse vers un endroit où il est plus difficile à atteindre, plus coûteux à exploiter, et moins fatal s'il est touché. ### Les datacenters sous-marins : une réalité commerciale aux vulnérabilités déplacées Les sauvegardes air-gapped placées dans un bunker souterrain constituent la combinaison de protection la plus robuste disponible aujourd'hui. Trois isolations simultanées : logique, parce que le système est déconnecté du réseau et donc inatteignable à distance ; physique, parce que la structure durcie absorbe les chocs et résiste aux frappes ; géographique, parce que le site est distinct du principal et ne partage aucune dépendance commune avec lui. C'est ce que les militaires appellent une position de repli durcie, le seul type d'infrastructure qui résiste en même temps à une frappe physique, une cyberattaque et une coupure réseau prolongée. Microsoft a conduit entre 2018 et 2020 l'expérience la plus documentée du secteur avec le Projet Natick : un datacenter dans un conteneur étanche, immergé à 36 mètres de profondeur au large des côtes écossaises pendant deux ans, sans aucune intervention humaine. Le bilan a contredit plusieurs intuitions initiales. La fiabilité des serveurs était 8 fois supérieure à celle d'un datacenter terrestre équivalent. La raison est contre-intuitive : en immersion, le conteneur est rempli d'azote inerte qui élimine l'oxygène, supprimant la corrosion qui est l'ennemi numéro un des composants électroniques. La mer absorbe par ailleurs la chaleur des serveurs de manière passive, supprimant l'essentiel des besoins en climatisation. La limite principale que ce projet a mise en évidence reste la maintenance. Quand quelque chose tombe en panne à l'intérieur, remonter le conteneur entier est coûteux et lent. L'architecture doit donc être conçue pour que les serveurs fonctionnent sans intervention humaine pendant toute leur durée de vie, une contrainte radicalement différente de celle des datacenters terrestres. Ce qu'implique cette contrainte opérationnellement n'est pas souvent précisé : pendant toute la durée de remontée, de maintenance et de réimmersion d'un module, l'intégralité de l'infrastructure hébergée dans ce module est indisponible. Pour un opérateur commercial qui a contractuellement garanti à ses clients un niveau de disponibilité minimal (SLA), c'est une contrainte de continuité de service non résolue à ce jour. Le modèle modulaire de Hainan répond partiellement à ce problème : 100 modules interconnectés permettent d'en remonter un sans affecter les autres. Mais cette redondance a un coût d'infrastructure qui n'est pas encore reflété dans les comparaisons économiques avec les datacenters terrestres. C'est pour cette raison que Microsoft a choisi en 2024 de ne pas commercialiser Natick : techniquement prouvé, mais pas encore économiquement viable à grande échelle. Ce que Microsoft n'a pas franchi, la Chine l'a franchi. En décembre 2023, la société Highlander a immergé à 35 mètres de profondeur au large de Lingshui, dans la province de Hainan, le premier datacenter sous-marin commercial au monde. En février 2026, un second module a été ajouté, capable de traiter 7000 requêtes d'intelligence artificielle par seconde. Dix entreprises utilisent déjà cette infrastructure, et le plan prévoit à terme 100 modules immergés dans cette seule zone. HiCloud revendique une réduction de consommation de 40 à 60% pour ses modules de Hainan, selon des déclarations de l'opérateur relayées par Data Center Dynamics en 2024. Ses projets ultérieurs annoncent des gains plus conservateurs, entre 23 et 30%. L'avantage énergétique est réel ; son amplitude exacte reste à ce stade auto-déclarée. Cette efficacité repose cependant sur une hypothèse qui mérite d'être nommée : la stabilité de la température de l'eau. Les datacenters sous-marins côtiers sont implantés à faible profondeur, précisément là où les océans se réchauffent le plus vite sous l'effet du changement climatique. L'efficacité énergétique annoncée est calculée sur des températures d'eau actuelles. Elle se dégradera progressivement, et le refroidissement peut devenir insuffisant lors des épisodes de chaleur marine exceptionnelle. C'est une vulnérabilité à horizon 10-20 ans qui n'est pas prise en compte dans les projections actuelles. Mais l'expérience chinoise révèle aussi ce que ce document cherche à démontrer depuis sa première page : chaque nouvelle forme d'infrastructure déplace la vulnérabilité sans l'éliminer. Hainan se trouve en Mer de Chine méridionale, l'une des zones maritimes les plus militairement contestées au monde. Un datacenter protégé des drones aériens reste accessible à d'autres formes de menace sous-marine, et elles sont désormais documentées, opérationnelles, et en cours de prolifération rapide. Cahiers de technopolitique, n° 1, Sources en dernières pages 25 La première est la menace acoustique. Le risque acoustique sur les structures immergées n'est pas théorique. En novembre 2024, Thales et FEBUS Optics ont signé un accord de co-développement d'une solution de surveillance acoustique permanente des infrastructures critiques sous-marines, basée sur la détection de toute anomalie vibratoire en tout point d'une structure immergée. L’existence même de cet accord de co-développement confirme que les opérateurs d’infrastructures critiques sous-marines intègrent désormais le risque acoustique dans leurs architectures de protection (surveillance passive des signaux hydrophones). Les principes de la guerre acoustique sous-marine, exploitation des vibrations basse fréquence pour déstabiliser des structures ou des équipements sensibles, sont quant à eux documentés dans la littérature militaire depuis plusieurs décennies, et leur application aux datacenters immergés constitue un vecteur d'attaque que les opérateurs de ces infrastructures intègrent désormais dans leurs analyses de risques Ces dispositifs sont discrets, peu coûteux comparés à un missile, et ne laissent aucune signature visible en surface. C'est une vulnérabilité que personne n'avait anticipée lors de la conception de ces infrastructures, précisément parce qu'elles ont été pensées comme des réponses à des menaces aériennes et non sous-marines. La contre-mesure existe, elle consiste en des systèmes d'isolation vibratoire des racks et des capteurs acoustiques de surveillance périmétrique. Mais elle n'est pas encore intégrée dans les standards de construction des datacenters sous-marins commerciaux actuels, Hainan inclus. La deuxième est la menace des drones sous-marins autonomes. L'ère de la guerre des fonds marins, où les infrastructures sous-marines seront de plus en plus ciblées, est arrivée. La Chine a développé en mars 2025 un outil capable de couper des câbles sous-marins blindés à une profondeur de 4000 mètres, monté sur un bras robotique utilisant une meule diamantée tournant à 1600 tours par minute. La Russie opère une flotte de navires, sous-marins et drones sous-marins via sa Direction principale de recherche en eaux profondes, spécifiquement dédiée aux opérations contre les infrastructures critiques sous-marines. Ces vecteurs ne sont pas des projets : ce sont des capacités opérationnelles déployées. Entre novembre 2024 et janvier 2025, sept câbles sous-marins ont été sectionnés dans la mer Baltique, dans des incidents largement attribués à des actions de sabotage d'acteurs étatiques. Un drone sous-marin autonome lancé à des centaines de kilomètres de sa cible peut approcher sans être détecté, localiser le module par sonar, et le neutraliser sans laisser de signature exploitable. La réponse à cette menace est en cours de développement : six marines nordiques ont lancé en mai 2025 le Centre d'expérimentation pour la sécurité des fonds marins, intégrant des drones de surveillance sous-marine, des capteurs acoustiques distribués et des véhicules autonomes de patrouille. Mais la capacité offensive précède la capacité défensive, comme toujours. Et la connectivité reste le maillon le plus fragile de tout le système. Les câbles qui relient un datacenter sous-marin au reste du réseau sont des câbles sous-marins, exactement ceux dont nous avons vu la vulnérabilité en Mer Rouge en 2026. En février 2024, trois câbles en Mer Rouge avaient déjà été sectionnés par l'ancre traînante d'un cargo touché par un missile houthi, perturbant 25% du trafic entre l'Asie, l'Europe et le Moyen-Orient, et l'un d'eux a nécessité cinq mois de réparation parce que les navires spécialisés ne pouvaient pas accéder à la zone en sécurité. Un datacenter sous-marin dont les connexions sont coupées reste intact, allumé, refroidi, et complètement inaccessible depuis le reste du monde. La résilience n'est pas une destination. C'est un déplacement permanent du point de faiblesse vers un endroit où il est plus difficile à atteindre, plus coûteux à exploiter, et moins fatal s'il est touché. ### Les datacenters en orbite : réalité physique et contraintes incontournables Plusieurs entreprises travaillent sur des datacenters orbitaux. Lumen Orbit aux États-Unis est la plus avancée avec une feuille de route crédible. L'Agence Spatiale Européenne (ESA) a publié des études de faisabilité. La Chine a officiellement intégré les datacenters spatiaux dans son plan quinquennal technologique. En orbite basse, entre 400 et 2000 km d'altitude, un satellite dispose d'une énergie solaire continue et échappe à toute frappe militaire conventionnelle. Aucun drone Shahed ne monte à 500 km. Cette phrase est exacte mais elle appelle une précision importante : si aucun drone iranien ne monte à 500 km, la Chine, la Russie et les États-Unis disposent tous de missiles antisatellites opérationnels capables d'atteindre l'orbite basse. Un datacenter orbital échappe aux drones de conflits hybrides régionaux. Il ne résiste pas à une confrontation entre puissances majeures. La stratification vers l'orbite déplace donc la vulnérabilité vers un niveau de menace supérieur : d'un conflit régional à une confrontation stratégique entre grandes puissances. Ce déplacement peut être acceptable selon le contexte, mais il doit être assumé consciemment, pas ignoré. Mais la physique ne négocie pas. La première contrainte est la latence, et elle est incompressible. Même en orbite très basse à 500 km, le signal met 3 à 5 millisecondes pour l'aller-retour. Ce délai est invisible pour de l'archivage ou du traitement scientifique, mais il est rédhibitoire pour une transaction financière temps réel ou une chirurgie à distance. Les datacenters orbitaux ne pourront pas servir tous les usages, seulement ceux qui tolèrent ce délai. En octobre 2024, la JAXA et NEC ont réussi une communication optique inter-satellitaire par laser à 1,8 gigabits par seconde sur une distance de 40 000 km, un record mondial de débit. C'est une avancée réelle et significative, notamment parce qu'un faisceau laser de quelques centimètres de diamètre dirigé précisément vers un satellite est quasi impossible à intercepter ou à brouiller, contrairement aux communications radio classiques. Sur le plan de la sécurité des infrastructures critiques, cette technologie est donc très pertinente. Mais elle ne change rien à la latence. La lumière laser voyage à la même vitesse que les ondes radio. Ce que le laser améliore, c'est la quantité d'informations transportées dans le même temps, pas la vitesse à laquelle le signal fait l'aller-retour. La contrainte physique de la latence reste entière, quelle que soit la technologie de transmission utilisée. La deuxième contrainte est le refroidissement, et elle est contre-intuitive. On pourrait croire que le vide spatial, à moins 270 degrés, est un congélateur idéal. En réalité, sans atmosphère, la seule manière d'évacuer la chaleur est le rayonnement infrarouge. Pour dissiper les watts produits par des serveurs à haute densité, il faudrait des panneaux radiateurs de plusieurs centaines de mètres carrés par mégawatt de puissance installée, une surface impossible à déployer dans l'état actuel des lanceurs. La troisième contrainte est la maintenance. Envoyer un technicien réparer un serveur en orbite coûte des dizaines de millions de dollars par mission. L'architecture doit donc être conçue dès le départ pour fonctionner sans aucune intervention humaine pendant 10 à 15 ans, ce qui impose une redondance matérielle extrême et limite fondamentalement la densité de calcul embarquable. Une quatrième contrainte mérite d'être ajoutée, parce qu'elle échappe à toute analyse géopolitique : Un événement de type Carrington, dont les estimations scientifiques situent la probabilité d'occurrence entre moins de 2% et 12% par décennie selon les modèles retenus; les travaux de Riley (Space Weather, AGU, 2012) donnant une borne haute à 12%, tandis que Moriña et al. (Scientific Reports, Nature, 2019) retiennent une fourchette de 0,46% à 1,88%, représente un risque de faible probabilité mais d'impact potentiellement catastrophique pour toute infrastructure numérique non protégée contre les surtensions électromagnétiques à grande échelle. Les satellites commerciaux actuels ne sont pas conçus pour résister à ce niveau d'exposition. Un datacenter orbital serait vulnérable à un phénomène naturel qu'aucun acteur étatique ne peut ni provoquer ni empêcher, et contre lequel il n'existe pas encore de solution technique économiquement viable. C'est la seule menace identifiée dans ce document qui soit totalement indépendante de la géopolitique. Les données froides, c'est-à-dire celles qu'on doit conserver mais qu'on consulte rarement, archives légales, séquences génomiques, patrimoine culturel numérique, enregistrements scientifiques à long terme, rejoindront l'orbite dans un horizon de 15 à 20 ans, à condition que les coûts de lancement continuent de chuter au rythme qu'impose la réutilisation des lanceurs. Ce n'est pas de la prospective spéculative. C'est une trajectoire déjà en cours, dont chaque étape est conditionnée par des variables économiques et technologiques mesurables. Elle reste cependant soumise à une condition géopolitique fondamentale : L'orbite basse est hors de portée des conflits régionaux, mais pas des confrontations entre grandes puissances. Stocker des archives légales ou du patrimoine culturel en orbite a du sens dans un monde où la menace principale reste le drone ou le missile de théâtre. Ce sens disparaît si le contexte bascule vers une confrontation directe entre puissances nucléaires. C'est un choix stratégique à faire consciemment, pas une évidence technique. En termes simples : le souterrain pour le critique, le sous-marin pour le sensible, l'orbite pour le froid. Sous réserve que le ciel reste un espace suffisamment préservé pour que cette dernière couche tienne ses promesses. Cette stratification est une architecture de destination. Elle ne se met pas en place au moment de la crise : elle doit exister avant. Ce point est crucial et souvent mal compris. On ne migre pas des données critiques vers un bunker souterrain en réponse à une frappe imminente. La migration prend du temps, de la bande passante, et suppose que la décision de basculer ait été prise et testée longtemps avant que la menace n'arrive. La vraie résilience opérationnelle impose donc que chaque couche de cette stratification soit accompagnée d'un plan de bascule défini : le RTO (Recovery Time Objective, temps maximal acceptable avant reprise de service) et le RPO (Recovery Point Objective, perte de données maximale acceptable) pour chaque type de données et chaque type d'incident. Un datacenter souterrain qui n'a jamais testé la bascule depuis le datacenter primaire n'est pas une forteresse. C'est une salle de secours que personne ne sait utiliser sous pression. ### Vers une stratification des infrastructures selon le risque Les horizons temporels indiqués sont des estimations conditionnelles, non des prédictions. La colonne Signal concret ancre chaque trajectoire dans des faits observables à la date d'avril 2026. Les mentions ⚠ signalent les vulnérabilités résiduelles après déplacement de la menace. ## Conclusion : la résilience, une philosophie autant qu'une technique qu'une technique Le cloud n'est pas une infrastructure abstraite et immatérielle. C'est du béton, des câbles, des batteries, des groupes électrogènes, et donc une cible physique, comme un pont, une centrale électrique ou un aéroport. Les frappes iraniennes sur AWS en mars 2026 ont officiellement mis fin à une illusion de deux décennies : l'idée que les datacenters sont des infrastructures commerciales neutres, en dehors des équations géopolitiques et militaires. Trois cadres permettent désormais de lire cette réalité avec précision. La géostratégie des infrastructures numériques, d'abord, comme discipline qui nomme ce que beaucoup pressentaient sans pouvoir le formuler. Le technoféodalisme ensuite, comme grille économique qui explique pourquoi la destruction d'un seul château numérique peut paralyser des milliers de vassaux sur cinq continents. La stratification de l'infrastructure physique enfin, du bunker souterrain au datacenter orbital, comme horizon de transformation à vingt ans qui est déjà en cours, pas encore à venir. Ces trois dimensions ensemble permettent de penser la résilience non plus seulement comme un plan de continuité d'activité, mais comme un choix de souveraineté. Ce choix doit être fait les yeux ouverts. Ce que ce document préconise n'est pas une forteresse unique, aussi sophistiquée soit-elle. C'est une fédération de noeuds souverains distribués, dont chaque couche physique répond à un niveau de menace distinct. Le souterrain protège contre la frappe conventionnelle et reste sous contrôle territorial direct. Le sous-marin échappe aux conflits aériens tout en maintenant une connectivité physique contrôlée par des opérateurs identifiés. L'orbital soustrait les données froides à toute portée régionale, sous réserve que la juridiction de lancement reste politiquement cohérente avec les intérêts de l'organisation. Ces trois couches ne fonctionnent pas en silos. Elles fonctionnent comme les noeuds d'une architecture fédérée : distribuée pour qu'aucune frappe unique ne paralyse l'ensemble, mais contrôlée pour que la souveraineté sur chaque noeud reste clairement attribuée. Ce n'est pas une blockchain décentralisée sans autorité. C'est une fédération souveraine dans laquelle la confiance est redistribuée entre des acteurs qui se contrôlent mutuellement, exactement comme des États membres qui coopèrent sans se dissoudre. Ce document l'a démontré section par section : chaque solution proposée déplace la vulnérabilité sans l'éliminer. Le datacenter souterrain résiste à la bombe mais pas à la coupure d'électricité en surface. Le datacenter sous-marin échappe aux drones aériens mais pas aux drones sous-marins ni à la guerre acoustique. Le datacenter orbital échappe aux conflits régionaux mais pas aux missiles antisatellites des grandes puissances. Il faut nommer également un angle mort réglementaire : NIS2, CER et DORA imposent des tests de résilience calibrés sur des cyberattaques ou des défaillances techniques internes. Aucun de ces textes n'impose de tester la résistance à la destruction physique simultanée de deux régions cloud dans deux pays différents. Les événements de mars 2026 ont révélé un chantier réglementaire ouvert que ni les régulateurs ni les opérateurs ne peuvent ignorer. La résilience n'est pas une forteresse imprenable. C'est une architecture d'arbitrages conscients : choisir où déplacer le risque, à quel niveau de menace l'exposer, et s'assurer que si ce niveau est atteint, les dommages restent supportables. C'est pour cela qu'elle est une philosophie autant qu'une technique. La vraie résilience n'est pas la technologie. C'est la diversité d'infrastructure, la capacité à basculer vite, et la décision politique de ne plus dépendre d'un seul suzerain numérique. Parce que le château peut brûler. La forteresse, elle, doit tenir. ## Télécharger Lire le document (PDF) 37 pages · français · 41 références · 0,9 Mo Texte intégralement sélectionnable et citable Licence CC BY-NC-ND 4.0, sans inscription ## Notice bibliographique Titre Quand le cloud prend feu Auteur Nizar Younes Mqam, ORCID 0009-0008-5549-7620 Collection Cahiers de technopolitique, n° 1 Éditeur Nizar Younes Mqam, Tourcoing, France Directeur de publication Nizar Younes Mqam Date de publication Septembre 2026 (première édition : avril 2026) Langue Français DOI 10.5281/zenodo.22812311 Toutes versions : 10.5281/zenodo.22812310 Dépôt pérenne Zenodo, hébergé par le CERN ISSN En cours d'attribution Licence CC BY-NC-ND 4.0 ## Sources et références Toutes les sources ont été consultées et vérifiées entre le 1er mars et le 4 avril 2026. La numérotation est celle du document. Frappes iraniennes sur AWS : faits et chronologie - Rest of World, « Iranian drone attacks on Amazon's Gulf data centers », 9 mars 2026. https://restofworld.org/2026/iran-amazon-data-center-strikes/ - The Conversation, « Why Iran targeted Amazon data centers », 1 avril 2026. https://theconversation.com/why-iran-targeted-amazon-data-centers-278642 - Fortune, « Iran's attacks signal a new kind of war », 9 mars 2026. https://fortune.com/2026/03/09/irans-attacks-on-amazon-data-centers-in-uae-bahrain - Bloomberg, « How Amazon Data Centers Became a Casualty of Iran War », 5 mars 2026. https://bloomberg.com/news/articles/2026-03-05/how-amazon-data-centers-became-a-casualty-of-iran-war - Data Centre Magazine, « Iran Missiles Hit AWS Bahrain », 2 avril 2026. https://datacentremagazine.com/news/iran-missiles-hit-aws-cloud-infrastructure-in-bahrain - CNBC, « Data centers become military targets », 6 mars 2026. https://cnbc.com/2026/03/06/iran-war-data-centers.html Impact technique : AWS Health Dashboard et analyses - APIStatusCheck, « AWS Middle East Outage March 2026 », 3 mars 2026. https://apistatuscheck.com/blog/aws-middle-east-drone-strike-outage-march-2026 - Network World, « Amazon waives March AWS charges », 31 mars 2026. https://networkworld.com/article/4151880 - Cloudswitched, « AWS Suffers Historic Middle East Outage », 29 mars 2026. https://cloudswitched.com/news/aws-outage-200-billion-ai-investment-2026 Câbles sous-marins et connectivité mondiale - Rest of World, « U.S.-Iran war threatens Gulf AI infrastructure », mars 2026. https://restofworld.org/2026/us-iran-war-gulf-ai-submarine-cables/ - TeleGeography, « Submarine Cable Infrastructure and Hormuz », mars 2026. https://resources.telegeography.com/submarine-cable-infrastructure-strait-hormuz - Submarine Networks, « War in the Gulf Severs the World's Digital Arteries », mars 2026. https://submarinenetworks.com/en/nv/insights/war-in-the-gulf-severs-the-world-s-digital-arteries - German Marshall Fund, « Stuck in Hostile Waters », mars 2026. https://gmfus.org/news/stuck-hostile-waters Menaces sous-marines et guerre des fonds marins - Naval News, « Cable Attack: New Undersea Threat Is Starting To Reshape Naval Wars », février 2024. https://navalnews.com/naval-news/2024/02/cable-attack-new-undersea-threat-is-starting-to-reshape-naval-wars/ - Asia Times, « China's underwater drones push undersea power toward US shores », décembre 2025. https://asiatimes.com/2025/12/plans-big-underwater-drones-push-undersea-power-toward-us-shores/ - Internationale Politik Quarterly, « The Underwater Battlefield: Protecting Submarine Critical Infrastructure », janvier 2025. https://ip-quarterly.com/en/underwater-battlefield-protecting-submarine-critical-infrastructure - University of Washington / Jackson School, « Baltic Sea Undersea Cable Security », 2025. https://jsis.washington.edu/news/baltic-sea-undersea-cable-security/ - Blueye Robotics / SeaSEC, « Surveillance of Critical Underwater Infrastructure », mai 2025. https://blueyerobotics.com/blog/surveillance-of-critical-underwater-infrastructure-using-underwater-technology - Thales & FEBUS Optics, « Accord de co-développement pour la protection des infrastructures critiques sous-marines par surveillance acoustique distribuée », novembre 2024. Installations souterraines : référence empirique Natanz - Institute for Science and International Security, « Post-Attack Assessment of the First 12 Days of Israeli and U.S. Strikes on Iranian Nuclear Facilities », David Albright et Spencer Faragasso, 24 juin 2025. https://isis-online.org/isis-reports/post-attack-assessment-of-the-first-12-days-of-israeli-strikes-on-iranian-nuclear-facilities - Arms Control Association, « Iran's Nuclear Facilities: Status Updates », juin 2025. https://armscontrol.org/blog/2025-06-25/irans-nuclear-facilities-status-updates - New Civil Engineer, « What we know about Iran's underground nuclear facilities », juin 2025. https://newcivilengineer.com/latest/what-we-know-about-irans-underground-nuclear-facilities-19-06-2025/ Cadre réglementaire européen : NIS2, CER, DORA - Commission européenne, « CER and NIS-2 Directives enter into application », octobre 2024. https://ec.europa.eu/newsroom/cipr/items/859754/ - Bird & Bird, « Understanding NIS2, CER, and CRA », mars 2025. https://twobirds.com/en/insights/2025/understanding-key-eu-cybersecurity-legislative-acts-nis2,-cer,-and-cra - nFlo, « CER: six months to full implementation », janvier 2026. https://nflo.tech/knowledge-base/cer-six-months-critical-infrastructure-implementation/ Projets datacenters du futur - Microsoft Research, Project Natick. https://natick.research.microsoft.com/ - Data Centre Dynamics, « Project Natick: Microsoft's underwater voyage of discovery », janvier 2021. https://datacenterdynamics.com/en/analysis/project-natick-microsofts-underwater-voyage-discovery/ - Highlander / HiCloud, Hainan Undersea Data Center. https://www.highlander.com.cn - Data Center Dynamics, « China's HiCloud reports commercial underwater data center modules are working », 2024. https://www.datacenterdynamics.com/en/news/chinas-hicloud-reports-commercial-underwater-data-center-modules-are-working/ - Lumen Orbit, Orbital computing. https://lumorbit.com - Bahnhof AB, Pionen Data Center Stockholm. https://bahnhof.net/datacenter/pionen - JAXA et NEC, Communication laser inter-satellitaire LUCAS, 1,8 Gbps, janvier 2025. https://nec.com/en/press/202501/global_20250123_01.html Cadre intellectuel : géostratégie numérique et techno-géopolitique - Asma Mhalla, Technopolitique. Seuil, 2023. - Cédric Durand, Techno-féodalisme. La Découverte, 2020. - Frédérick Douzet, Chaire Castex de Cyberstratégie (2013–2018), IHEDN / Institut Français de Géopolitique (IFG) - Université Paris 8. Site Chaire Cyber IHEDN : https://cyber-ihedn.fr - IFG Paris 8 : https://www.univ-paris8.fr/Institut-francais-de-geopolitique-IFG - Abishur Prakash, analyses techno-géopolitiques. https://futuremoving.ca Probabilité Carrington - Riley, P. (2012). « On the probability of occurrence of extreme space weather events ». Space Weather, American Geophysical Union / NASA. https://doi.org/10.1029/2011SW000734 - Moriña, D., Serra, I., Puig, P., & Corral, Á. (2019). « Probability estimation of a Carrington-like geomagnetic storm ». Scientific Reports, Nature Publishing Group. https://doi.org/10.1038/s41598-019-38918-8 La perspective MENA/Maghreb - [REF-AT-1] Loi n°18-04, article 70, Journal officiel algérien. [REF-AT-2] Algérie Télécom, Catalogue d'Interconnexion 2025-2026, https://www.algerietelecom.dz/docs/document/autres/CATALOGUE-D-INTERCONNEXION-D-ALGERIE-TELECOM-2025-2026-14776.pdf - [REF-MEDUSA] Tunisie Telecom, câble sous-marin Medusa (Bizerte–Marseille, 22 Tbps), partenariat signé février 2025, inauguration novembre 2025. https://www.leaders.com.tn/article/37431-tunisie-telecom-celebre-l-atterrissement-du-cable-sous-marin-medusa-a-bizerte-un-tourna - [REF-ACE] Africa Coast to Europe Submarine Cable (ACE), 2022. https://ace-submarinecable.com/le-systeme-de-cable-ace-relie-desormais-leurope-lafrique-de-louest-et-lafrique-du-sud/ - [REF-ANRT] ANRT, Observatoires ANRT, Le Mémo T4-2024, mars 2026. https://anrt.ma/sites/default/files/2026-03/Observatoires%20ANRT%20-%20le%20Memo%20-%20T4-2025.pdf - [REF-CASIX] Internet Society Pulse / PeeringDB, Casablanca Internet Exchange Point, CAS-IX, données novembre 2025. https://pulse.internetsociety.org/fr/ixp-tracker/ixp/760/ - [REF-DM2030-1] Bulletin officiel n°7432, DGSSI Maroc (réglementaire). [REF-DM2030-2] Agence Ecofin / Reuters, « Cloud hybride et souveraineté : le Maroc annonce un nouveau datacenter de 500 MW », juillet 2025. + Bulletin officiel n°7432, référentiel de qualification cloud, 21 août 2025. https://www.agenceecofin.com/actualites-numerique/1107-129990 https://www.digital.ma/articles/le-maroc-impose-un-referentiel-cloud-pour-proteger-sa-souverainete-numerique Pour toute demande d'intervention, citation, ou collaboration sur les sujets traités dans ce document, contactez le Vice-président de MARAMM au : Email : geopolitics@maramm.org Linkedin : https://linkedin.com/in/nizar-mqam ## Pour citer ce document Mqam, N. Y. (2026). Quand le cloud prend feu. Cahiers de technopolitique, n° 1. https://doi.org/10.5281/zenodo.22812311 ## Lire aussi N° 3 · Étude · Septembre 2026 ### La donnée d'actif : la sortie devient gratuite, le modèle reste captif Au 12 janvier 2027, changer de fournisseur ne coûtera plus rien. Reste à savoir ce qu'on emporte. Les contrats promettent un « format raisonnable et courant », c'est à dire des tableaux. Le modèle du référentiel d'actifs, lui, ne part pas. 19 pages · 28 sources · PDF 136 Ko DOI 10.5281/zenodo.22836960 Lire la notice et télécharger N° 2 · Note · Septembre 2026 ### L'IA de maintenance : vous gardez la propriété, vous perdez la maîtrise Les contrats reconnaissent que vos données vous appartiennent. Leurs définitions rangent la couche dérivée du côté du fournisseur, et ce droit survit à la résiliation. Le règlement européen s'arrête au même endroit. 5 pages · 12 sources · PDF 253 Ko DOI 10.5281/zenodo.22818645 Lire la notice et télécharger ================================================================================ ## SOURCE : Cahiers n° 2, L'IA de maintenance : vous gardez la propriété, vous perdez la maîtrise (Note, DOI 10.5281/zenodo.22818645) URL : https://technopolitique.eu/cahiers/n2/ Cahiers de technopolitique, n° 2 · Note · Septembre 2026 Éditeur et directeur de la publication : Nizar Younes Mqam · Lieu d'édition : Tourcoing, France ISSN en cours d'attribution · Contact : y.nizar@proton.me · https://technopolitique.eu/cahiers/n2/ ORCID de l'auteur : https://orcid.org/0009-0008-5549-7620 Note n° 2 · Volet souveraineté et données d'actifs # L'IA de maintenance : vous gardez la propriété, vous perdez la maîtrise Nizar Younes Mqam ORCID 0009-0008-5549-7620 Note · 17 septembre 2026 · Cahiers de technopolitique, n° 2 Tous les contrats de plateformes de maintenance prédictive disent la même chose : vos données vous appartiennent. C'est exact, et c'est sans effet. Ce qui se joue n'est pas la propriété de la matière première, mais celle de ce qu'on en tire. ## Ce que les contrats vous accordent Deux fournisseurs publient leurs conditions en texte intégral et librement accessible. Les autres ne le font pas, ce qui est en soi une information, et j'y reviens. Samsara, dans ses Master Terms of Service mis à jour en juin 2026, ouvre son article 8.1 par une phrase sans ambiguïté : « Customer owns all Customer Data ». Siemens, dans son Universal Customer Agreement du 13 avril 2026, écrit à l'article 6.3 que « Siemens will not acquire any title to or ownership of Customer Content ». Vous êtes donc propriétaire. Sur ce point, aucun des deux ne triche. ## Et ce que leurs définitions reprennent La bascule ne se trouve pas dans les clauses de propriété, elle se trouve dans les définitions, quinze pages plus loin. Samsara définit les Usage Data comme les données agrégées relatives à l'usage de la plateforme, puis inclut ces Usage Data dans la définition des Services, et déclare enfin à l'article 10.1 que « Samsara and its licensors exclusively own all right, title and interest in and to the Services ». La boucle est fermée en trois renvois. Siemens procède autrement, plus directement. Son article 6.2 l'autorise à « collect and derive information, statistics, and metrics […] or from Customer Content » et à s'en servir pour « develop, and improve its products and services ». Et sa définition du Siemens IP englobe « algorithms, models » ainsi que « any improvement, modification, or derivative work ». Vous gardez donc le minerai. Le métal appartient à la fonderie. Reste le détail qui décide de tout, et que l'on ne lit qu'en cas de rupture. Chez Samsara, la licence d'exploitation des données du client « shall survive the termination of this Agreement », tandis que ces mêmes données « may be immediately deleted ». Chez Siemens, l'article 10.4 fait survivre l'article 6.2 à la résiliation, et le client dispose de trente jours pour récupérer son contenu avant qu'il ne soit effacé. Autrement dit : le jour où vous partez, ce que vous avez apporté disparaît de votre côté et demeure du sien. ## Le droit européen s'arrête exactement au même endroit Le règlement européen sur les données s'applique depuis le 12 septembre 2025. Il est ambitieux : son article 3 impose un accès par défaut, aisé, sécurisé, gratuit et dans un format lisible par machine aux données générées par l'usage d'un produit connecté. Son article 4 exige une mise à disposition « à un niveau de qualité identique à celui dont bénéficie le détenteur de données », en continu et en temps réel lorsque c'est pertinent. Son considérant 15 referme la porte. Les « informations dérivées ou déduites de ces données, qui sont le résultat d'investissements supplémentaires dans l'attribution de valeurs ou d'informations tirées des données, en particulier au moyen d'algorithmes complexes et propriétaires » ne relèvent pas du champ du règlement. La Commission le confirme dans sa fiche officielle : les données inférées ou dérivées sont hors périmètre. Le règlement garantit la matière première et abandonne le produit fini. Deux précisions achèvent le tableau. La définition des données de produit, à l'article 2, ne vise que celles « que le fabricant a conçu pour qu'elles puissent être extraites » : le périmètre du droit est fixé par l'architecture du fournisseur. Et l'obligation d'équivalence fonctionnelle en cas de changement de prestataire, à l'article 30, ne pèse que sur les services d'infrastructure. Les plateformes logicielles de maintenance ne doivent que des interfaces ouvertes. J'ai fait le compte sur le texte intégral : le règlement ne mentionne jamais les modèles entraînés. Pas une occurrence d'« intelligence artificielle ». Une seule d'« apprentissage automatique », à propos d'autre chose. ## Le levier existe, mais il est contractuel Il serait malhonnête d'en conclure que le propriétaire d'actif est désarmé. Le règlement lui donne deux appuis sérieux, à condition qu'il s'en saisisse. L'article 4, paragraphe 13, interdit au détenteur d'utiliser les données non personnelles autrement que « sur la base d'un contrat avec l'utilisateur », et lui défend d'en tirer des informations sur les actifs ou les méthodes de production de l'utilisateur d'une manière portant atteinte à sa position commerciale. L'article 13, paragraphe 5, présume abusive la clause imposée unilatéralement qui permettrait d'accéder aux données de l'autre partie et de les utiliser en portant gravement atteinte à ses intérêts légitimes. Ces deux articles ne s'appliquent pas tout seuls. Ils se plaident, ou mieux, ils se négocient avant signature. Ce que vous n'écrivez pas dans le contrat, le règlement ne l'écrira pas à votre place. ## Ce que l'affaire Deere a tranché, et comment En janvier 2025, la Federal Trade Commission et cinq États américains assignent Deere devant le tribunal fédéral de l'Illinois. Le grief porte sur l'outil de diagnostic Service ADVISOR, réservé au réseau de concessionnaires. Un règlement transactionnel est annoncé en juillet 2026, sous forme d'ordonnance de dix ans. Le point remarquable n'est pas l'issue, c'est la rédaction du remède. Il est écrit en capacités de données : pouvoir lire et effacer les codes défaut, reprogrammer un calculateur, apparier une pièce de rechange, sortir une machine du mode dégradé. Jamais en termes de propriété. Le même déplacement s'observe ailleurs. Les principes publiés par l'IATA en octobre 2024 sur les données opérationnelles d'aéronefs demandent l'accessibilité « dans le format généré par l'aéronef ». L'ISO 55013:2024, qui porte précisément sur la gestion des actifs de données, traite d'interopérabilité et de préservation numérique, et exclut explicitement de son champ toute méthode de valorisation. Trois sources indépendantes, dans trois univers sans rapport. Aucune ne parle de titre. Toutes parlent de maîtrise opérationnelle et de format. ## Ce qu'un maître d'ouvrage peut exiger L'enseignement est directement transposable au cahier des charges. Écrivez vos exigences en capacités et en formats, pas en propriété, car la propriété vous sera concédée sans effort et ne vous apportera rien. Quatre exigences tiennent en quelques lignes et changent la nature du contrat. L'extraction continue de vos données brutes dans un format ouvert et documenté, pendant toute la durée du contrat. L'accès non seulement aux sorties du modèle, mais aux variables d'entrée qui les produisent. Un droit d'export à la résiliation, avec un délai et un format écrits noir sur blanc, plutôt que les trente jours par défaut d'un contrat que vous n'avez pas négocié. Et l'encadrement explicite de l'usage des données dérivées hors exécution du contrat, que l'article 4 du règlement européen vous autorise précisément à poser. L'ISO 55001:2024 vous en donne le cadre, et peu de praticiens l'ont remarqué : son édition 2024 a introduit une clause 7.6 consacrée aux données et à l'information, qui n'existait pas auparavant. Couplée à la clause 8.3 sur les processus, produits, technologies et services fournis par l'extérieur, elle offre un ancrage normatif à ce qui ressemblerait sinon à une exigence d'humeur. La norme fournit le cadre, le contrat fournit les dents. ## Ce qu'on ne sait pas, et qui compte Deux fournisseurs publient leurs conditions. Je n'ai trouvé aucun texte contractuel public pour GE Vernova APM, Schneider EcoStruxure, ABB Ability, SAP APM, Hitachi, ni pour Siemens Senseye en propre. AVEVA publie bien un document, mais sa seule mention de l'apprentissage automatique sert à décliner toute responsabilité sur l'exactitude des sorties, sans dire un mot de l'usage des données clients. Le marché se mesure aussi mal qu'il se documente. Eurostat n'a interrogé qu'une seule fois les entreprises européennes sur l'usage de l'internet des objets pour la maintenance conditionnelle, en 2021 : 6,92 % des entreprises de dix salariés et plus, 21,43 % au-delà de deux cent cinquante. Son enquête 2025 sur l'intelligence artificielle, qui recense pourtant nombre de finalités, ne comporte aucune catégorie « maintenance prédictive ». Quant au gain souvent annoncé de 25 à 30 %, il figure bien dans le guide de référence du département américain de l'énergie, mais y est attribué à des enquêtes indépendantes qui ne sont jamais nommées. Le seul chiffre traçable de ce document est de 8 à 12 % par rapport à une maintenance préventive seule. Un marché qui se mesure aussi mal est un marché où l'acheteur négocie à l'aveugle. C'est précisément là que se creuse la dépendance : non pas dans une clause abusive, mais dans un déséquilibre d'information que personne n'a organisé et dont tout le monde s'accommode. ## Télécharger Lire la note (PDF) 5 pages · français · 12 sources · 253 Ko · texte sélectionnable et citable ## Notice bibliographique Titre L'IA de maintenance : vous gardez la propriété, vous perdez la maîtrise Auteur Nizar Younes Mqam, ORCID 0009-0008-5549-7620 Collection Cahiers de technopolitique, n° 2, format Note Éditeur Nizar Younes Mqam, Tourcoing, France Date de publication Septembre 2026 Langue Français DOI 10.5281/zenodo.22818645 DOI de concept, toutes versions : 10.5281/zenodo.22818644 Dépôt pérenne Zenodo, hébergé par le CERN ISSN En cours d'attribution Licence CC BY-NC-ND 4.0 ## Sources et références - Règlement (UE) 2023/2854 du 13 décembre 2023 sur des règles harmonisées portant sur l'équité de l'accès aux données et de l'utilisation des données. EUR-Lex, CELEX 32023R2854. Articles 2, 3, 4, 13, 29, 30, 31 et 50 ; considérants 15 et 25. - Commission européenne, Data Act explained, digital-strategy.ec.europa.eu. - Samsara, Master Terms of Service, mise à jour de juin 2026, articles 8.1, 10.1, 18.29 et 18.34. - Siemens, Universal Customer Agreement version 1.3 du 13 avril 2026, articles 3.6, 6.2, 6.3 et 10.4, et définition du Siemens IP. - AVEVA, Software Schedule PO/APM/MC version 6.0, juin 2026, article 3.5. - Federal Trade Commission et cinq États contre Deere & Company, tribunal fédéral du district nord de l'Illinois, affaire 3:25-cv-50017, plainte du 15 janvier 2025, règlement transactionnel annoncé le 8 juillet 2026. L'homologation par le juge n'était pas confirmée au 17 septembre 2026. - IATA, principes relatifs aux données opérationnelles d'aéronefs, 2 octobre 2024. GE, Pratt & Whitney et Boeing n'en sont pas signataires. - Eurostat, série isoc_eb_iot, indicateur E_IOTDMTN1, enquête 2021. - Eurostat, série isoc_eb_ai, enquête 2025. - Department of Energy des États-Unis, Operations and Maintenance Best Practices Guide, version 3.0, PNNL-19634, 2010, section 5.4. - ISO 55001:2024, Gestion d'actifs, systèmes de management, exigences, deuxième édition, juillet 2024, clauses 7.6 et 8.3. - ISO 55013:2024, Guidance on the management of data assets. ## Pour citer cette note Mqam, N. Y. (2026). L'IA de maintenance : vous gardez la propriété, vous perdez la maîtrise. Cahiers de technopolitique, n° 2. https://doi.org/10.5281/zenodo.22818645 © 2026 Nizar Younes Mqam. Publié en accès ouvert sous licence Creative Commons Attribution – Pas d'Utilisation Commerciale – Pas de Modification 4.0 International (CC BY-NC-ND 4.0). Partage et citation autorisés avec attribution ; modification et usage commercial interdits. creativecommons.org/licenses/by-nc-nd/4.0/deed.fr ================================================================================ ## SOURCE : Cahiers n° 3, La donnée d'actif : la sortie devient gratuite, le modèle reste captif (Étude, DOI 10.5281/zenodo.22836960) URL : https://technopolitique.eu/cahiers/n3/ PDF : https://technopolitique.eu/cahiers/n3/donnee-actif-sortie-gratuite-modele-captif.pdf Cahiers de technopolitique, n° 3 · Étude · Septembre 2026 Éditeur et directeur de la publication : Nizar Younes Mqam · Lieu d'édition : Tourcoing, France ISSN en cours d'attribution · DOI : 10.5281/zenodo.22836960 · Contact : y.nizar@proton.me ORCID de l'auteur : https://orcid.org/0009-0008-5549-7620 Étude n° 3 · Volet souveraineté et données d'actifs # La donnée d'actif : la sortie devient gratuite, le modèle reste captif Nizar Younes Mqam ORCID 0009-0008-5549-7620 Étude · 18 septembre 2026 · Cahiers de technopolitique, n° 3 Au 12 janvier 2027, changer de fournisseur de cloud ne coûtera plus rien. En France, c'est déjà le cas depuis un arrêté du 17 novembre 2025. Reste à savoir ce qu'on emporte. Les contrats promettent un « format raisonnable et courant », c'est à dire des tableaux. Ce qui ne part pas, c'est le modèle : la hiérarchie fonctionnelle, les classifications, les règles. Et le règlement qui organise la sortie l'exclut dans sa définition même. ## La sortie devient gratuite, et la France est en avance Le chapitre VI du règlement européen sur les données est applicable depuis le 12 septembre 2025. Il est plus ambitieux qu'on ne le dit. Son article 23 impose aux fournisseurs de supprimer les obstacles « précommerciaux, commerciaux, techniques, contractuels et organisationnels » au départ d'un client, vers un autre fournisseur ou vers une infrastructure sur site. Son article 25 encadre le calendrier : préavis maximal de deux mois, période transitoire de trente jours calendaires pendant laquelle le contrat continue de s'appliquer, période de récupération d'au moins trente jours ensuite. Et il oblige le fournisseur à « concourir à la stratégie de sortie du client », formule qui n'existait dans aucun contrat avant lui. L'article 29 fixe le calendrier de l'argent. Des frais réduits restent facturables jusqu'au 12 janvier 2027. À cette date, tout frais de changement de fournisseur devient interdit. C'est une date qu'un directeur des actifs devrait avoir dans son échéancier, au même titre qu'une date de renouvellement de contrat. La France a pris de l'avance, et il faut être précis sur la façon dont elle l'a fait, parce qu'on lit souvent l'inverse. La loi SREN du 21 mai 2024 n'interdit pas les frais de sortie. Son article 27 interdit de facturer des frais de transfert de données « supérieurs aux coûts supportés par le fournisseur et directement liés à ce changement », et renvoie, pour le plafond, à un arrêté du ministre chargé du numérique pris sur proposition de l'ARCEP. C'est une tarification au coût, pas une gratuité. La gratuité est venue de l'arrêté. L'ARCEP a proposé, par sa décision n° 2025-0340 du 20 février 2025, de fixer ce plafond à zéro euro. La ministre déléguée chargée de l'intelligence artificielle et du numérique l'a suivie par un arrêté du 17 novembre 2025, publié le 30 novembre. Le 2 juillet 2026, l'ARCEP a complété le dispositif par deux jeux de lignes directrices, l'un sur les coûts imputables aux frais de changement autres que le transfert de données, l'autre sur le multi-cloud. Cette avance française n'est pas théorique, et elle se lit dans les conditions des fournisseurs eux-mêmes. La page des conditions d'utilisation d'IBM Cloud, mise à jour le 26 août 2026, comporte deux paragraphes voisins. Sous l'intitulé « EU Data Act », un client européen qui migre ses données « bénéficie de frais de sortie réduits ». Sous l'intitulé « French SREN Law », un client français « n'est pas facturé » de frais de sortie. Le même fournisseur, la même page, deux régimes. Le règlement européen produit, à ce jour et chez l'un des plus gros opérateurs mondiaux, une remise. La loi française produit un zéro. On pourrait s'arrêter là et conclure que la dépendance se dissout. Ce serait une erreur de lecture, et le reste de cette étude consiste à montrer pourquoi. Ce que ces textes rendent gratuit, c'est le déplacement des octets. Pas la restitution de ce qui leur donne un sens. ## Quatre exclusions, toutes dans le texte Un référentiel d'actifs n'est pas une liste. C'est une liste plus une organisation : une hiérarchie fonctionnelle qui dit quel équipement appartient à quel système et quel système à quelle installation, des classifications qui disent ce qu'est une pompe et ce qui compte comme une défaillance, des attributs, des unités, des règles de criticité, des seuils. Un exploitant met dix ou quinze ans à constituer cet ensemble. C'est lui, et non la liste des numéros de série, qui permet de décider quoi remplacer et quand. Le règlement organise la portabilité des données. Il n'organise pas la portabilité de cette organisation. Et il le dit, quatre fois, dans son propre texte. Premièrement, la définition. L'article 2, point 38 définit les « données exportables » comme les données d'entrée et de sortie et les métadonnées générées par l'utilisation du service, « à l'exclusion des actifs ou des données protégés par des droits de propriété intellectuelle, ou constituant un secret d'affaires, des fournisseurs de services de traitement de données ou des tiers ». L'exclusion n'est pas une dérogation ajoutée plus loin, ni une exception à invoquer. Elle est dans la définition. Ce que vous avez le droit d'emporter est défini par soustraction de ce que le fournisseur revendique. Deuxièmement, la clause. L'article 25, paragraphe 2, point f) exige que le contrat comporte « une spécification exhaustive des catégories de données spécifiques au fonctionnement interne du service de traitement de données du fournisseur qui doivent être exclues des données exportables [...] lorsqu'il existe un risque de violation des secrets d'affaires du fournisseur ». Le texte impose donc au contrat de lister ce que vous n'emporterez pas. C'est une obligation de transparence, ce qui vaut mieux que le silence, mais c'est une obligation de transparence sur une privation. Troisièmement, la garantie s'arrête à l'infrastructure. L'article 30, paragraphe 1, réserve l'équivalence fonctionnelle, c'est à dire la promesse de retrouver ailleurs un service qui fait la même chose, aux fournisseurs de « ressources informatiques modulables et variables limitées à des éléments d'infrastructure tels que les serveurs, les réseaux et les ressources virtuelles [...], sans donner accès aux services, logiciels et applications d'exploitation ». Autrement dit, l'infrastructure seule. Une gestion de maintenance assistée par ordinateur, un système de gestion d'actifs, une plateforme de maintenance prédictive relèvent du paragraphe 2, qui ne demande que des « interfaces ouvertes », et du paragraphe 5, qui ne demande, à défaut de spécifications communes publiées, qu'un export « dans un format structuré, couramment utilisé et lisible par machine ». Un fichier de valeurs séparées par des virgules satisfait cette exigence. Le paragraphe 6 du même article ajoute que les fournisseurs « ne sont pas tenus de développer de nouvelles technologies ou de nouveaux services, ou de divulguer ou transférer des actifs numériques qui sont protégés par des droits de propriété intellectuelle ou qui constituent un secret d'affaires ». Quatrièmement, le sur-mesure est exempté. L'article 31, paragraphe 1, écarte les obligations de l'article 23 point d), de l'article 29 et de l'article 30 paragraphes 1 et 3 pour les services « dont la majorité des caractéristiques principales ont été conçues sur mesure pour répondre aux besoins spécifiques d'un client particulier [...] et lorsque ces services ne sont pas proposés à grande échelle sur le plan commercial par l'intermédiaire du catalogue de services du fournisseur ». Il faut être honnête sur la portée de cette dernière exclusion : un déploiement de progiciel lourdement paramétré n'est pas, en principe, un service conçu sur mesure au sens du catalogue. Le règlement vise le développement spécifique, pas la configuration. Mais la frontière n'est définie nulle part, et le texte confie au fournisseur le soin d'informer le client, avant la signature, des obligations qui ne s'appliqueront pas. Une déclaration unilatérale, faite au moment où le client a le moins de raisons d'y prêter attention. ## La Commission savait, et a légiféré sur la moitié facile Ce découpage entre l'infrastructure et le logiciel n'est pas un accident de rédaction. Il était documenté, par la Commission elle-même, dans l'analyse d'impact qui accompagne la proposition de règlement, en février 2022. Le passage mérite d'être lu en entier : L'absence de normes communes est également un problème très pertinent pour la portabilité effective des données et pour la capacité à changer de service de cloud et de périphérie. C'est la cause technique la plus importante de la captivité vis à vis du fournisseur, en particulier pour les services qui vont au delà du simple stockage. Des formats de données, des sémantiques de données ou des architectures de données différentes conduisent à des résultats différents sur la base des mêmes données, et cela empêche une application donnée d'être maintenue après le changement. Si l'interopérabilité technique des services de simple stockage peut être plus facile en théorie, au niveau du logiciel en service elle constitue un obstacle prohibitif. La Commission écrit donc, en 2022, que l'obstacle est prohibitif au niveau applicatif, et qu'il tient aux sémantiques et aux architectures de données. Puis le règlement, en 2023, réserve l'équivalence fonctionnelle au seul stockage. L'obstacle identifié comme le plus important est celui que le texte ne traite pas. On objectera qu'il fallait bien commencer, et que l'article 30 paragraphe 3 prévoit la suite : les fournisseurs de logiciels devront assurer la compatibilité avec des spécifications communes ou des normes harmonisées, douze mois après leur publication dans un répertoire central de l'Union. Le mécanisme existe. Mais il n'a pas commencé à courir. Le plan de route de la Commission pour la normalisation, dans son édition 2025, indique que l'article 35 paragraphe 8 « oblige la Commission à construire ce répertoire par voie d'actes d'exécution », et que « pour préparer ce répertoire, la Commission lancera une étude » chargée de cartographier les normes et spécifications existantes susceptibles d'y figurer. Cette étude a rendu ses résultats le 23 février 2026, et la page qui les publie indique qu'elle vise à préparer « la première salve » de spécifications ouvertes. Au 18 septembre 2026, je n'ai trouvé aucune publication du répertoire. Je ne conclus pas qu'il n'existe pas ; je dis que je ne l'ai pas trouvé, et que les documents officiels les plus récents le décrivent encore au futur. Tant qu'il est vide, c'est le paragraphe 5 qui s'applique : un export lisible par machine. Des tables. Une note, au passage, sur ce qui a été essayé avant. La même page de la Commission rappelle que les codes de conduite SWIPO, dispositif d'autorégulation censé organiser volontairement la portabilité et le changement de fournisseur, « n'ont finalement pas rencontré l'adhésion souhaitée du marché ». L'autorégulation a été tentée, et la Commission constate elle-même qu'elle a échoué. C'est un argument qu'il est honnête de rappeler à ceux qui proposent d'y revenir. ## Ce que les contrats s'engagent à rendre Passons du texte général aux engagements réels. Le contrat cadre cloud d'IBM, dans sa version publiée pour IBM Cloud International B.V., référence Z126-6304-IBMCIBV_13_ZZ_08-2023, publiée le 7 décembre 2023, comporte dix-sept pages. L'article qui traite du sort du contenu client est intitulé, littéralement, « Removal of Content », retrait du contenu, et non restitution. Son contenu est le suivant : IBM restituera ou retirera le Contenu de ses ressources informatiques à l'expiration ou à la résiliation des Services Cloud [...] IBM peut facturer certaines activités effectuées à la demande du Client, comme la livraison du Contenu dans un format spécifique. Et, dans les dispositions sur la résiliation : À la résiliation, IBM peut assister le Client dans la transition vers une autre technologie moyennant un coût supplémentaire et selon des conditions convenues séparément. Il faut mesurer ce que ces deux phrases articulent. La restitution du contenu est due, et gratuite. La restitution du contenu sous une forme déterminée est une prestation facturable. L'assistance à la transition est facturable et, qui plus est, soumise à des conditions qui restent à négocier. Or ces conditions se négocient au moment du départ, c'est à dire au moment précis où le client a le moins de pouvoir : il a annoncé qu'il partait, il n'a plus rien à promettre, et son calendrier est déjà engagé chez le repreneur. Une précision d'équité, qui a son importance. Ce document est daté d'août 2023 et publié en décembre 2023, soit avant l'applicabilité du chapitre VI le 12 septembre 2025. Les mots « Data Act », « 2023/2854 », « portabilité » et « interopérabilité » n'y figurent nulle part, ce qui n'est pas un manquement mais une question de date. Ce que la clause documente, ce n'est pas une infraction, c'est l'état du droit contractuel juste avant que le règlement ne s'y applique. Elle sert ici de point de comparaison, pas d'accusation. Le descriptif de services français d'IBM Cloud, référence i126-6605-28, publié le 9 avril 2024, ajoute une asymétrie de préavis qui dit quelque chose de la structure de la relation. IBM s'engage à prévenir douze mois à l'avance avant d'interrompre une fonctionnalité essentielle ou d'introduire « toute modification non rétrocompatible d'une API », et douze mois avant de retirer un service. Mais le délai tombe à trente jours pour une hausse de prix ou pour une modification du descriptif de services lui même, celui qui porte les conditions de sortie, et à quatre-vingt-dix jours pour une modification de niveau de service défavorable. Le texte précise qu'« en continuant d'utiliser les Services Cloud après la période de préavis, le Client accepte les modifications ». Douze mois pour l'interface technique, trente jours pour les conditions de la sortie, et le silence vaut acceptation. La hiérarchie des protections est explicite, et elle ne place pas la sortie au sommet. ## La même question posée à trois fournisseurs Comparer des engagements contractuels est d'ordinaire impossible, parce que chaque contrat pose ses propres questions. Il existe une exception, et elle est publique. Le cadre d'achat britannique G-Cloud, dont le catalogue est publié par le gouvernement, impose à tous les fournisseurs de répondre aux mêmes questions normalisées, dont deux nous intéressent directement : « approche d'export des données » et « extraction des données en fin de contrat ». Les réponses sont publiques, datées, et opposables au fournisseur. Poser la même question à trois éditeurs de systèmes de gestion d'actifs devient donc un exercice reproductible : n'importe quel lecteur peut refaire la vérification. Voici les trois réponses, telles qu'elles figuraient au 18 septembre 2026. IBM, Maximo Application Suite. Extraction en fin de contrat : « IBM restituera les Données du Client dans un délai raisonnable et dans un format raisonnable et courant, sur instruction écrite du Client avant la résiliation ou l'expiration. » Approche d'export : « Les données peuvent être exportées de la solution sous forme Excel à partir des rapports tabulaires. Les graphiques peuvent être exportés en PDF ou en images. » Formats déclarés : valeurs séparées par des virgules, et XML. Hexagon, Octave Attune EAM, anciennement HxGN EAM. « Hexagon fournit un jeu de données complet à la résiliation du contrat. Le client est responsable de l'extraction de toute donnée intermédiaire avant la résiliation. Des options payantes supplémentaires sont disponibles [...] pour une assistance renforcée à l'extraction des données. » Formats : Excel, HTML, PDF, XML. F0CUS Work and Asset Management. « En fin de contrat, nous désignerions un développeur F0CUS pour travailler à une extraction complète de la base de données du client et des médias associés. Nous fournirions : une copie de sauvegarde de l'instance du client, sous forme de fichier .bak ou .bacpac [...] » Et, dans la description du processus de sortie : « Fournir les schémas de processus et les manuels utilisateurs au nouveau prestataire. » Le résultat contredit ce qu'on attend, et c'est ce qui le rend intéressant. Ce n'est pas le plus gros éditeur qui livre le plus. Les deux acteurs mondiaux livrent des tableaux, l'un dans un « format raisonnable et courant » dont la définition reste à leur main, l'autre en facturant l'assistance à l'extraction. Le plus petit fournisseur des trois livre la base complète et la documentation des processus, c'est à dire à la fois le contenant, le contenu et le mode d'emploi. On peut en tirer deux conclusions, et il faut les distinguer. La première est technique : une sauvegarde de base de données dans un format propriétaire de système de gestion de bases de données n'est pas davantage portable qu'un fichier de valeurs séparées par des virgules ; elle n'est exploitable que par qui peut remonter le même schéma. La générosité de F0CUS n'est donc pas une solution universelle. La seconde est structurelle, et elle est la vraie leçon : la contrainte n'est pas technique, elle est commerciale. Rien n'empêchait les deux grands d'offrir la même chose. Plus la base installée est large, plus l'engagement de sortie est mince. Un point de droit, à surveiller plutôt qu'à trancher. L'assistance à l'extraction facturée en option supplémentaire devra être réexaminée à l'aune de l'article 29 paragraphe 1 du règlement au 12 janvier 2027. Je n'affirme pas qu'elle sera illicite : l'analyse dépend du contrat concerné, de la qualification exacte de la prestation et du régime applicable au client. Je dis que la date est connue, qu'elle est proche, et qu'un acheteur peut s'en servir dès maintenant dans une négociation. ## Le modèle n'est pas un secret, et c'est plus grave Il serait commode d'écrire ici que les éditeurs dissimulent le modèle de données de leurs systèmes. Ce serait faux, et vérifiable comme tel en trois clics. Le dictionnaire d'objets de Maximo, ses structures d'objets, son interface de programmation et sa documentation de migration sont publiquement accessibles. On peut lire, sans licence et sans contrat, quelle table porte les équipements et quelle table porte les emplacements. Le schéma n'est pas un secret d'affaires. Cette constatation ne détruit pas la thèse, elle la précise, et elle la rend plus dérangeante. Si le schéma est public et que la sortie reste difficile, alors la difficulté n'est pas dans le schéma. Elle est dans ce que l'organisation a déposé dedans. Un référentiel d'actifs en exploitation n'est pas un schéma, c'est un schéma rempli. La hiérarchie fonctionnelle qui rattache chaque pompe à sa station et chaque station à son réseau a été construite par des ingénieurs, arbitrage après arbitrage. Les codes de défaillance ont été choisis, discutés, parfois inventés. Les seuils de criticité encodent une politique de risque. Les règles de déclenchement des interventions encodent une doctrine de maintenance. Rien de tout cela n'est protégé par un droit de propriété intellectuelle du fournisseur : c'est le travail du client. Et pourtant rien de tout cela ne se trouve dans un export tabulaire, parce qu'un export tabulaire transporte des valeurs, pas des raisons. La norme, ici, est du côté du client, et c'est ce qui rend la situation absurde. L'ISO 55001:2024, dans sa clause 7.6 consacrée aux données et aux informations, exige de l'organisme qu'il : a) détermine les données et les informations requises pour soutenir la gestion d'actifs ; b) détermine les spécifications des données et des informations, y compris les attributs, les unités de mesure, la qualité, et la source ; c) développe un plan pour la collecte, l'intégration, l'amélioration de la qualité et le partage des données et des informations. Le point b) est sans ambiguïté : la spécification des données est une obligation de l'organisme. Pas du fournisseur. La norme met à la charge de l'exploitant la définition du modèle qu'il utilise. Dans la pratique, cette spécification est presque toujours produite, détenue et maintenue par l'éditeur du logiciel et son intégrateur, et le client la découvre le jour où il veut partir. L'organisme certifié ISO 55001 se conforme à une exigence dont il n'a pas la maîtrise. La clause 7.6 ajoute d'ailleurs une exigence que peu d'exploitants savent devoir satisfaire : l'alignement, la cohérence et la traçabilité des informations et de la terminologie entre les fonctions financières et non financières. Autrement dit, le même actif doit porter le même nom et la même identité dans la comptabilité et dans l'atelier. Cette exigence suppose un modèle commun, indépendant des deux systèmes qui l'hébergent de part et d'autre. L'ISO 55013:2024, publiée en juillet 2024, nomme enfin ces données comme des actifs à part entière. C'est une ligne directrice de vingt pages, et il faut dire ce qu'elle ne fait pas : son résumé officiel précise qu'elle « ne fournit pas de méthodologies pour dériver ou apprécier la valeur des actifs de données », ni pour en dériver des valeurs financières, ni même d'orientation sur la nécessité de le faire. On reconnaît donc que la donnée d'actif est un actif, et on renonce à la valoriser. Tant qu'une chose n'a pas de valeur inscrite, personne ne défend sa propriété dans une négociation. ## Ce que coûte l'information qui ne circule pas Ce coût a été mesuré une fois, sérieusement, et il est ancien. En 2004, l'institut national des normes et de la technologie des États-Unis a publié une étude conduite pour lui par RTI International et le Logistics Management Institute, sous la référence GCR 04-867. Elle porte sur le coût de l'interopérabilité insuffisante dans l'industrie des installations, c'est à dire les grands bâtiments commerciaux, institutionnels et industriels. Cent cinq entretiens, soixante-dix organisations, une enquête en ligne, des coûts moyens au pied carré extrapolés à un parc de trente-sept milliards de pieds carrés. La méthode vaut d'être décrite, parce qu'elle définit exactement notre sujet. Le coût est obtenu en comparant la situation réelle à un scénario contrefactuel dans lequel l'échange, la gestion et l'accès aux données seraient fluides, ce qui, écrivent les auteurs, « implique que l'information n'ait besoin d'être saisie qu'une seule fois et soit ensuite disponible pour toutes les parties prenantes, instantanément ». Tout l'écart entre ce monde et le nôtre constitue la facture. Les résultats : - 15,8 milliards de dollars par an pour l'année 2002, soit entre 1 et 2 % du chiffre d'affaires du secteur. - Les deux tiers sont supportés par les propriétaires et exploitants, très précisément 10,6 milliards, soit 68 % du total. - 85 % de la facture des exploitants tombe en phase d'exploitation et de maintenance, soit environ 9 milliards de dollars pour la seule année 2002. - Parmi les postes de coût figurent explicitement les coûts de ressaisie manuelle et les coûts de traduction de données. Le diagnostic porté sur les exploitants est celui qu'on entend encore dans n'importe quelle salle de gestion de maintenance : « un temps démesuré est consacré à localiser et à vérifier des informations précises sur les installations et les projets, issues d'activités antérieures », et « les problèmes de données héritées constituent une préoccupation majeure pour les propriétaires et exploitants », qui reçoivent au fil des ans des informations dans des formats disparates, lesquelles « ne reflètent pas toujours la configuration réelle des installations ». Trois réserves, que je préfère poser moi-même. Ce chiffre date de 2002. Il est américain. Et il porte sur des bâtiments, pas sur des réseaux d'eau, d'énergie ou de transport. Je ne le réactualise pas en euros d'aujourd'hui, ce qui reviendrait à fabriquer un chiffre que personne n'a mesuré. Il faut aussi noter que les auteurs le déclarent eux-mêmes conservateur : les pertes d'opportunité ont été écartées du calcul « en raison de leur caractère hautement spéculatif », et les locataires sont hors périmètre. Ce qui frappe, à vingt-deux ans de distance, n'est pas la précision du montant. C'est que le problème ait été identifié, quantifié et publié par une institution publique en 2004, et que le premier texte européen à s'y attaquer date de 2023, en réservant sa garantie la plus forte au seul stockage. ## Birmingham, ou le remède qui consiste à effacer sa configuration Le mécanisme se lit à nu dans un cas documenté par deux documents publics, et non par la presse : les recommandations statutaires de l'auditeur externe, et les comptes statutaires de la collectivité. En septembre 2023, l'auditeur externe du conseil municipal de Birmingham, la plus grande collectivité locale d'Europe par la population, adresse à celle-ci des recommandations statutaires prises sur le fondement de la loi britannique sur l'audit local. Sur le système de gestion intégré mis en service en avril 2022, il écrit : Le Conseil a connu des problèmes importants pendant et à la suite de la mise en œuvre de son nouveau système de planification des ressources, ce qui entraîne des coûts supplémentaires anticipés (coût total de 100 millions de livres contre un budget initial de 38,7 millions approuvé par le Cabinet en mars 2021). [...] En raison de ces problèmes, le Conseil a été dans l'incapacité de produire ses comptes pour l'exercice 2022-2023. Sur la cause, l'auditeur est précis : la mise en service avait été classée « rouge » avant le démarrage, et « le système financier comportait plusieurs adaptations qui n'ont pas fonctionné correctement par la suite ». Les comptes statutaires de l'exercice clos le 31 mars 2024, un document de deux cent cinquante-neuf pages soumis à audit, donnent la suite. Le système « continue d'imputer des écritures incorrectement », et un travail manuel important reste nécessaire. Sur les cent millions dépensés, le Conseil a décidé de « n'inscrire à l'actif que ce qui a été jugé un montant approprié, soit 19,6 millions de livres, tout le reste étant passé en charges ». Et le Conseil s'attend à devoir imposer « une limitation de l'étendue des travaux d'audit externe » après la remise en service. Mais le détail décisif est ailleurs, et c'est celui pour lequel ce cas figure dans cette étude. La décision prise en mai 2024 est de réimplanter le système en version standard, en supprimant les personnalisations, et de s'appuyer sur « les fonctionnalités standard éprouvées, utilisées avec succès par d'autres collectivités ». Autrement dit : l'organisation avait passé des années à façonner le système à sa manière, et le remède retenu a consisté à effacer ce travail pour adopter le modèle de l'éditeur. La sémantique accumulée n'a pas été portée ailleurs, ni documentée, ni transmise. Elle a été abandonnée. C'est la forme la plus radicale de ce que cette étude décrit : quand le modèle n'est pas détenu, la seule sortie praticable est la reddition. Deux réserves, encore, et elles sont importantes. Il s'agit d'un système de gestion financière et de ressources humaines, non d'un référentiel d'actifs : ce qui se transpose est le mécanisme, pas le périmètre. Et l'auditeur écrit noir sur blanc que « les dispositions de gestion du Conseil pour la mise en œuvre étaient inadéquates ». Une part de ce qui s'est produit tient à la gouvernance de la collectivité elle-même, et il serait malhonnête d'en imputer la totalité au fournisseur. La recommandation statutaire numéro sept dit d'ailleurs l'essentiel : « à plus long terme, l'Autorité devra veiller à reconstruire sa propre capacité et sa propre compétence informatiques ». ## Le régulateur qui ne peut pas conclure Si la thèse est juste, ses effets ne devraient pas se limiter à l'exploitant. Ils devraient remonter jusqu'à celui qui surveille l'exploitant. C'est exactement ce qu'on observe, et le constat est public. En décembre 2024, le régulateur de l'eau en Angleterre et au pays de Galles publie, dans le cadre de ses déterminations tarifaires, une feuille de route sur la compréhension de l'état de santé des actifs du secteur. Il y énumère lui-même les obstacles qui empêchent de comparer l'état des actifs entre compagnies. Le premier de la liste : Des systèmes d'entreprise différents sont utilisés pour gérer et enregistrer les données d'actifs essentielles, par exemple la gestion des ordres de travail et le signalement des défaillances. Suivent la qualité inégale des données selon l'historique de chaque compagnie, les interprétations divergentes des définitions, « par exemple de ce qui constitue la défaillance d'un actif », les stratégies de maintenance hétérogènes, et enfin : Des approches incohérentes de la définition des hiérarchies d'actifs et des groupes d'actifs, par exemple selon la façon dont les compagnies considèrent les actifs électriques, mécaniques et de génie civil. Le régulateur conclut la section ainsi : « des travaux sont en cours sur la normalisation des définitions et de la modélisation, mais il n'existe à ce jour aucune approche commune appliquée dans le secteur ». Il a pourtant exercé son pouvoir. Dans le cadre de ses déterminations provisoires, il a émis une demande formelle d'informations portant sur l'état des actifs et la charge de travail, adressée à des compagnies sur lesquelles il dispose d'un pouvoir d'injonction. Le résultat, dans ses propres termes : Sur la base des données fournies, il n'a pas été possible d'établir l'existence d'un problème d'état des actifs à l'échelle du secteur. [...] Les compagnies ont fortement assorti de réserves les données fournies [...] ce qui a rendu difficile de parvenir à une conclusion ferme sur l'état des actifs dans le secteur de l'eau. Il faut lire cette phrase pour ce qu'elle dit exactement, et pas pour ce qu'on aimerait lui faire dire. Le régulateur n'affirme pas que les infrastructures se dégradent. Il n'affirme pas non plus qu'elles vont bien. Il dit qu'il ne peut pas conclure. Un régulateur national, doté de pouvoirs d'information contraignants sur un secteur entier, n'obtient pas de réponse à la question la plus simple qu'on puisse poser sur des infrastructures essentielles : dans quel état sont-elles. Ce n'est pas faute d'avoir prévenu. Trois ans plus tôt, en septembre 2021, le même régulateur publiait les enseignements d'une évaluation de la maturité en gestion d'actifs conduite auprès de seize compagnies. Maturité moyenne du secteur : « en développement ». Recommandation numéro quatre, textuellement : « Les compagnies devraient développer une approche stratégique de la gestion des données et de l'information qui tienne compte de la capacité à partager les données ». Trois ans séparent cette recommandation du constat d'échec. Ce qui échoue, dans cet intervalle, n'est pas l'effort des exploitants. C'est la structure : tant que chaque compagnie hérite du modèle de son éditeur, aucune quantité de bonne volonté ne produit un langage commun. ## L'échelle européenne Reste à situer l'ordre de grandeur. Il n'existe pas, à ma connaissance, d'équivalent européen et récent du chiffre du NIST appliqué spécifiquement aux infrastructures physiques. En revanche, plusieurs travaux européens récents mesurent le phénomène voisin, la dépendance logicielle et cloud, et leurs chiffres sont accessibles à la source. Le cabinet Asterès, pour le Cigref qui réunit les directions numériques des grandes entreprises françaises, a établi en avril 2025 que les organisations européennes dépensent environ 400 milliards d'euros par an en services cloud et logiciels, dont 330 milliards vers des entreprises américaines, soit 83 % du marché, et que 80 % de la valeur créée par cette dépense, soit 264 milliards d'euros, bénéficie à l'économie américaine. Dans une seconde étude publiée en mai 2026, le même cabinet projette, à volumes de dépense constants et sur la période 2026-2030, une sur-inflation représentant en moyenne 140 milliards d'euros par an, qui priverait l'économie européenne d'environ 107 milliards d'euros de valeur ajoutée par an, soit 0,6 point de produit intérieur brut, et de 1,4 million d'emplois d'ici 2030. Ces travaux sont commandés par une association de clients, et le second est une projection. Je le dis parce que la symétrie compte : l'étude la plus souvent citée en sens inverse, celle du professeur Frédéric Jenny sur les pratiques de licence, a été commandée par une association de fournisseurs de cloud européens en litige avec un éditeur. Elle estime, dans une fourchette de 100 à 930 millions d'euros dont 560 millions constituent l'estimation centrale, le surcoût de première année supporté par les clients européens d'une suite bureautique du fait d'un changement de politique de licence, et, dans une fourchette de 500 à 1 900 millions dont 1 milliard constitue l'estimation centrale, le surcoût cumulé de 2020 à 2022 sur les déploiements d'un serveur de bases de données hors du cloud de son éditeur. Ces deux montants circulent souvent additionnés et convertis en un flux annuel de 1,56 milliard d'euros. L'étude ne fait jamais cette addition, et aucun des deux termes n'est annuel. Je les donne séparés. Le chiffre de 264 milliards a été repris, en décembre 2025, par une étude demandée par la commission de l'industrie, de la recherche et de l'énergie du Parlement européen, qui le situe à environ 1,5 % du produit intérieur brut de l'Union, soit à peu près une fois et demie le budget européen. Cette étude n'a pas produit le chiffre, elle le cite, et il faut le dire. Mais elle apporte en propre quelque chose de plus utile qu'un montant, à savoir le mécanisme, nommé par une institution européenne : Ces dépendances sont renforcées par la captivité vis à vis du fournisseur, les contrats de longue durée, les formats propriétaires et les effets de réseau, qui limitent le changement et découragent l'entrée sur le marché des innovateurs européens. La même étude retient d'ailleurs, parmi ses indicateurs de mesure de la dépendance, « des indicateurs qualitatifs et quantitatifs de captivité, par exemple les formats propriétaires, le contrôle de l'écosystème, les normes ouvertes ». Le Parlement européen mesure donc la souveraineté numérique, entre autres, par la portabilité des formats. Enfin, la Commission chiffre ses propres attentes. L'analyse d'impact du règlement sur les données estime le gain des mesures relatives au cloud à 7,1 milliards d'euros, correspondant à une demande de cloud supérieure de 10,9 % en 2025, et à 0,05 point de produit intérieur brut. Elle chiffre par ailleurs à 653 millions d'euros sur deux ans le préjudice économique brut subi par les petites et moyennes entreprises du fait de contrats déséquilibrés avec les fournisseurs de cloud. Et la foire aux questions officielle du règlement sur l'interopérabilité de l'Europe annonce, sur la foi de son analyse d'impact, une économie pouvant atteindre 5 milliards d'euros par an pour le seul secteur public. Ce sont des gains espérés, issus de modèles, et non des économies constatées. ## Ce qu'un maître d'ouvrage peut exiger Tout ce qui précède décrit une dépendance qui n'est ni illégale, ni cachée, ni même malveillante. Elle résulte d'un vide : personne n'a jamais exigé que le modèle appartienne à l'exploitant. Or les instruments pour l'exiger existent, ils sont internationaux, publics et achetables, et ils sont antérieurs au problème. Premier levier : une désignation de référence qui appartient à l'exploitant. La norme IEC 81346-1, dans son édition de 2022, publiée conjointement par la Commission électrotechnique internationale et l'Organisation internationale de normalisation, établit les principes de structuration des systèmes et les règles de formulation de désignations de référence non ambiguës. Son résumé officiel dit l'essentiel : La désignation de référence identifie les objets aux fins de création et de récupération de l'information à leur sujet. Une désignation de référence apposée sur un composant est la clé qui permet de retrouver l'information sur cet objet à travers des documents de natures différentes. Les principes sont généraux et s'appliquent à tous les domaines techniques. C'est très exactement la réponse au problème. Une désignation de référence décrit une fonction dans un système et un emplacement. Elle est posée par l'exploitant, elle survit au remplacement de l'équipement, et elle survit au remplacement du logiciel. C'est une norme horizontale, c'est à dire destinée à être reprise par les autres comités de normalisation, et elle existe depuis 2009 dans sa première édition. Une confusion à éviter, et elle est très répandue. La norme IEC 61406-1, de la même famille numérique, traite d'un tout autre objet. Elle spécifie « les exigences minimales pour une identification globalement unique des objets physiques, qui constitue également un lien vers l'information numérique associée », sous forme d'une adresse encodée dans un code à deux dimensions ou une étiquette sans contact. Son champ d'application précise qu'elle s'applique aux objets « auxquels une identité unique a déjà été attribuée par le fabricant ». C'est donc l'identifiant du produit, posé par le fabricant. Il est utile, et il ne remplace pas le précédent. Beaucoup de projets achètent la plaque signalétique numérique en croyant régler la question du référentiel. Les deux identifiants sont complémentaires, et seul celui de l'exploitant protège de la dépendance. Deuxième levier : un modèle de données normalisé, opposable au cahier des charges. La norme ISO 14224, dans son édition de 2016 confirmée en 2022, fournit une taxonomie d'équipements, un vocabulaire normalisé de modes de défaillance, et un format d'échange. Son résumé officiel contient une phrase qu'un acheteur devrait connaître par cœur : La présente Norme internationale établit les exigences que tout système de données de fiabilité et de maintenance, interne ou disponible dans le commerce, est tenu de satisfaire lorsqu'il est conçu pour l'échange de données. Elle est née dans le pétrole et le gaz, ce qui en limite l'application directe hors de ces secteurs, et il serait excessif de prétendre qu'elle couvre un réseau d'eau ou un patrimoine bâti. Mais elle démontre qu'un modèle normatif d'échange est possible, qu'il a été écrit, et qu'il s'impose explicitement aux systèmes commerciaux. La réponse à « un format raisonnable et courant » n'est pas une protestation, c'est un numéro de norme. Ce que cela donne, concrètement, dans un marché. Les cinq exigences suivantes tiennent en une page de cahier des charges, et aucune ne suppose un rapport de force particulier. - La désignation de référence appartient au maître d'ouvrage. Elle est définie selon l'IEC 81346, documentée hors du système, et le titulaire s'engage à la porter telle quelle, sans la transformer en clé technique interne. - La spécification des données est un livrable contractuel. Conformément à l'ISO 55001 clause 7.6 b), le titulaire remet et tient à jour la liste des attributs, des unités de mesure, des exigences de qualité et des sources. Ce document appartient au maître d'ouvrage et lui reste à l'issue du marché. - La hiérarchie, les classifications et les règles sont exportables dans un format documenté. Pas seulement les enregistrements : les structures, les listes de valeurs, les règles de déclenchement, avec leur documentation. - La liste des exclusions est fournie avant la signature. C'est déjà une obligation du règlement à l'article 25 paragraphe 2 point f) ; il suffit de l'exiger explicitement, et de la lire. - La réversibilité est testée pendant le marché, pas à sa fin. Un export complet est produit et rechargé dans un environnement tiers à une échéance convenue, par exemple tous les deux ans. Une réversibilité qui n'a jamais été essayée n'est pas une réversibilité, c'est une clause. La cinquième est la plus importante et la moins pratiquée. Elle transforme une promesse en fait vérifié, et elle déplace la découverte du problème du moment du divorce vers un moment où l'on peut encore négocier. ## Ce qu'on ne sait pas, et qui compte Cinq incertitudes subsistent, et les taire affaiblirait tout ce qui précède. Il n'existe pas de chiffre européen récent équivalent à celui du NIST. Je n'en ai pas trouvé, et je ne transpose pas le chiffre américain de 2002 à l'Europe de 2026. Les ordres de grandeur européens cités plus haut portent sur la dépendance logicielle et cloud en général, pas sur le coût de l'information d'actif qui ne circule pas. Ce sont des phénomènes voisins, pas le même phénomène. Le répertoire central de l'Union n'a pas été trouvé publié. Les documents officiels les plus récents que j'ai pu consulter le décrivent encore comme à construire. Une absence constatée n'est pas une absence établie : il se peut qu'une publication m'ait échappé, et la vérification est à refaire avant toute décision qui en dépendrait. La frontière de l'exemption du sur-mesure n'est définie nulle part. Aucune décision, aucune ligne directrice publiée ne dit à partir de quel niveau de paramétrage un déploiement cesse de relever du catalogue. C'est une zone d'interprétation, et elle est confiée en première instance au fournisseur lui-même. Le sort de l'assistance à l'extraction facturée reste ouvert. La date du 12 janvier 2027 est certaine ; sa conséquence sur une prestation d'assistance vendue en option ne l'est pas, et dépendra des contrats et de la pratique des autorités. Enfin, une étude fréquemment citée n'a pas été retenue ici. Un chiffre global du coût de la mauvaise donnée dans la construction, de l'ordre de mille huit cents milliards de dollars, circule abondamment. Il provient d'une étude publiée par un éditeur de logiciels, ce qui n'est pas disqualifiant en soi, mais ses propres pages en donnent des versions divergentes, et la part attribuée aux reprises y figure avec un facteur mille d'écart selon les documents. Une étude dont le commanditaire vend la solution au problème qu'elle mesure, et qui n'en donne pas deux fois le même montant, n'a pas sa place dans un appareil de preuve. Je préfère le dire que de l'utiliser. Ce qui reste, une fois ces réserves posées, tient en peu de mots. Le droit de sortie existe, il devient gratuit, et il livre des tableaux. Le modèle, lui, ne part pas, parce que personne ne l'a jamais demandé. Ce n'est pas une fatalité technique : c'est un vide contractuel, et les normes pour le combler sont écrites depuis quinze ans. La question n'est plus de savoir si l'on peut partir. Elle est de savoir ce qu'on emporte, et qui a écrit la réponse. ## Télécharger Lire le document (PDF) 19 pages · français · 28 sources · 136 Ko Texte intégralement sélectionnable et citable Le document porte son propre DOI, réservé avant l'export Licence CC BY-NC-ND 4.0, sans inscription ## Notice bibliographique Titre La donnée d'actif : la sortie devient gratuite, le modèle reste captif Auteur Nizar Younes Mqam, ORCID 0009-0008-5549-7620 Collection Cahiers de technopolitique, n° 3, format Étude Éditeur Nizar Younes Mqam, Tourcoing, France Date de publication 18 septembre 2026 Langue Français DOI Réservation en cours sur Zenodo Dépôt pérenne Zenodo, hébergé par le CERN, dépôt à venir ISSN En cours d'attribution Licence CC BY-NC-ND 4.0 ## Sources et références - Règlement (UE) 2023/2854 du Parlement européen et du Conseil du 13 décembre 2023 concernant des règles harmonisées portant sur l'équité de l'accès aux données et de l'utilisation des données. EUR-Lex, CELEX 32023R2854. Article 2, points 32, 33 et 38 ; articles 23, 24, 25, 29, 30, 31 et 35. - Commission européenne, Impact Assessment accompanying the proposal for a Data Act, SWD(2022) 34 final, 23 février 2022, sections 2.2 et 2.3, et synthèse des bénéfices et coûts. - Commission européenne, Rolling Plan for ICT Standardisation, section « Cloud and edge computing », édition 2025, Interoperable Europe Portal. - Commission européenne, Results of the study on interoperability of data processing services, page publiée le 23 février 2026, digital-strategy.ec.europa.eu. Étude conduite par WIK, Decision et Schuman associates. - Commission européenne, foire aux questions du règlement sur l'interopérabilité de l'Europe, Interoperable Europe Portal, consultée le 18 septembre 2026. - Loi n° 2024-449 du 21 mai 2024 visant à sécuriser et à réguler l'espace numérique, articles 26 et 27. Légifrance, JORFTEXT000049563368. - ARCEP, communiqué de presse du 2 juillet 2026, référence 39-26, sur les lignes directrices relatives aux frais de changement de fournisseur et de transfert de données. Rappelle la décision n° 2025-0340 du 20 février 2025 et l'arrêté ministériel du 17 novembre 2025, publié le 30 novembre 2025, fixant à zéro euro le montant maximal de tarification. - IBM, Cloud Services Agreement, IBM Cloud International B.V., référence Z126-6304-IBMCIBV_13_ZZ_08-2023, version 13, publiée le 7 décembre 2023, articles 2.f et 7. - IBM, Descriptif de Services IBM Cloud, référence i126-6605-28, publié le 9 avril 2024, articles 6.1.1, 6.1.2 et 6.1.3. - IBM, IBM Cloud Terms of Use, cloud.ibm.com, sections « EU Data Act » et « French SREN Law », dernière mise à jour du 26 août 2026. - IBM, Service Description, IBM Maximo Application Suite as a Service for Other Public Clouds, référence i126-9424-01, juin 2022. - Digital Marketplace, cadre G-Cloud, fiches de service publiées par le gouvernement britannique, consultées le 18 septembre 2026 : IBM Maximo Application Suite, service 796607983892135 ; Octave Attune EAM, anciennement HxGN EAM, service 363440304862681 ; F0CUS Work and Asset Management System, service 210498469166781. Rubriques « Data export approach » et « End-of-contract data extraction ». - Documentation publique de l'interface de programmation et des structures d'objets de Maximo, IBM Docs et ibm-maximo-dev.github.io, consultées le 18 septembre 2026. - ISO 55001:2024, Gestion d'actifs, systèmes de management, exigences, deuxième édition, juillet 2024, clause 7.6. - ISO 55013:2024, Asset management, Guidance on the management of data assets, première édition, juillet 2024, ISO/TC 251, 20 pages. - ISO 14224:2016, Petroleum, petrochemical and natural gas industries, Collection and exchange of reliability and maintenance data for equipment, troisième édition, septembre 2016, confirmée en 2022. - IEC 81346-1:2022, Industrial systems, installations and equipment and industrial products, Structuring principles and reference designations, Part 1: Basic rules, publication conjointe IEC et ISO. - IEC 61406-1:2022, Identification Link, Part 1: General requirements, article 1, champ d'application. - NIST GCR 04-867, Cost Analysis of Inadequate Interoperability in the U.S. Capital Facilities Industry, août 2004, préparé pour le National Institute of Standards and Technology par RTI International et le Logistics Management Institute. Résumé exécutif et section 6.5. - Grant Thornton, Birmingham City Council External Audit 2020-21 to 2023-24, Statutory recommendations under Schedule 7 of the Local Audit and Accountability Act 2014, septembre 2023, section « Oracle implementation » et recommandations statutaires 5 à 7. - Birmingham City Council, Statement of Accounts for the Year Ended 31 March 2024, 259 pages, sections « Oracle implementation issues », « Oracle » et « Oracle Issues ». - Ofwat, PR24 final determinations: Roadmap for enhancing asset health understanding in the water sector, décembre 2024, section 3 « Industry Challenges ». - Ofwat, Asset management maturity assessment, insights and recommendations, septembre 2021, recommandation n° 4 et synthèse des scores de maturité. - Asterès pour le Cigref, La dépendance technologique aux softwares et cloud services américains, une estimation des conséquences économiques en Europe, avril 2025. - Asterès pour le Cigref, From technological dependency to economic capture: the cost of cloud and software services inflation to Europe, mai 2026, résumé exécutif et section 4. - Parlement européen, European Software and Cyber Dependencies, étude demandée par la commission ITRE, PE 778.576, décembre 2025, principaux constats et section 3. - Frédéric Jenny, Unfair Software Licensing Practices: A quantification of the cost for cloud customers, rapport pour CISPE, 21 juin 2023, sections 2.3.1 et 2.3.2. - GFMAM, Asset Management Landscape, version 3.0, 2024, sujet 5.5 « Asset Management Data and Information Systems ». ## Pour citer cette étude Mqam, N. Y. (2026). La donnée d'actif : la sortie devient gratuite, le modèle reste captif. Cahiers de technopolitique, n° 3. https://technopolitique.eu/cahiers/n3/ ================================================================================ ## SOURCE : Articles, la rubrique URL : https://technopolitique.eu/articles/ Rubrique # Articles Analyses courtes, sourcées, en accès ouvert Auteur Nizar Younes Mqam Licence CC BY-NC-ND 4.0 Des textes brefs et réactifs, qui commentent sans prétendre à l'appareil de sources. Tout ce qui repose sur un travail de recherche documenté paraît dans les Cahiers de technopolitique, sous forme d'Étude ou de Note, avec un PDF, une notice et un DOI. ## Parus - 17 septembre 2026 · Souveraineté et données d'actifs ### L'IA de maintenance : vous gardez la propriété, vous perdez la maîtrise Les contrats de plateformes de maintenance prédictive reconnaissent que vos données vous appartiennent. Leurs définitions rangent la couche dérivée du côté du fournisseur, et ce droit survit à la résiliation. Le droit européen s'arrête au même endroit. ================================================================================ ================================================================================ ## SOURCE : Pages légales URL : https://technopolitique.eu/mentions-legales/ Éditeur : Nizar Younes Mqam, personne physique. Directeur de la publication : Nizar Younes Mqam. Lieu d'édition : Tourcoing, France. Contact : y.nizar@proton.me · ORCID : https://orcid.org/0009-0008-5549-7620 Nature du site : publication non commerciale en accès ouvert, sans vente ni prestation en ligne. Collection : Cahiers de technopolitique, ISSN en cours d'attribution. Hébergeur : Codeberg e.V., Arminiusstraße 2-4, 10551 Berlin, Allemagne, contact@codeberg.org, inscrite au registre des associations du tribunal d'instance de Charlottenburg sous VR 36929. Service : Codeberg Pages, hébergement de sites statiques. URL : https://technopolitique.eu/confidentialite/ Le site ne dépose aucun cookie, n'utilise aucun stockage local, aucune mesure d'audience, aucun pixel, aucune balise publicitaire. Aucune police, aucun script et aucune image ne sont chargés depuis un domaine tiers. Aucun formulaire, aucun compte, aucune inscription. Aucun profilage. Subsistent les journaux techniques de l'hébergeur : adresse IP tronquée, navigateur, date, adresse demandée. Base légale : intérêt légitime, article 6.1.f du RGPD. Conservation : sept jours au plus. L'éditeur n'y a pas accès. Les courriels reçus sont traités pour répondre, puis supprimés. Les boutons « Interroger une IA » transportent le titre et l'adresse du document dans la question adressée au service choisi ; aucune donnée sur le lecteur n'est ajoutée par ce site. Droits RGPD (accès, rectification, effacement, limitation, opposition, portabilité) : y.nizar@proton.me. Réclamation : CNIL, 3 place de Fontenoy, TSA 80715, 75334 Paris Cedex 07. URL : https://technopolitique.eu/conditions/ Licence CC BY-NC-ND 4.0. Sont autorisés : lire, télécharger, imprimer, citer et redistribuer à l'identique, y compris le dépôt dans un dépôt institutionnel, à condition de citer l'auteur, le titre, la collection et le DOI. Sont interdits sans autorisation écrite : l'usage commercial et toute version remaniée, traduite, abrégée ou recomposée. La citation d'extraits dans un travail distinct reste permise. L'indexation et la lecture par des systèmes automatisés sont autorisées aux conditions de la licence, attribution comprise. Le texte intégral est fourni en clair dans llms-full.txt pour éviter les extractions approximatives. Les textes publiés ne constituent ni un conseil juridique, ni un conseil en investissement, ni une prestation d'audit ou de certification. Une erreur factuelle donne lieu à une version nouvelle, datée et identifiée, jamais à une retouche silencieuse. Droit applicable : droit français.