Mois : mai 2026

Cada archivo guardado, cada conjunto de datos replicado, cada copia de seguridad creada tiene un coste en carbono. Almacenamos para no perder nada, para cumplir con la normativa, para dejar constancia. Pero este reflejo de guardar todo, por si acaso, se ha convertido silenciosamente en una de las decisiones IT más contaminantes que puede tomar una organización. En 2026, la pregunta ya no es si tus datos tienen huella. Es si tu arquitectura te obliga a tenerla.

Un peso que el sector tecnológico ha subestimado durante demasiado tiempo

El sector digital representa hoy el 4,4 % de la huella de carbono de Francia, es decir, 29,5 millones de toneladas de CO2 equivalente emitidas en 2022, una cifra comparable a las emisiones totales del transporte de mercancías por carretera (fuente: ADEME-Arcep, enero de 2025). Lo que ha cambiado significativamente desde las primeras estimaciones es la parte atribuida a los centros de datos: pasó del 16 % en 2020 al 46 % en 2025, rozando ya el 50 % que corresponde a los dispositivos de los usuarios finales.

La explicación se resume en un solo dato: el 53 % del uso digital francés está alojado en el extranjero, en centros de datos que funcionan con mezclas eléctricas mucho más intensivas en carbono que la red francesa (fuente: ADEME-Arcep, enero de 2025). La electricidad consumida en Francia es de media 10 veces menos intensiva en carbono que la de los principales países que alojan centros de datos, como Estados Unidos (fuente: informe del Senado francés, junio de 2020), lo que amplifica mecánicamente la huella de los usos digitales franceses procesados en el extranjero. La ubicación del servidor, que nadie elige desde el navegador, determina una gran parte del impacto real.

A escala mundial, los centros de datos absorbieron 310,6 teravatios-hora en 2024, un incremento del 74 % desde 2019, y ya representan más del 1,7 % de la demanda eléctrica mundial según la Agencia Internacional de la Energía (fuente: Structure Research ESG 2025, vía Allegro Informatique). En países con alta concentración de centros de datos, como Estados Unidos, Irlanda o Singapur, esta proporción puede superar el 10 % del consumo nacional. La refrigeración representa por sí sola el 40 % de la energía total consumida por estas instalaciones (fuente: Greenly, 2025). Según un informe del Senado francés, la huella de carbono del sector digital francés podría aumentar un 60 % de aquí a 2040 si las tendencias actuales no cambian.

El almacenamiento por defecto, un reflejo ecológicamente costoso

La cultura empresarial respecto a los datos sigue siendo la de la abundancia: recopilar todo, conservar todo, no eliminar nada. La normativa sobre retención, el miedo a perder un historial útil y la ausencia de políticas de ciclo de vida de los datos forman un tríptico que desemboca siempre en el mismo resultado: servidores funcionando de forma continua para alojar archivos que nadie consulta.

Veritas ha medido el fenómeno: el 52 % de todos los datos almacenados por las empresas en el mundo son « dark data », es decir, datos no utilizados, obsoletos, cuyo contenido los responsables de IT a menudo ni siquiera conocen (fuente: Veritas, vía Le Monde Informatique). El volumen mundial de datos almacenados alcanzó los 175 zettabytes en 2025, cinco veces más que en 2018 según las previsiones del IDC (fuente: IDC Data Age 2025, vía Le Monde Informatique), de los cuales 91 zettabytes serían dark data. Almacenar únicamente estos datos no utilizados genera 6,4 millones de toneladas de CO2 innécesariamente cada año, el equivalente al consumo anual de dióxido de carbono de 80 países (fuente: Veritas, vía Global Security Mag).

Esta cifra resulta aún más llamativa si se tiene en cuenta que el almacenamiento suele presentarse como un recurso barato. El coste unitario por gigabyte ha caído, pero el volumen almacenado ha crecido tanto que la factura global, económica y en carbono, ha subido con él. Como detallábamos en nuestro artículo sobre los costes ocultos del cloud, la promesa de « paga solo lo que consumes » exige entender realmente qué se consume. Para la mayoría de las organizaciones, la huella real del almacenamiento fantasma nunca ha sido calculada.

El Scope 3 llega, y la infraestructura IT está dentro

Durante mucho tiempo, la huella de carbono digital de las empresas fue invisible en sus informes. Ni el almacenamiento cloud, ni los flujos de datos salientes, ni la energía consumida por los servidores de producción aparecían en los reportes ESG. Ese tiempo está llegando a su fin.

La directiva CSRD, que entró en vigor el 1 de enero de 2024 para las grandes empresas ya sujetas a la NFRD, obliga a publicar un informe de emisiones que cubra los ámbitos 1, 2 y 3, de acuerdo con las normas ESRS (fuente: economie.gouv.fr). El ámbito 3 es precisamente el que recoge las emisiones indirectas de la cadena de valor, incluida la infraestructura IT externalizada. El paquete Omnibus, adoptado por el Parlamento Europeo en diciembre de 2025, redujo el ámbito de aplicación de unas 50 000 a aproximadamente 10 000 empresas en la Unión Europea, con un aplazamiento de dos años para las oleadas 2 y 3 (fuente: Réglementation-environnement.com, 2026). Pero para los grandes grupos de la oleada 1, las obligaciones de reporte del ámbito 3 se mantienen.

El efecto en cascada es aún más amplio. Las pymes no sujetas directamente a la CSRD tendrán que proporcionar datos ESG estructurados a sus clientes que sí lo estén (fuente: Claire Gérardin, 2026). La infraestructura digital tendrá que hacerse visible en los balances de toda la cadena. Sin embargo, la pregunta casi nunca se hace en las auditorías de carbono actuales: ¿cuántos datos almacena tu sistema de información que nadie ha consultado en años? ¿Qué proporción de tu ámbito 3 representa la energía consumida por servidores que alojan archivos que no han recibido una sola petición en media década?

Procesar sin almacenar: sobriedad estructural, no cosmética

La sobriedad digital suele reducirse a sus formas más visibles: apagar equipos en desuso, vaciar bandejas de entrada, desactivar servicios inactivos. Estas acciones tienen su utilidad, pero operan en los márgenes de un problema arquitectónico.

La verdadera palanca está más arriba, en el propio diseño de los pipelines de procesamiento. La lógica dominante sigue siendo la del almacenamiento intermedio: los datos se recopilan, luego se almacenan, luego se procesan, luego se analizan, a veces se replican entre sistemas. Cada etapa genera una huella, y cada duplicación multiplica las superficies de almacenamiento activas. Este supuesto de almacenar primero para poder procesar no es una inevitabilidad técnica. Es el resultado de un hábito de diseño.

Una arquitectura que procesa los datos durante su tránsito, sin persistirlos jamás en un espacio intermedio, reduce mecánicamente la huella de almacenamiento a cero en la capa de procesamiento. Este es el principio en que se basa la DataCell de iD4Connect: cada unidad de procesamiento actúa sobre los datos durante su paso (limpieza, transformación, enriquecimiento, enrutamiento) y luego los libera. Nada se acumula en el lado del middleware. El DataGraph orquesta estas unidades sin centralizar jamás los datos en un hub intermedio. El resultado no es solo una mejora de rendimiento o coste: es una arquitectura sobria por construcción, con una huella ambiental estructuralmente inferior a la de un pipeline clásico.

Algunas cifras para replantear el debate:

4,4 %: peso del sector digital en la huella de carbono francesa (ADEME-Arcep, enero de 2025)

46 %: cuota de los centros de datos en las emisiones digitales, frente al 16 % en 2020 (ADEME-Arcep, enero de 2025)

53 %: proporción del uso digital francés alojado en el extranjero, con mezclas eléctricas más contaminantes (ADEME, 2025)

52 %: proporción de los datos empresariales almacenados que están sin usar u obsoletos, es decir los « dark data » (Veritas)

6,4 millones de toneladas de CO2: emisiones anuales generadas únicamente por el almacenamiento de dark data en todo el mundo (Veritas)

60 %: aumento proyectado de la huella de carbono del sector digital francés de aquí a 2040 si las tendencias actuales no cambian (Informe del Senado, 2020)

Tres preguntas que todo CIO debería hacerse antes de aprobar la próxima arquitectura

1. ¿Sabe cuántos datos almacena su sistema de información sin releerlos jamás? Los dark data no aparecen en los paneles de control habituales. No generan alertas, no ralentizan el rendimiento, no disparan ningún sistema de monitorización. Simplemente consumen energía, en silencio, cada segundo. Una auditoría del ciclo de vida de los datos (cuántos no han sido accedidos en más de seis meses, más de un año, más de tres años) es el punto de entrada más inmediato para comprender la huella real de un SI.

2. ¿Su huella de carbono digital integra el ciclo de vida de los datos? Las evaluaciones de carbono IT suelen centrarse en los equipos físicos y el consumo eléctrico medido. Los costes de egress, el almacenamiento fantasma, las replicaciones automáticas olvidadas: estas partidas casi nunca aparecen en los análisis de ámbito 3 actuales. Sin embargo, es aquí donde se genera una parte creciente de la huella real, como detallábamos en nuestro artículo sobre los costes ocultos del cloud.

3. ¿Pueden sus arquitecturas de procesamiento funcionar sin almacenar por defecto? El objetivo no es eliminar todo el almacenamiento: algunos datos deben persistir. La pregunta es si puede distinguir los datos que verdaderamente necesitan almacenarse de los que se guardan por hábito o por defecto de arquitectura. Un pipeline que procesa en tránsito y solo almacena lo que tiene un valor documentado es, por diseño, más eficiente que uno que centraliza primero y procesa después.

