É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.

1. 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.
2. 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é.
3. 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.
4. 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.
5. 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

10.5281/zenodo.22836960
Toutes versions : 10.5281/zenodo.22836959

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

1. 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.
2. 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.
3. Commission européenne, Rolling Plan for ICT Standardisation, section « Cloud and edge computing », édition 2025, Interoperable Europe Portal.
4. 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.
5. 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.
6. 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.
7. 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.
8. 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.
9. 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.
10. 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.
11. IBM, Service Description, IBM Maximo Application Suite as a Service for Other Public Clouds, référence i126-9424-01, juin 2022.
12. 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 ».
13. 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.
14. ISO 55001:2024, Gestion d'actifs, systèmes de management, exigences, deuxième édition, juillet 2024, clause 7.6.
15. ISO 55013:2024, Asset management, Guidance on the management of data assets, première édition, juillet 2024, ISO/TC 251, 20 pages.
16. 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.
17. 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.
18. IEC 61406-1:2022, Identification Link, Part 1: General requirements, article 1, champ d'application.
19. 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.
20. 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.
21. Birmingham City Council, Statement of Accounts for the Year Ended 31 March 2024, 259 pages, sections « Oracle implementation issues », « Oracle » et « Oracle Issues ».
22. Ofwat, PR24 final determinations: Roadmap for enhancing asset health understanding in the water sector, décembre 2024, section 3 « Industry Challenges ».
23. Ofwat, Asset management maturity assessment, insights and recommendations, septembre 2021, recommandation n° 4 et synthèse des scores de maturité.
24. 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.
25. 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.
26. 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.
27. 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.
28. 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://doi.org/10.5281/zenodo.22836960

Lire aussi

N° 2 · Note · Septembre 2026

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.

5 pages · 12 sources · PDF 253 Ko
DOI 10.5281/zenodo.22818645

Lire la notice et télécharger

N° 1 · Étude · Septembre 2026

Quand le cloud prend feu

Des drones ont frappé des centres de données commerciaux dans le Golfe et mis hors ligne 109 services numériques. Ce que change le passage de la cybermenace à la destruction physique, pour qui doit garantir une continuité.

37 pages · 41 références · PDF 0,9 Mo
DOI 10.5281/zenodo.22812311

Lire la notice et télécharger