La sobriedad digital no se decreta en una carta de RSC. Se construye en las decisiones de arquitectura, en las políticas de ciclo de vida de los datos, en la mirada honesta que una organización echa sobre lo que sus servidores realmente alojan. No almacenar, cuando el procesamiento puede prescindir de ello, no es una limitación: es una decisión de diseño. Y en 2026, también es un acto ecológico.

Descubra cómo iD4Connect procesa los datos sin almacenarlos jamás →

Every saved file, every replicated dataset, every backup created has a carbon cost. We store to avoid losing things, to stay compliant, to keep a trace. But this reflex of keeping everything, just in case, has quietly become one of the most polluting IT choices an organization can make. In 2026, the question is no longer whether your data has a footprint. It’s whether your architecture forces you to have one.

A weight the tech industry has long underestimated

The digital sector now accounts for 4.4% of France’s carbon footprint, representing 29.5 million tonnes of CO2 equivalent emitted in 2022, a figure on par with the total emissions of the country’s entire heavy goods transport sector (source: ADEME-Arcep, January 2025). What has shifted dramatically since earlier estimates is the share attributed to data centers: it jumped from 16% in 2020 to 46% in 2025, nearly matching the 50% attributed to end-user devices.

The explanation comes down to one number: 53% of French digital usage is hosted abroad, in data centers running on electricity mixes far more carbon-intensive than the French grid (source: ADEME-Arcep, January 2025). Electricity consumed in France is on average 10 times less carbon-intensive than that of the main data center host countries such as the United States (source: French Senate report, June 2020), which mechanically amplifies the footprint of French digital usage processed abroad. The location of the server, which nobody chooses in their browser, determines a large share of the real-world impact.

Globally, data centers absorbed 310.6 terawatt-hours in 2024, a 74% increase since 2019, now representing over 1.7% of total global electricity demand according to the International Energy Agency (source: Structure Research ESG 2025, via Allegro Informatique). In major data center hubs such as the United States, Ireland, and Singapore, this share can exceed 10% of national consumption. Cooling alone accounts for 40% of total energy consumed by these facilities (source: Greenly, 2025). According to a French Senate report, the carbon footprint of France’s digital sector is on course to increase by 60% by 2040 if current trends hold.

Default storage: an environmentally costly reflex

Enterprise data culture remains one of abundance: collect everything, keep everything, delete nothing. Retention regulations, fear of losing useful history, and the absence of data lifecycle policies combine to produce the same outcome: servers running continuously to host files nobody ever looks at.

Veritas has measured the scale: 52% of all data stored by companies worldwide is « dark data », meaning unused, obsolete data whose content IT managers are often unaware of (source: Veritas, via Le Monde Informatique). Global data storage reached 175 zettabytes in 2025, five times the 2018 figure according to IDC (source: IDC Data Age 2025, via Le Monde Informatique), of which 91 zettabytes would be dark data. Storing this unused data alone generates 6.4 million tonnes of CO2 needlessly each year: the equivalent of the annual carbon consumption of 80 countries (source: Veritas, via Global Security Mag).

This figure is all the more striking given that storage is typically framed as a cheap resource. The unit cost per gigabyte has indeed fallen, but the volume stored has exploded to such a degree that the overall bill, financial and carbon alike, has risen with it. As we outlined in our article on the hidden costs of cloud, the promise of « pay only for what you use » requires actually understanding what you consume. For most organizations, the true footprint of phantom storage has never been calculated.

Scope 3 is coming, and IT infrastructure is in it

For a long time, the digital carbon footprint of businesses was invisible in their reports. Cloud storage, outbound data flows, energy consumed by production servers: none of it appeared in ESG disclosures. That era is ending.

The CSRD directive, which came into force on January 1, 2024 for large companies already subject to the NFRD, requires the publication of an emissions report covering scopes 1, 2, and 3, in line with ESRS standards (source: economie.gouv.fr). Scope 3 is precisely the category that captures indirect emissions from the upstream and downstream value chain, including outsourced IT infrastructure. The Omnibus package adopted by the European Parliament in December 2025 reduced the scope of application from approximately 50,000 to around 10,000 companies in the European Union, with a two-year delay for waves 2 and 3 (source: Réglementation-environnement.com, 2026). But for large groups in wave 1, scope 3 reporting obligations remain.

The cascade effect extends further still. SMEs not directly subject to CSRD will need to provide structured ESG data to their customers who are (source: Claire Gérardin, 2026). Digital infrastructure will have to become visible across the entire supply chain. Yet the question is almost never asked in current carbon audits: how much data is your information system storing that nobody has accessed in years? What share of your scope 3 represents the energy consumed by servers hosting files that haven’t seen a single query in half a decade?

Processing without storing: structural sobriety, not cosmetic effort

Digital sobriety is often reduced to its most visible forms: switching off idle equipment, clearing inboxes, deactivating unused services. These actions have their place, but they operate at the margins of an architectural problem.

The real lever lies upstream, in the design of processing pipelines themselves. The dominant logic remains that of intermediate storage: data is collected, then stored, then processed, then analyzed, sometimes replicated across systems. Each step generates a footprint, and each duplication multiplies active storage surfaces. This assumption of storing first in order to process is not a technical inevitability. It is the product of a design habit.

An architecture that processes data during transit, without ever persisting it in an intermediate space, mechanically reduces the storage footprint to zero at the processing layer. This is the principle underlying iD4Connect’s DataCell: each processing unit acts on the data during its passage (cleaning, transformation, enrichment, routing) then releases it. Nothing accumulates on the middleware side. The DataGraph orchestrates these units without ever centralizing data in an intermediate hub. The result is not only a performance or cost gain: it is an architecture that is lean by design, with a structurally lower environmental footprint than a conventional pipeline.

A few figures to reframe the debate:

4.4%: digital sector’s share of France’s carbon footprint (ADEME-Arcep, January 2025)

46%: data centers’ share of digital carbon emissions, up from 16% in 2020 (ADEME-Arcep, January 2025)

53%: share of French digital usage hosted abroad, on more carbon-intensive electricity mixes (ADEME, 2025)

52%: proportion of enterprise-stored data that is unused or obsolete, meaning « dark data » (Veritas)

6.4 million tonnes of CO2: annual emissions generated solely by storing dark data worldwide (Veritas)

60%: projected increase in France’s digital sector carbon footprint by 2040 if current trends continue (French Senate report, 2020)

Three questions every CIO should ask before approving the next architecture

1. Do you know how much data your IT system stores without ever reading it back? Dark data doesn’t show up in standard dashboards. It doesn’t trigger alerts, doesn’t slow down performance, doesn’t flag any monitoring system. It simply consumes energy, silently, every second. A data lifecycle audit (how much hasn’t been accessed in more than six months, more than a year, more than three years) is the most immediate entry point for understanding a system’s real footprint.

2. Does your digital carbon footprint account for the lifecycle of your data? IT carbon assessments typically focus on physical equipment and metered electricity consumption. Egress costs, phantom storage, forgotten automated replications: these line items almost never appear in current scope 3 analyses. Yet this is precisely where a growing share of real-world footprint is generated, as we detailed in our article on the hidden costs of cloud.

3. Can your processing architectures function without storing by default? The goal isn’t to eliminate all storage: some data must be persisted. The question is whether you can distinguish data that genuinely needs to be stored from data that is stored out of habit or architectural default. A pipeline that processes in transit and stores only what has documented value is, by design, more resource-efficient than one that centralizes first and processes second.

Digital sobriety cannot be decreed in a CSR charter. It is built into architectural choices, data lifecycle policies, and the honest assessment of what an organization’s servers are actually hosting. Not storing, when processing can do without it, is not a constraint: it is a design decision. And in 2026, it is also an ecological one.

Discover how iD4Connect processes data without ever storing it →

Chaque fichier enregistré, chaque dataset répliqué, chaque sauvegarde créée a un coût carbone. On stocke pour ne pas perdre, pour être en conformité, pour avoir une trace. Mais ce réflexe de tout garder, juste au cas où, est devenu silencieusement l’un des choix IT les plus polluants qui soit. En 2026, la question n’est plus de savoir si vos données ont une empreinte. Elle est de savoir si votre architecture vous oblige à en avoir une.

Le numérique a un poids que nous avons longtemps sous-estimé

Le secteur numérique représente aujourd’hui 4,4 % de l’empreinte carbone de la France, soit 29,5 millions de tonnes équivalent CO2 émises en 2022, un chiffre équivalent aux émissions totales du secteur des poids lourds (source : ADEME-Arcep, janvier 2025). Ce qui a changé depuis les premières estimations, c’est la part attribuée aux datacenters : elle est passée de 16 % en 2020 à 46 % en 2025, dépassant désormais presque les équipements utilisateurs qui représentent 50 %.

L’explication tient en un chiffre : 53 % des usages numériques français sont hébergés à l’étranger, dans des centres de données alimentés par des mix électriques bien plus carbonés que le réseau français (source : ADEME-Arcep, janvier 2025). L’électricité consommée en France est en moyenne 10 fois moins carbonée que celle des principaux pays d’accueil de datacenters comme les États-Unis (source : rapport du Sénat, juin 2020), ce qui amplifie mécaniquement l’empreinte des usages français traités à l’étranger. La localisation du serveur, que personne ne choisit dans son navigateur, détermine une grande part de l’impact réel.

À l’échelle mondiale, les datacenters ont absorbé 310,6 térawattheures en 2024, soit une croissance de 74 % depuis 2019, et représentent désormais plus de 1,7 % de la demande électrique mondiale selon l’Agence Internationale de l’Énergie (source : Structure Research ESG 2025, via Allegro Informatique). Dans les grands pays d’accueil comme les États-Unis, l’Irlande ou Singapour, cette part peut dépasser 10 % de la consommation nationale. Le refroidissement des serveurs représente seul 40 % de l’énergie totale consommée par ces infrastructures (source : Greenly, 2025). Selon un rapport du Sénat, l’empreinte carbone du numérique en France risque d’augmenter de 60 % d’ici à 2040 si les trajectoires actuelles ne changent pas.

Le stockage par défaut, un réflexe écologiquement coûteux

La culture de l’entreprise vis-à-vis de la donnée reste celle de l’abondance : tout collecter, tout conserver, ne rien supprimer. Les réglementations sur la rétention, la peur de perdre un historique utile, l’absence de politique de cycle de vie des données forment un triptyque qui aboutit au même résultat : des serveurs qui tournent en continu pour héberger des fichiers que personne ne consulte.

L’éditeur Veritas a mesuré le phénomène : 52 % de toutes les données stockées par les entreprises dans le monde sont des « dark data », c’est-à-dire inutilisées, obsolètes, dont les responsables IT ignorent souvent même le contenu (source : Veritas, via Le Monde Informatique). Le volume mondial de données stockées a atteint 175 zettaoctets en 2025, soit cinq fois plus qu’en 2018 selon les prévisions de l’IDC (source : IDC Data Age 2025, via Le Monde Informatique), dont 91 zettaoctets seraient donc des dark data. Le stockage de ces seules données inutilisées est responsable de 6,4 millions de tonnes de CO2 rejetées inutilement chaque année dans l’atmosphère, l’équivalent de la consommation annuelle en dioxyde de carbone de 80 pays (source : Veritas, via Global Security Mag).

Ce chiffre est d’autant plus saisissant que le stockage est souvent présenté comme une ressource bon marché. Le coût unitaire du gigaoctet a effectivement baissé, mais la quantité stockée a tellement explosé que la facture globale, financière et carbone, a suivi. Comme nous le développions dans notre article sur les coûts cachés du cloud, la promesse du « payer ce que vous consommez » suppose de comprendre ce qu’on consomme réellement. Pour la grande majorité des organisations, ce que représente le stockage fantôme n’a jamais été mesuré.

Le Scope 3 arrive, et l’infrastructure IT est dedans

Pendant longtemps, l’empreinte carbone numérique des entreprises a été invisible dans leurs bilans. Ni le stockage cloud, ni les flux de données sortants, ni l’énergie consommée par les serveurs de production n’apparaissaient dans les reportings ESG. Ce temps est en train de se terminer.

La directive CSRD, entrée en vigueur le 1er janvier 2024 pour les grandes entreprises déjà soumises à la NFRD, impose la publication d’un bilan d’émissions couvrant les scopes 1, 2 et 3, conformément aux normes ESRS (source : economie.gouv.fr). Le scope 3 est précisément celui qui intègre les émissions indirectes liées à la chaîne de valeur amont et aval, dont l’infrastructure IT externalisée. Le paquet Omnibus, adopté par le Parlement européen en décembre 2025, a réduit le périmètre d’application d’environ 50 000 à 10 000 entreprises dans l’Union européenne, avec un report de deux ans pour les vagues 2 et 3 (source : Réglementation-environnement.com, 2026). Mais pour les grands groupes de la vague 1, la publication des émissions de scope 3 est maintenue.

L’effet de cascade est plus large encore. Les PME non directement soumises à la CSRD devront fournir des données structurées à leurs clients donneurs d’ordres qui, eux, le sont (source : Claire Gérardin, 2026). L’infrastructure numérique va devoir se matérialiser dans les bilans de toute la chaîne. Or la question est rarement posée dans les audits carbone actuels : combien votre système d’information stocke-t-il de données non utilisées ? Quelle part de votre scope 3 représente l’énergie consommée par des serveurs qui hébergent des fichiers depuis cinq ans sans qu’une seule requête ne les ait touchés ?

Traiter sans stocker : une sobriété structurelle, pas cosmétique

La sobriété numérique est souvent réduite à ses formes les plus visibles : éteindre les équipements inutilisés, effacer les boîtes mail, désactiver les services inactifs. Ces gestes ont leur utilité, mais ils opèrent à la marge d’un problème architectural.

Le vrai levier est en amont, dans la conception même des pipelines de traitement. La logique dominante reste celle du stockage intermédiaire : les données sont collectées, puis stockées, puis traitées, puis analysées, parfois répliquées entre systèmes. Chaque étape génère une empreinte, et chaque duplication multiplie les surfaces de stockage actives. Ce postulat de stocker pour pouvoir traiter n’est pas une fatalité technique. Il est le résultat d’une habitude de conception.

Une architecture qui traite la donnée pendant son transit, sans jamais la persister dans un espace intermédiaire, réduit mécaniquement l’empreinte de stockage à zéro sur la couche de traitement. C’est le principe sur lequel repose la DataCell d’iD4Connect : chaque unité de traitement agit sur la donnée pendant son passage (nettoyage, transformation, enrichissement, routage) puis la libère. Rien ne s’accumule côté middleware. L’organisation du DataGraph orchestre ces unités sans jamais centraliser les données dans un hub intermédiaire. Le résultat n’est pas seulement un gain de performance ou de coût : c’est une architecture sobre par construction, dont l’empreinte environnementale est structurellement plus faible que celle d’un pipeline classique.

Quelques ordres de grandeur qui recadrent le débat :

4,4 % : part du numérique dans l’empreinte carbone française (ADEME-Arcep, janvier 2025)

46 % : part des datacenters dans l’empreinte carbone numérique, contre 16 % en 2020 (ADEME-Arcep, janvier 2025)

53 % : part des usages numériques français hébergés à l’étranger, sur des mix électriques plus carbonés (ADEME, 2025)

52 % : proportion des données stockées en entreprise qui sont inutilisées ou obsolètes, soit les « dark data » (Veritas)

6,4 millions de tonnes de CO2 : émissions annuelles du seul stockage de dark data dans le monde (Veritas)

60 % : hausse projetée de l’empreinte carbone du numérique en France d’ici 2040 si les trajectoires actuelles ne changent pas (rapport du Sénat, 2020)

Trois questions que chaque DSI devrait se poser avant de valider sa prochaine architecture

1. Savez-vous combien de données votre SI stocke sans jamais les relire ? La dark data ne se voit pas dans les tableaux de bord habituels. Elle ne génère pas d’alertes, ne ralentit pas les performances, n’alerte aucun monitoring. Elle consomme simplement de l’énergie, en silence, à chaque seconde. Un audit de cycle de vie des données (combien d’entre elles n’ont pas été accédées depuis plus de six mois, plus d’un an, plus de trois ans) est le point d’entrée le plus immédiat pour comprendre l’empreinte réelle d’un SI.

2. Votre empreinte carbone numérique intègre-t-elle le cycle de vie des données ? Les bilans carbone IT se concentrent souvent sur les équipements physiques et la consommation électrique mesurée. Le coût de l’egress, le coût du stockage fantôme, le coût des réplications automatiques oubliées : ces postes ne figurent presque jamais dans les analyses scope 3 actuelles. Pourtant, c’est là que se joue une part croissante de l’empreinte réelle, comme nous le détaillions dans notre article sur les coûts cachés du cloud.

3. Vos architectures de traitement peuvent-elles fonctionner sans stocker par défaut ? La question n’est pas de supprimer le stockage de toutes les données : certaines doivent être persistées. Elle est de distinguer les données qui doivent l’être de celles qui sont stockées par habitude ou par défaut d’architecture. Un pipeline qui traite en transit et ne stocke que ce qui a une valeur documentée est, par construction, plus sobre qu’un pipeline qui centralise d’abord et traite ensuite.

La sobriété numérique ne se décrète pas dans une charte RSE. Elle se construit dans les choix d’architecture, dans les politiques de cycle de vie des données, dans le regard qu’une organisation porte sur ce que ses serveurs hébergent réellement. Ne pas stocker, quand le traitement peut s’en passer, n’est pas une contrainte : c’est un acte de conception. Et en 2026, c’est aussi un acte écologique.

Découvrez comment iD4Connect traite la donnée sans jamais la stocker →

Su ERP no habla con su CRM. Sus datos de RR. HH. duermen en un rincón, aislados del resto. Y cada vez que un equipo de negocio añade una nueva herramienta SaaS, es una integración más que parchear. Bienvenido a la realidad del SI moderno, donde la empresa media maneja 897 aplicaciones diferentes (fuente: APPSeCONNECT). Aquí es donde entra en juego el middleware.

¿Qué es exactamente un middleware?

La palabra viene del inglés «middle» (medio) y «software» (programa). En la práctica, un middleware es un software que se sitúa entre las aplicaciones, las bases de datos y los sistemas operativos de un sistema de información para permitir que se comuniquen entre sí (fuente: IBM).

A menudo se le compara con el cemento de un edificio o con el sistema nervioso de una organización. Sin él, cada aplicación se queda en su silo, habla su propio idioma e ignora a las demás. Con él, el conjunto forma un sistema coherente donde la información circula, los procesos se encadenan y los equipos dejan de perder tiempo copiando datos de una herramienta a otra.

El término apareció oficialmente en una conferencia de la OTAN sobre ingeniería del software en 1968, y se consolidó en los años ochenta como forma de conectar las nuevas aplicaciones a los sistemas heredados (fuente: Wikipedia). Desde entonces, su papel no ha hecho más que crecer.

Por qué su SI lo necesita

La razón es sencilla: el SI moderno se ha convertido en un mosaico. ERP, CRM, herramientas de marketing automation, plataformas de RR. HH., aplicaciones de negocio especializadas, servicios cloud, bases de datos heredadas… La empresa media utiliza hoy 897 aplicaciones, y el 46 % de las grandes organizaciones supera las 1000 (fuente: ONEiO Cloud). Más preocupante aún: el 71 % de esas aplicaciones permanecen sin integrar, lo que multiplica las entradas manuales, los errores y los silos de datos.

Sin middleware, cada nueva aplicación obliga a desarrollar un conector a medida. Multiplicado por decenas de herramientas, el coste se dispara: Gartner estima que las empresas dedican entre el 30 % y el 40 % de su presupuesto de TI a gestionar la complejidad generada por las aplicaciones no integradas (fuente: APPSeCONNECT). El middleware cambia esa ecuación al ofrecer una capa de abstracción única: se desarrolla una vez, se conecta en todas partes.

El mercado refleja esta necesidad. El sector de la integración de aplicaciones empresariales debería alcanzar los 26 800 millones de dólares en 2026, con un crecimiento anual del 16,5 % (fuente: The Business Research Company). No es una moda pasajera, sino una respuesta estructural a un problema que no deja de agravarse.

Las grandes familias de middleware

No todos los middleware hacen lo mismo. Tradicionalmente se distinguen varias grandes categorías (fuente: AWS). El middleware orientado a mensajes (MOM) transmite mensajes entre aplicaciones de forma asíncrona, como una cola de espera: Apache Kafka y RabbitMQ son ejemplos populares. El middleware de integración de aplicaciones empresariales (EAI) conecta varios sistemas heterogéneos a través de un hub común, históricamente mediante un Enterprise Service Bus (ESB).

El iPaaS (Integration Platform as a Service) es la versión cloud native del EAI, que integra aplicaciones en un entorno híbrido. Es hoy el segmento más dinámico del mercado y se espera que supere los 17 000 millones de dólares en 2028, según Gartner (fuente: ONEiO Cloud). El middleware de API, o API Gateway, gestiona las peticiones entre aplicaciones, aplica políticas de seguridad y supervisa el rendimiento. Este segmento por sí solo representa el 28,7 % del mercado de la integración en 2026 (fuente: Persistence Market Research). Por último, el middleware de plataforma (servidores de aplicaciones, servidores web, CMS) proporciona una capa de ejecución común a las aplicaciones.

Esta diversidad no es casual: cada caso de uso tiene sus propias restricciones. Pero todos comparten la misma misión básica: hacer dialogar lo que no había sido pensado para hacerlo.

Los límites del middleware clásico

El middleware no es una solución mágica. Hay tres puntos ciegos que se repiten sistemáticamente.

En primer lugar, la duplicación de datos. La mayoría de los middleware clásicos funcionan copiando los datos de un sistema a otro, o centralizándolos en un hub intermedio. Resultado: la misma información existe en varias copias, a veces con versiones divergentes, y cada una es una superficie de exposición adicional para ataques o fugas.

En segundo lugar, la complejidad. El 45 % de las organizaciones citan la complejidad del middleware como una barrera, y el 39 % declara retrasos de integración debidos a problemas de interoperabilidad (fuente: Business Research Insights). Cuanto más crece el SI, más se convierte el propio middleware en un sistema que mantener, con sus propias dependencias y sus propios puntos de fallo.

Por último, la soberanía. Muchos middleware de integración son hoy servicios SaaS estadounidenses, sometidos a la Cloud Act. Los datos que transitan por ellos pueden ser solicitados legalmente por las autoridades estadounidenses, incluso si el cliente es europeo. Para los sectores regulados (sanidad, defensa, finanzas, sector público), este punto se vuelve bloqueante. Como explicábamos en nuestro artículo sobre la soberanía digital, la nacionalidad del proveedor prevalece sobre la ubicación de los servidores.

¿Y si el middleware no necesitase almacenar para funcionar?

La lógica histórica del middleware parte de un supuesto pocas veces cuestionado: para hacer circular los datos, primero hay que capturarlos, transformarlos y, a veces, almacenarlos. Eso es precisamente lo que genera la complejidad, la duplicación y la exposición.

iD4Connect propone otro enfoque: un middleware que trata los datos durante su tránsito, sin almacenarlos ni duplicarlos jamás. Cada DataCell actúa como una unidad de procesamiento inteligente (limpieza, transformación, enriquecimiento, enrutamiento) que se ejecuta sobre el dato durante su paso y después lo libera. Nada persiste, nada se acumula.

La orquestación de estas DataCells, estructurada en DataGraph, permite construir flujos complejos entre cualquier aplicación y en cualquier entorno: en local, cloud o híbrido. El Conector Universal se encarga de la ingesta multifuente a través de todos los protocolos estándar (JDBC, ODBC, MQTT, Kafka, REST…), sin imponer su propio formato.

El beneficio para el SI es triple: la superficie de exposición se reduce a cero, puesto que los datos nunca son almacenados por el middleware; la soberanía está garantizada por la propia arquitectura (diseño europeo, ejecución dentro del perímetro del cliente); y los costes operativos se mantienen predecibles.

En 2026, la verdadera pregunta tal vez ya no sea «qué middleware elegir», sino cómo hacer que su SI dialogue consigo mismo sin convertirlo en un cementerio de copias.

Your ERP doesn’t talk to your CRM. Your HR data sits isolated in a corner, cut off from everything else. And every time a business team adds a new SaaS tool, that’s one more integration to patch together. Welcome to the reality of the modern IT system, where the average enterprise juggles 897 different applications (source: APPSeCONNECT). This is where middleware comes in.

What exactly is middleware?

The word comes from « middle » and « software ». In practice, middleware is software that sits between the applications, databases, and operating systems of an information system, allowing them to communicate with each other (source: IBM).

It’s often described as the cement of a building or the nervous system of an organization. Without it, each application stays in its silo, speaks its own language, and ignores the others. With it, the whole forms a coherent system where information flows, processes chain together, and teams stop wasting time copying data from one tool to another.

The term first appeared officially at a NATO software engineering conference in 1968, then took hold in the 1980s as a way to connect new applications to legacy systems (source: Wikipedia). Its role has only grown since.

Why your IT system needs it

The reason is simple: the modern IT system has become a patchwork. ERP, CRM, marketing automation tools, HR platforms, specialized business applications, cloud services, legacy databases… The average enterprise now uses 897 applications, and 46% of large organizations exceed 1,000 (source: ONEiO Cloud). More worrying still, 71% of those applications remain unintegrated, which multiplies manual data entry, errors, and data silos.

Without middleware, each new application requires building a custom connector. Multiplied across dozens of tools, the cost explodes: Gartner estimates that enterprises spend 30 to 40% of their IT budget managing the complexity created by unintegrated applications (source: APPSeCONNECT). Middleware changes the equation by providing a single abstraction layer: build once, connect everywhere.

The market reflects this need. Enterprise application integration is expected to reach $26.8 billion in 2026, growing at 16.5% per year (source: The Business Research Company). Not a passing trend, but a structural answer to a problem that keeps getting worse.

The main families of middleware

Not all middleware does the same thing. Several broad categories are traditionally distinguished (source: AWS). Message Oriented Middleware (MOM) passes messages between applications asynchronously, much like a queue (Apache Kafka and RabbitMQ are popular examples). Enterprise Application Integration (EAI) middleware connects multiple heterogeneous systems through a common hub, historically through an Enterprise Service Bus (ESB).

iPaaS (Integration Platform as a Service) is the cloud native version of EAI, integrating applications across hybrid environments. It is now the most dynamic segment of the market, expected to exceed $17 billion by 2028 according to Gartner (source: ONEiO Cloud). API middleware, or API Gateways, handles API requests between applications, enforces security policies, and monitors performance. This segment alone accounts for 28.7% of the integration market in 2026 (source: Persistence Market Research). Finally, platform middleware (application servers, web servers, content management systems) provides a common runtime foundation for applications.

This diversity is no accident: each use case has its own constraints. But they all share the same fundamental mission: making things talk that weren’t designed to talk to each other.

The limits of traditional middleware

Middleware isn’t a silver bullet. Three blind spots keep coming up.

First, data duplication. Most traditional middleware works by copying data from one system to another, or by centralizing it in an intermediate hub. The result: the same information exists in multiple copies, sometimes with diverging versions, and each one is another attack surface or potential leak.

Second, complexity. 45% of organizations cite middleware complexity as a barrier, and 39% report integration delays caused by interoperability issues (source: Business Research Insights). The bigger the IT system grows, the more the middleware itself becomes a system to maintain, with its own dependencies and its own potential failure points.

Third, sovereignty. Many integration middleware products today are American SaaS services, subject to the Cloud Act. The data flowing through them can legally be requested by U.S. authorities, even if the client is European. For regulated sectors (healthcare, defense, finance, public sector), this becomes a deal breaker. As we explained in our article on digital sovereignty, the provider’s nationality outweighs the location of the servers.

What if middleware didn’t need to store anything to work?

The historical logic of middleware rests on one rarely questioned assumption: to move data around, you first have to capture it, transform it, and sometimes store it. That’s exactly what creates the complexity, the duplication, the exposure.

iD4Connect takes a different approach: middleware that processes data during transit, without ever storing or duplicating it. Each DataCell acts as an intelligent processing unit (cleaning, transformation, enrichment, routing) that runs on the data as it passes through, then releases it. Nothing persists, nothing accumulates.

The orchestration of these DataCells, structured as a DataGraph, makes it possible to build complex flows between any applications, in any environment: on premise, cloud, or hybrid. The Universal Connector handles multisource ingestion across all standard protocols (JDBC, ODBC, MQTT, Kafka, REST…), without forcing its own format.

The benefit for the IT system is threefold: the exposure surface is reduced to zero since the middleware never stores the data, sovereignty is guaranteed by the architecture itself (European design, execution within the client’s perimeter), and operating costs stay predictable.

In 2026, the real question may no longer be « which middleware to choose, » but how to make your IT system talk to itself without turning it into a graveyard of copies.

Votre ERP ne parle pas à votre CRM. Vos données RH dorment dans un coin, isolées du reste. Et chaque fois qu’une équipe métier ajoute un nouvel outil SaaS, c’est une intégration de plus à bricoler. Bienvenue dans la réalité du SI moderne, où l’entreprise moyenne jongle avec 897 applications différentes (source : APPSeCONNECT). C’est là que le middleware entre en scène.

Le middleware, c’est quoi exactement ?

Le mot vient de l’anglais « middle » (milieu) et « software » (logiciel). En français : intergiciel. Concrètement, un middleware est un logiciel qui s’intercale entre les applications, les bases de données et les systèmes d’exploitation d’un système d’information, pour leur permettre de communiquer entre eux (source : IBM).

On le compare souvent au ciment d’un édifice ou au système nerveux d’une entreprise. Sans lui, chaque application reste dans son silo, parle son propre langage et ignore les autres. Avec lui, l’ensemble forme un système cohérent où l’information circule, où les processus s’enchaînent, et où les équipes ne perdent plus leur temps à recopier des données d’un outil à l’autre.

Le terme est apparu officiellement à l’OTAN en 1968 lors d’une conférence sur le génie logiciel, puis s’est imposé dans les années 1980 pour relier les nouvelles applications aux systèmes existants (source : Wikipédia). Depuis, son rôle n’a fait que grandir.

Pourquoi votre SI en a besoin

La raison est simple : le SI moderne est devenu un patchwork. ERP, CRM, outils de marketing automation, plateformes RH, applications métiers spécialisées, services cloud, bases de données historiques… L’entreprise moyenne utilise aujourd’hui 897 applications, et 46 % des grandes structures dépassent les 1 000 (source : ONEiO Cloud). Plus inquiétant encore, 71 % de ces applications restent non intégrées entre elles, ce qui multiplie les saisies manuelles, les erreurs et les silos de données.

Sans middleware, chaque nouvelle application impose de développer un connecteur sur mesure. Multiplié par des dizaines d’outils, le coût explose : Gartner estime que les entreprises consacrent 30 à 40 % de leur budget IT à gérer la complexité créée par les applications non intégrées (source : APPSeCONNECT). Le middleware change la donne en fournissant une couche d’abstraction unique : on développe une fois, on connecte partout.

Le marché reflète cette nécessité. Le secteur de l’intégration d’applications d’entreprise devrait atteindre 26,8 milliards de dollars en 2026, avec une croissance annuelle de 16,5 % (source : The Business Research Company). Pas un effet de mode, donc, mais une réponse structurelle à un problème qui ne fait que s’aggraver.

Les grandes familles de middleware

Tous les middlewares ne font pas la même chose. On distingue traditionnellement plusieurs grandes catégories (source : AWS). Le middleware orienté message (MOM) fait transiter des messages entre applications de manière asynchrone, à la manière d’une file d’attente : Apache Kafka ou RabbitMQ en sont des exemples populaires. Le middleware d’intégration d’applications d’entreprise (EAI) connecte plusieurs systèmes hétérogènes au sein d’un même hub, historiquement via un Enterprise Service Bus (ESB).

L’iPaaS (Integration Platform as a Service) en est la version cloud native, qui intègre les applications dans un environnement hybride. C’est aujourd’hui le segment le plus dynamique du marché, attendu à plus de 17 milliards de dollars d’ici 2028 selon Gartner (source : ONEiO Cloud). Le middleware d’API, ou API Gateway, gère quant à lui les requêtes entre applications, applique des politiques de sécurité et surveille la performance. Ce segment représente à lui seul 28,7 % du marché de l’intégration en 2026 (source : Persistence Market Research). Enfin, le middleware de plateforme regroupe les serveurs d’applications, les serveurs web et les CMS, qui fournissent un socle d’exécution commun.

Cette diversité n’est pas un hasard : chaque cas d’usage a ses contraintes propres. Mais tous partagent la même mission de base : faire dialoguer ce qui n’avait pas été conçu pour le faire.

Les limites du middleware classique

Le middleware n’est pas une solution miracle. Trois angles morts reviennent systématiquement.

D’abord, la duplication des données. La plupart des middlewares classiques fonctionnent en copiant les données d’un système à l’autre, ou en les centralisant dans un hub intermédiaire. Résultat : la même information existe en plusieurs exemplaires, avec des versions parfois divergentes, et autant de surfaces d’exposition supplémentaires pour les attaques ou les fuites.

Ensuite, la complexité. 45 % des organisations citent la complexité du middleware comme un frein, et 39 % rapportent des retards d’intégration liés à des problèmes d’interopérabilité (source : Business Research Insights). Plus le SI grandit, plus le middleware lui-même devient un système à maintenir, avec ses propres dépendances et ses propres pannes potentielles.

Enfin, la souveraineté. Beaucoup de middlewares d’intégration sont aujourd’hui des services SaaS américains, soumis au Cloud Act. Les données qui transitent par eux peuvent légalement être demandées par les autorités américaines, même si le client est européen. Pour des secteurs réglementés (santé, défense, finance, secteur public), ce point devient bloquant. Comme nous l’expliquions dans notre article sur la souveraineté numérique, la nationalité du fournisseur prime sur la localisation des serveurs.

Et si le middleware n’avait pas besoin de stocker pour fonctionner ?

La logique historique du middleware repose sur un postulat rarement remis en cause : pour faire circuler les données, il faut d’abord les capturer, les transformer, parfois les stocker. C’est ce qui crée la complexité, la duplication, l’exposition.

iD4Connect propose une autre approche : un middleware qui traite la donnée pendant son transit, sans jamais la stocker ni la dupliquer. Chaque DataCell agit comme une unité de traitement intelligente: (nettoyage, transformation, enrichissement, routage) qui s’exécute sur la donnée pendant son passage, puis la libère. Rien ne persiste, rien ne s’accumule.

L’orchestration de ces DataCells, organisée en DataGraph, permet de bâtir des flux complexes entre n’importe quelles applications, dans n’importe quel environnement : sur site, cloud ou hybride. Le Connecteur Universel prend en charge l’ingestion multisources via tous les protocoles standards (JDBC, ODBC, MQTT, Kafka, REST…), sans imposer son propre format.

L’intérêt pour le SI est triple : la surface d’exposition est réduite à zéro puisque les données ne sont jamais stockées par le middleware, la souveraineté est garantie nativement par l’architecture (conçue en Europe et exécutée dans le périmètre du client), et le coût d’exploitation reste prévisible.

En 2026, la vraie question n’est probablement plus « quel middleware choisir », mais comment faire dialoguer son SI sans en faire un cimetière de copies.

Tu factura cloud sube cada mes, y no sabes realmente por qué. Las instancias de cómputo no han cambiado, el volumen de datos almacenados es estable, y sin embargo el total sigue creciendo. La razón se esconde en los márgenes: tarifas de salida de datos, transferencias entre regiones, NAT Gateway, direcciones IPv4 públicas, recuperación desde niveles de archivado. Unos céntimos por gigabyte, invisibles hasta que representan el 15% de la factura. En 2026, comprender estos costes ya no es opcional: es un requisito previo para pilotar tu infraestructura.

La promesa inicial y la realidad de la factura

El argumento del cloud siempre ha descansado sobre una ecuación simple: solo pagas lo que consumes, dejas de invertir en capital y pasas a un modelo operativo predecible. Esa promesa sigue siendo válida para los recursos de cómputo bien dimensionados. Se derrumba en el momento en que los datos empiezan a circular.

El principio fundador del modelo de precios de los hyperscalers es asimétrico por diseño: la entrada de datos (ingress) es gratuita y la salida (egress) se factura. AWS cobra $0,09/GB por los primeros 10 TB de datos que salen hacia Internet, Azure $0,087/GB, Google Cloud $0,12/GB por el primer terabyte (fuente: EgressCost.com, marzo 2026). Estas tarifas se aplican a cada byte que abandona la red del proveedor, ya sea hacia tus usuarios, hacia otro cloud o hacia tu datacenter on-premise.

El resultado es matemáticamente vertiginoso para las organizaciones que procesan volúmenes significativos. Una aplicación SaaS que sirve 50 TB de datos al mes desde AWS paga aproximadamente $4.300/mes solo en tarifas de egress, más de $51.000 al año únicamente para entregar sus propios datos a sus propios usuarios (fuente: EgressCost.com). Y eso sin contar las transferencias entre regiones, las replicaciones multi-AZ, las llamadas a la API y las demás líneas de facturación que se acumulan discretamente.

Según un análisis de CloudZero publicado en 2025, las tarifas de transferencia de datos representan entre el 6 y el 12% de las facturas cloud típicas, pero la mayoría de los equipos son incapaces de identificar con precisión de dónde proviene su gasto en egress (fuente: CloudZero, 2025, vía Deloitte). Gartner va más lejos y estima que en algunos casos las tarifas de egress pueden alcanzar el 40% de la factura cloud total (fuente: Gartner, vía Akave).

Las partidas que inflan la factura sin que nadie lo note

La dificultad no reside tanto en la tarifa publicada como en la multiplicidad de los factores desencadenantes. Los cargos por datos no se concentran en una sola línea de facturación: se distribuyen en decenas de subpartidas distintas, a menudo etiquetadas de forma diferente según el servicio de AWS, Azure o GCP de que se trate.

Las tarifas de salida hacia Internet son las más conocidas pero las menos anticipadas a escala. Una API que gestiona 10 TB de respuestas al mes genera aproximadamente $900/mes solo en egress de AWS. Una configuración de CDN mal ajustada, con una tasa de cache miss del 30% en un sitio de alto tráfico de vídeo, puede añadir silenciosamente varios miles de dólares al mes (fuente: CloudCostChefs, febrero 2026).

Las transferencias entre regiones se facturan a $0,02/GB en la mayoría de los proveedores. Insignificantes individualmente, se acumulan rápidamente en las arquitecturas de alta disponibilidad. Un job de copia de seguridad que replica 2 TB por noche hacia una región secundaria cuesta $1.200/mes solo en tarifas entre regiones. Automatizado y gobernado por reglas de retención, este tipo de flujo funciona a menudo durante meses sin que nadie supervise la línea correspondiente en el panel de control (fuente: Strategic Micro Systems, abril 2026).

El NAT Gateway es calificado de « coste oculto notorio » en varios análisis FinOps de 2026. Un solo NAT Gateway de AWS cuesta $32,40/mes en tarifas fijas, antes de procesar un solo byte, más $0,045/GB de datos procesados. Para un despliegue multi-AZ estándar con un NAT Gateway por zona de disponibilidad, la factura mensual supera fácilmente los $4.800 para una plataforma de tamaño medio, una línea que la mayoría de los paneles hacen desaparecer en la categoría genérica « Networking » (fuente: FirstPassLab, marzo 2026).

Las direcciones IPv4 públicas se convirtieron en una línea de coste propia desde que AWS introdujo en febrero de 2024 una facturación de $0,005/hora por dirección, esté asignada a una instancia activa o simplemente reservada e inactiva. Azure y GCP siguieron con estructuras similares. Para cuentas enterprise con cientos de load balancers, instancias RDS y Elastic IPs, la factura anual se cuenta en decenas de miles de dólares, únicamente por disponer de direcciones IP (fuente: CloudCostChefs, febrero 2026).

Las herramientas de monitoring y observabilidad raramente figuran en las estimaciones iniciales. Datadog, New Relic, Splunk o incluso el CloudWatch nativo: todos extraen datos de tu VPC hacia sus endpoints de ingesta, generando egress facturable. Una configuración de logs verbose en una flota de 50 instancias puede transferir varios cientos de GB al día sin que nadie relacione eso con la factura de red (fuente: Strategic Micro Systems, abril 2026).

El coste real del almacenamiento, más allá del precio anunciado

El marketing de los hyperscalers destaca los precios brutos de almacenamiento. Amazon S3 Standard a $0,023/GB/mes, Azure Blob Hot a $0,018/GB/mes, Google Cloud Storage Standard a $0,020/GB/mes: estas cifras son verídicas, pero representan solo una fracción del coste total de propiedad para datos que se utilizan realmente.

Para cargas de trabajo activas, la realidad se parece más a esto: el precio de almacenamiento puro representa aproximadamente el 30% de la factura total, y las tarifas de egress, cobradas cada vez que un dato se descarga, se sirve a un usuario o se mueve entre servicios, constituyen el 70% restante (fuente: Akave, enero 2026). Azure cobra $0,018/GB por almacenamiento pero $0,087/GB por egress: una diferencia de uno a cinco.

Algunas cifras que reencuadran el debate:

• 6 a 12%: cuota de las tarifas de transferencia de datos en una factura cloud típica (CloudZero, 2025)

• 27%: cuota del presupuesto cloud que las empresas declaran desperdiciar, según los responsables cloud (Deloitte, 2025)

• 50%: proporción de organizaciones que superaron su presupuesto cloud el año pasado, con una desviación media del 15% (Deloitte / Flexera, 2025)

• 30 a 40%: reducción potencial de costes cloud gracias a prácticas FinOps estructuradas (Deloitte, 2025)

• 45%: organizaciones que han repatriado cargas de trabajo al on-premise o a proveedores alternativos, citando costes de transferencia imprevisibles como razón principal (IDC, 2025)

Las tarifas de recuperación de datos desde los niveles de archivado añaden aún otra capa de invisibilidad. AWS Glacier Deep Archive resulta atractivo a $1/TB/mes frente a $23/TB de S3 Standard. Pero las tarifas de recuperación se aplican en cada acceso. Añade las penalizaciones por eliminación anticipada (se impone una duración mínima de almacenamiento de 90 días en muchos niveles de archivado), y los ahorros teóricos se evaporan en cuanto los patrones de acceso no son exactamente los previstos durante el dimensionamiento inicial (fuente: DoiT, marzo 2026).

Lo que cambia el Data Act europeo (y lo que aún no cambia)

La presión regulatoria empieza a morder en las prácticas de los hyperscalers. El Data Act europeo, que entró en aplicación el 12 de septiembre de 2025, obliga a los proveedores de servicios cloud a eliminar los obstáculos al cambio de proveedor, incluidas las tarifas de egress en una migración. AWS, Azure y Google Cloud han anunciado programas de gratuidad de egress para los clientes que abandonen su plataforma (fuente: Data Center Dynamics, marzo 2026).

Pero la lectura de las condiciones aplicables templa el entusiasmo. En Azure, la gratuidad del egress solo se aplica a la transferencia mediante Internet estándar, no vía ExpressRoute, y únicamente si el cliente cierra íntegramente su cuenta en los 60 días siguientes a la solicitud. En AWS, el programa no cubre el uso multi-cloud continuo. En Google, la gratuidad está condicionada a una salida total o reservada a un caso de uso específico (fuente: The Register, septiembre 2025).

La supresión total de las tarifas de egress está prevista para el 12 de enero de 2027. Mientras tanto, entre septiembre de 2025 y enero de 2027, los proveedores pueden seguir cobrando tarifas de egress « a coste », sin margen, pero la definición de ese « coste real » sigue siendo vaga y difícil de auditar para el cliente (fuente: Comisión Europea).

Lo que el Data Act no resuelve aún: las tarifas de transferencia entre servicios dentro del mismo proveedor, los costes de NAT Gateway, las tarifas de monitoring externo y todos los microcargos que inflan las facturas sin llevar nunca la etiqueta de « egress ». Los reguladores atacan la salida; los costes ocultos se desplazan hacia las tuberías internas.

Tres preguntas que todo CIO debería hacerse antes de firmar un compromiso cloud

1. ¿Cuál es el TCO real de mis datos, transferencias incluidas? El coste total de propiedad de una arquitectura cloud no se limita al almacenamiento y el cómputo. Incorpora cada gigabyte en movimiento, entre regiones, hacia los usuarios, hacia las herramientas de análisis, hacia los sistemas de copia de seguridad. Sin modelizar los flujos de datos de antemano, el presupuesto es una ficción.

2. ¿Dónde se procesan mis datos, no solo dónde se almacenan? Elegir el proveedor de alojamiento no es suficiente. Si el procesamiento analítico pasa por un motor externo, si los logs van hacia una plataforma de observabilidad de terceros, si los pipelines ETL replican datos entre regiones, cada salto genera egress facturable, independientemente de la soberanía del almacenamiento inicial. El mismo razonamiento que aplicamos a los datos sanitarios: el alojamiento soberano no protege si la cadena de tratamiento no lo es.

3. ¿Mi arquitectura minimiza los movimientos de datos innecesarios? Antes de optimizar la tarifa de egress, hay que identificar las transferencias que no deberían haber existido. Los endpoints VPC no configurados, los logs verbose, las replicaciones automáticas olvidadas, los CDN mal ajustados: en la mayoría de las auditorías FinOps, aproximadamente un tercio de los costes de transferencia identificados proviene de workloads que nadie sabía que seguían activos (fuente: Strategic Micro Systems, abril 2026).

La promesa del cloud no era falsa. Pero era incompleta. Pagar por uso exige comprender con precisión lo que se consume, incluido lo que no se ve. Las organizaciones que controlan su factura cloud en 2026 no son las que negociaron las mejores tarifas de almacenamiento: son las que cartografiaron cada flujo de datos y eliminaron las transferencias superfluas antes de que se facturaran. Una arquitectura que minimiza los movimientos de datos no es solo más barata: está menos expuesta, es más soberana y más predecible.

Descubra cómo iD4Connect aborda el procesamiento de datos sin almacenamiento intermedio →

Your cloud bill keeps climbing every month, and you can’t quite figure out why. Compute instances haven’t changed, stored data volumes are stable, and yet the total line keeps creeping up. The reason hides in the margins: data egress fees, inter-region transfers, NAT Gateway charges, public IPv4 addresses, retrieval from archival tiers. A few cents per gigabyte, invisible until they account for 15% of the bill. In 2026, understanding these costs is no longer optional: it is a prerequisite for running your infrastructure.

The initial promise and the reality of the invoice

The cloud argument has always rested on a simple equation: you only pay for what you consume, you no longer invest in capital, you move to a predictable operational model. That promise still holds for well-sized compute resources. It collapses the moment data starts moving.

The foundational principle of hyperscaler pricing is asymmetric by design: data ingress is free and egress is billed. AWS charges $0.09/GB for the first 10 TB of data leaving to the Internet, Azure $0.087/GB, Google Cloud $0.12/GB for the first terabyte (source: EgressCost.com, March 2026). These rates apply to every byte that leaves the provider’s network, whether toward your users, another cloud, or your on-premise datacenter.

The result is mathematically staggering for organizations processing significant volumes. A SaaS application serving 50 TB of data per month from AWS pays roughly $4,300/month in egress fees alone, more than $51,000 per year simply to deliver its own data to its own users (source: EgressCost.com). And that is before counting inter-region transfers, multi-AZ replication, API calls, and the other billing lines quietly accumulating in the background.

According to a CloudZero analysis published in 2025, data transfer fees account for 6 to 12% of typical cloud invoices, but most teams are unable to pinpoint exactly where their egress spend is coming from (source: CloudZero, 2025, via Deloitte). Gartner goes further, estimating that in some cases egress fees can reach 40% of the total cloud bill (source: Gartner, via Akave).

The line items inflating your bill without anyone noticing

The difficulty lies not so much in the listed rate as in the sheer number of triggers. Data charges do not concentrate in a single billing line: they spread across dozens of distinct sub-items, often labelled differently depending on which AWS, Azure, or GCP service is involved.

Internet egress fees are the best known but the least anticipated at scale. An API handling 10 TB of responses per month generates roughly $900/month in AWS egress alone. A poorly tuned CDN configuration, with a 30% cache miss rate on a high-traffic video site, can silently add several thousand dollars a month (source: CloudCostChefs, February 2026).

Inter-region transfers are billed at $0.02/GB on most providers. Negligible individually, they accumulate rapidly on high-availability architectures. A backup job replicating 2 TB per night to a secondary region costs $1,200/month in inter-region fees alone. Automated and governed by retention rules, this kind of flow often runs for months without anyone monitoring the corresponding line in the dashboard (source: Strategic Micro Systems, April 2026).

NAT Gateway is described as a « notorious hidden cost » across multiple FinOps analyses in 2026. A single AWS NAT Gateway costs $32.40/month in fixed fees, before processing a single byte, plus $0.045/GB of data processed. For a standard multi-AZ deployment with one NAT Gateway per availability zone, the monthly bill easily exceeds $4,800 for a mid-sized platform, a line that most dashboards quietly absorb into the generic « Networking » category (source: FirstPassLab, March 2026).

Public IPv4 addresses became their own cost line after AWS introduced a $0.005/hour charge per address in February 2024, whether attached to an active instance or simply reserved and unused. Azure and GCP followed with similar structures. For enterprise accounts with hundreds of load balancers, RDS instances, and Elastic IPs, the annual bill runs into tens of thousands of dollars, purely to hold IP addresses (source: CloudCostChefs, February 2026).

Monitoring and observability tools rarely appear in initial estimates. Datadog, New Relic, Splunk, and even native CloudWatch all pull data from your VPC to their ingestion endpoints, generating billable egress. A verbose log configuration across a fleet of 50 instances can transfer several hundred GB per day without anyone connecting the dots to the network bill (source: Strategic Micro Systems, April 2026).

The real cost of storage, beyond the advertised price

Hyperscaler marketing leads with raw storage prices. Amazon S3 Standard at $0.023/GB/month, Azure Blob Hot at $0.018/GB/month, Google Cloud Storage Standard at $0.020/GB/month: these figures are accurate, but they represent only a fraction of the total cost of ownership for data that is actually used.

For active workloads, the reality looks more like this: raw storage represents roughly 30% of the total bill, and egress fees, charged every time data is downloaded, served to a user, or moved between services, account for the remaining 70% (source: Akave, January 2026). Azure charges $0.018/GB for storage but $0.087/GB for egress: a fivefold gap.

A few figures that reframe the debate:

• 6 to 12%: share of data transfer fees in a typical cloud bill (CloudZero, 2025)

• 27%: share of cloud budget that companies say they waste, according to cloud executives (Deloitte, 2025)

• 50%: proportion of organizations that exceeded their cloud budget last year, with an average overrun of 15% (Deloitte / Flexera, 2025)

• 30 to 40%: potential cloud cost reduction through structured FinOps practices (Deloitte, 2025)

• 45%: organizations that have repatriated workloads to on-premise or alternative providers, citing unpredictable transfer costs as the main reason (IDC, 2025)

Retrieval fees from archival tiers add yet another layer of invisibility. AWS Glacier Deep Archive looks attractive at $1/TB/month compared to $23/TB for S3 Standard. But retrieval fees apply on every access. Add early deletion penalties (a minimum storage duration of 90 days is enforced across many archival tiers), and the theoretical savings evaporate the moment access patterns differ from those anticipated during initial sizing (source: DoiT, March 2026).

What the European Data Act changes (and what it does not yet change)

Regulatory pressure is beginning to bite into hyperscaler practices. The European Data Act, which entered into application on 12 September 2025, requires cloud service providers to remove barriers to switching providers, including egress fees on migration. AWS, Azure, and Google Cloud have all announced egress waiver programs for customers leaving their platform (source: Data Center Dynamics, March 2026).

But reading the applicable conditions tempers the enthusiasm. At Azure, the egress waiver only applies to standard Internet transfer, not via ExpressRoute, and only if the customer fully closes their account within 60 days of the request. At AWS, the program does not cover ongoing multi-cloud use. At Google, the waiver is contingent on a complete exit or reserved for a specific use case (source: The Register, September 2025).

Full elimination of egress fees is scheduled for 12 January 2027. In the meantime, between September 2025 and January 2027, providers can still charge egress fees « at cost », without margin, but the definition of that « actual cost » remains vague and difficult for customers to audit (source: European Commission).

What the Data Act does not yet resolve: inter-service transfer fees within the same provider, NAT Gateway costs, external monitoring fees, and all the micro-charges that inflate invoices without ever carrying the « egress » label. Regulators are tackling the exit; the hidden costs are shifting into the internal pipes.

Three questions every CIO should ask before signing a cloud commitment

1. What is the real TCO of my data, transfers included? The total cost of ownership of a cloud architecture is not limited to storage and compute. It incorporates every gigabyte in motion, between regions, toward users, toward analytics tools, toward backup systems. Without modeling data flows upfront, the budget is fiction.

2. Where is my data processed, not just stored? Choosing a hosting provider is not enough. If analytical processing goes through an external engine, if logs flow to a third-party observability platform, if ETL pipelines replicate data across regions, each hop generates billable egress, regardless of the sovereignty of the initial storage. The same reasoning applies to healthcare data: sovereign hosting does not protect if the processing chain is not.

3. Does my architecture minimize unnecessary data movement? Before optimizing egress pricing, identify transfers that should not have existed in the first place. Unconfigured VPC endpoints, verbose logs, forgotten automated replications, poorly tuned CDNs: in most FinOps audits, roughly a third of identified transfer costs come from workloads nobody knew were still running (source: Strategic Micro Systems, April 2026).

The cloud promise was not false. But it was incomplete. Paying per use requires precisely understanding what you consume, including what you cannot see. The organizations that control their cloud bill in 2026 are not those who negotiated the best storage rates: they are those who mapped every data flow and eliminated unnecessary transfers before they could be billed. An architecture that minimizes data movement is not just cheaper: it is less exposed, more sovereign, and more predictable.

Discover how iD4Connect addresses data processing without intermediate storage →

Votre facture cloud augmente chaque mois, et vous ne savez pas vraiment pourquoi. Les instances de calcul n’ont pas bougé, le volume de données stockées est stable, et pourtant la ligne de total grimpe. La raison se cache dans les marges : frais de sortie de données, transferts inter-régions, NAT Gateway, IPv4 publiques, récupération depuis les tiers d’archivage. Des centimes par gigaoctet, invisibles jusqu’au moment où ils représentent 15 % de la facture. En 2026, comprendre ces coûts n’est plus optionnel, c’est un prérequis pour piloter son infrastructure.

La promesse initiale et la réalité de la facture

L’argument du cloud a toujours reposé sur une équation simple : vous ne payez que ce que vous consommez, vous n’investissez plus en capital, vous passez à un modèle opérationnel prévisible. Cette promesse reste vraie pour les ressources de calcul bien dimensionnées. Elle s’effondre dès que les données commencent à circuler.

Le principe fondateur du modèle tarifaire des hyperscalers est asymétrique par construction : l’entrée de données (ingress) est gratuite et la sortie (egress) est facturée. AWS facture 0,09 $/Go pour les premiers 10 To de données sortant vers Internet, Azure 0,087 $/Go, Google Cloud 0,12 $/Go pour le premier téraoctet (source : EgressCost.com, mars 2026). Ces tarifs s’appliquent à chaque octet qui quitte le réseau du fournisseur, que ce soit vers vos utilisateurs, vers un autre cloud ou vers votre datacenter on-premise.

Le résultat est mathématiquement vertigineux pour les organisations qui traitent des volumes significatifs. Une application SaaS qui sert 50 To de données par mois depuis AWS paie environ 4 300 $/mois en frais d’egress seuls, soit plus de 51 000 $ par an uniquement pour délivrer ses propres données à ses propres utilisateurs (source : EgressCost.com). Et ça, c’est sans compter les transferts inter-régions, les réplications multi-AZ, les appels API, et les autres lignes de facturation qui s’accumulent discrètement.

Selon une analyse CloudZero publiée en 2025, les frais de transfert de données représentent entre 6 et 12 % des factures cloud typiques — mais la plupart des équipes sont incapables d’identifier précisément d’où vient leur dépense en egress (source : CloudZero, 2025, via Deloitte). Gartner estime même que dans certains cas, les frais d’egress peuvent atteindre 40 % de la facture cloud totale (source : Gartner, via Akave).

Les postes qui gonflent la facture sans que personne ne le voie

La difficulté n’est pas tant le tarif affiché que la multiplicité des déclencheurs. Les charges de données ne se concentrent pas sur une seule ligne de facturation : elles se répartissent sur des dizaines de sous-postes distincts, souvent intitulés différemment selon le service AWS, Azure ou GCP concerné.

Les frais de sortie vers Internet sont les plus connus mais les moins bien anticipés à l’échelle. Une API gérant 10 To de réponses par mois génère environ 900 $/mois rien en egress AWS. Une configuration CDN mal ajustée, avec un taux de cache miss de 30 % sur un site à fort trafic vidéo, peut silencieusement ajouter plusieurs milliers de dollars par mois (source : CloudCostChefs, février 2026).

Les transferts inter-régions sont facturés 0,02 $/Go sur la plupart des providers. Anodins à l’unité, ils s’accumulent rapidement sur les architectures de haute disponibilité. Un job de sauvegarde répliquant 2 To par nuit vers une région secondaire coûte 1 200 $/mois en frais inter-régions seuls. Automatisé et piloté par des règles de rétention, ce type de flux fonctionne souvent pendant des mois sans que personne ne surveille la ligne correspondante dans le tableau de bord (source : Strategic Micro Systems, avril 2026).

Le NAT Gateway est qualifié de « coût caché notoire » par plusieurs analyses FinOps 2026. Un seul NAT Gateway AWS coûte 32,40 $/mois en frais fixes, avant même de traiter un seul octet, plus 0,045 $/Go de données traitées. Pour un déploiement multi-AZ standard avec un NAT Gateway par zone de disponibilité, la facture mensuelle dépasse facilement les 4 800 $ pour une plateforme de taille intermédiaire, une ligne que la plupart des tableaux de bord font disparaître dans la catégorie générique « Networking » (source : FirstPassLab, mars 2026).

Les adresses IPv4 publiques sont devenues une ligne de coût à part entière depuis que AWS a introduit en février 2024 une facturation de 0,005 $/heure par adresse — qu’elle soit attachée à une instance active ou qu’elle soit simplement réservée et inutilisée. Azure et GCP ont suivi avec des structures similaires. Pour des comptes enterprise avec des centaines de load balancers, d’instances RDS et d’Elastic IP, la facture annuelle se compte en dizaines de milliers de dollars, uniquement pour disposer d’adresses IP (source : CloudCostChefs, février 2026).

Les outils de monitoring et d’observabilité figurent rarement dans les estimations initiales. Datadog, New Relic, Splunk, ou même CloudWatch natif : tous extraient des données de votre VPC vers leurs endpoints d’ingestion, générant de l’egress facturable. Une configuration de logs verbose sur une flotte de 50 instances peut transférer plusieurs centaines de Go par jour sans que personne n’ait fait le lien avec la facture réseau (source : Strategic Micro Systems, avril 2026).

Le coût réel du stockage, au-delà du prix affiché

La communication marketing des hyperscalers met en avant les prix de stockage brut. Amazon S3 Standard à 0,023 $/Go/mois, Azure Blob Hot à 0,018 $/Go/mois, Google Cloud Storage Standard à 0,020 $/Go/mois : ces chiffres sont vrais, mais ils ne représentent qu’une fraction du coût total d’ownership pour des données réellement utilisées.

Pour des charges de travail actives, la réalité ressemble davantage à ceci : le prix de stockage pur représente environ 30 % de la facture totale, et les frais d’egress, facturés à chaque fois qu’une donnée est téléchargée, servie à un utilisateur ou déplacée entre services, constituent les 70 % restants (source : Akave, janvier 2026). Azure facture 0,018 $/Go pour le stockage mais 0,087 $/Go pour l’egress : l’écart est de 1 à 5.

Quelques ordres de grandeur qui recadrent le débat :

• 6 à 12 % : part des frais de transfert de données dans une facture cloud typique (CloudZero, 2025)

• 27 % : part du budget cloud que les entreprises déclarent gaspiller, selon les responsables cloud (Deloitte, 2025)

• 50 % : proportion d’organisations qui ont dépassé leur budget cloud l’an dernier, avec un dépassement moyen de 15 % (Deloitte / Flexera, 2025)

• 30 à 40 % : réduction potentielle des coûts cloud grâce à des pratiques FinOps structurées (Deloitte, 2025)

• 45 % : organisations ayant rapatrié des charges de travail vers le on-premise ou des prestataires alternatifs, citant des coûts de transfert imprévisibles comme raison principale (IDC, 2025)

Les frais de récupération des données depuis les tiers d’archivage ajoutent encore une couche d’invisibilité. AWS Glacier Deep Archive est attractif à 1 $/To/mois, contre 23 $/To pour S3 Standard. Mais les frais de récupération s’appliquent à chaque accès. Ajoutez les pénalités de suppression anticipée (une durée de stockage minimale de 90 jours est imposée sur de nombreux tiers d’archivage), et les économies théoriques s’évaporent dès que les patterns d’accès ne sont pas exactement ceux prévus lors du dimensionnement initial (source : DoiT, mars 2026).

Ce que le Data Act européen change (et ce qu’il ne change pas encore)

La pression réglementaire commence à mordre sur les pratiques des hyperscalers. Le Data Act européen, entré en application le 12 septembre 2025, oblige les fournisseurs de services cloud à supprimer les obstacles au changement de prestataire, dont les frais d’egress lors d’une migration. AWS, Azure et Google Cloud ont tous annoncé des programmes de gratuité d’egress pour les clients qui quittent leur plateforme (source : Data Center Dynamics, mars 2026).

Mais la lecture des conditions applicables tempère l’enthousiasme. Chez Azure, la gratuité d’egress ne s’applique qu’au transfert via Internet standard, pas via ExpressRoute, et uniquement si le client ferme intégralement son compte dans les 60 jours suivant la demande. Chez AWS, le programme ne couvre pas l’usage multi-cloud continu. Chez Google, la gratuité est conditionnée à une sortie totale ou réservée à un cas d’usage spécifique (source : The Register, septembre 2025).

La suppression totale des frais d’egress est planifiée pour le 12 janvier 2027. En attendant, entre septembre 2025 et janvier 2027, les fournisseurs peuvent encore facturer des frais d’egress « au coût », sans marge, mais la définition de ce « coût réel » reste floue et difficile à auditer pour le client (source : Commission européenne).

Ce que le Data Act ne règle pas encore : les frais de transfert inter-services au sein d’un même fournisseur, les coûts de NAT Gateway, les frais de monitoring externes, et tous les micro-frais qui gonflent les factures sans jamais porter l’étiquette « egress ». Les régulateurs s’attaquent à la sortie ; les coûts cachés se déplacent dans les tuyaux internes.

Trois questions que chaque DSI devrait se poser avant de signer un engagement cloud

1. Quel est le vrai TCO de mes données, transferts compris ? Le total cost of ownership d’une architecture cloud ne se limite pas au stockage et au calcul. Il intègre chaque gigaoctet qui se déplace, entre régions, vers les utilisateurs, vers les outils d’analyse, vers les systèmes de sauvegarde. Sans modélisation des flux de données en amont, le budget est une fiction.

2. Où mes données sont-elles traitées, et pas seulement stockées ? Le choix du provider d’hébergement ne suffit pas. Si le traitement analytique passe par un moteur externe, si les logs partent vers une plateforme d’observabilité tiers, si les pipelines ETL répliquent des données entre régions, chaque saut génère de l’egress facturable, indépendamment de la souveraineté du stockage initial. C’est le même raisonnement que nous développions pour les données de santé : l’hébergement souverain ne protège pas si la chaîne de traitement ne l’est pas.

3. Mon architecture minimise-t-elle les mouvements de données inutiles ? Avant d’optimiser le tarif de l’egress, il faut identifier les transferts qui n’auraient pas dû exister. Les endpoints VPC non configurés, les logs verbeux, les réplications automatiques oubliées, les CDN mal paramétrés : dans la majorité des audits FinOps, environ un tiers des coûts de transfert identifiés provient de workloads que personne ne savait encore actifs (source : Strategic Micro Systems, avril 2026).

La promesse du cloud n’était pas fausse. Mais elle était incomplète. Payer à l’usage suppose de comprendre précisément ce qu’on consomme, y compris ce qu’on ne voit pas. Les organisations qui maîtrisent leur facture cloud en 2026 ne sont pas celles qui ont négocié les meilleurs tarifs de stockage : ce sont celles qui ont cartographié chaque flux de données et éliminé les transferts superflus avant de les facturer. Une architecture qui minimise les mouvements de données n’est pas seulement moins chère : elle est moins exposée, plus souveraine, et plus prévisible.

Découvrez comment iD4Connect adresse la question du traitement des données sans stockage intermédiaire →