Catégorie : Technologie

La directive NIS2 est désormais le cadre de référence de la cybersécurité européenne. Pour les DSI et les RSSI, elle ne se limite pas à une nouvelle case de conformité à cocher : elle oblige à revoir la manière dont les données entrent dans le système d’information, y circulent et en sortent. Voici ce qu’elle impose vraiment, et pourquoi la façon dont vous faites transiter vos flux devient un sujet de premier plan.

NIS2, une directive qui change d’échelle

NIS2, c’est la directive (UE) 2022/2555, adoptée fin 2022 et entrée en vigueur en janvier 2023. Elle succède à la première directive NIS de 2016, devenue trop étroite face à l’ampleur prise par les cyberattaques. La Commission européenne la présente comme le socle d’un niveau commun et élevé de cybersécurité dans toute l’Union.

Le calendrier est simple à retenir : les États membres devaient la transposer dans leur droit national avant le 17 octobre 2024. En France, c’est l’ANSSI qui pilote cette transposition et accompagne les organisations concernées. Le texte ne se contente pas d’ajouter des obligations : il élargit fortement le périmètre couvert par NIS1, comme le souligne l’ENISA.

Ce changement d’échelle n’a rien de cosmétique. Là où la première directive laissait beaucoup de marge d’interprétation aux États, NIS2 harmonise les critères, les seuils et les sanctions. Pour une entreprise déjà soumise à NIS1, l’enjeu est de mesurer ce qui devient plus strict ; pour les nouvelles entités concernées, il faut souvent partir d’une page presque blanche.

Qui est concerné, et à quel titre

Là où NIS1 visait un nombre restreint d’acteurs, NIS2 couvre environ dix-huit secteurs. On y trouve autant d’infrastructures vitales que d’activités numériques et industrielles, comme le détaille la Commission européenne.

• Énergie, transports, banque et marchés financiers
• Santé, eau potable, eaux usées
• Infrastructures numériques, administration publique, espace
• Services postaux, gestion des déchets, agroalimentaire, fabrication

NIS2 introduit surtout une distinction structurante : les entités essentielles et les entités importantes. Les premières regroupent les acteurs les plus critiques, soumis à une supervision renforcée ; les secondes relèvent d’un régime allégé mais restent pleinement responsables en cas de manquement. L’ANSSI précise les critères de taille et de secteur qui font basculer une organisation dans l’une ou l’autre catégorie.

Cette classification a une conséquence pratique : elle détermine l’intensité des contrôles, mais pas la nature des obligations, qui restent largement communes. Autrement dit, être classé « important » plutôt qu’« essentiel » ne dispense de presque rien. Mieux vaut donc vérifier tôt son statut pour dimensionner correctement les efforts à fournir.

Ce que NIS2 impose concrètement

Le cœur de la directive tient dans une série d’obligations que tout DSI ou RSSI doit pouvoir démontrer, et pas seulement déclarer. L’ENISA, l’agence de l’Union pour la cybersécurité, en fournit le cadre technique et les lignes directrices.

• Des mesures de gestion des risques cyber, proportionnées et documentées
• La sécurité de la chaîne d’approvisionnement, fournisseurs et sous-traitants compris
• La notification des incidents selon un calendrier strict
• La responsabilité directe des organes de direction

La sécurité de la chaîne d’approvisionnement mérite une attention particulière. NIS2 vous rend responsable non seulement de vos propres systèmes, mais aussi de maillons que vous ne contrôlez pas directement : prestataires, éditeurs de logiciels, hébergeurs. Or ces maillons échangent des données avec vous en permanence, ce qui déplace le sujet de la sécurité vers les interfaces et les flux.

Le volet notification est particulièrement cadré. Selon le texte de la directive, une alerte précoce doit partir dans les 24 heures suivant la détection, une notification plus complète dans les 72 heures, puis un rapport final dans un délai d’un mois. Ce tempo suppose de savoir très vite quelles données ont été touchées, et par quels chemins elles transitaient.

Tenir ces délais est un exercice opérationnel exigeant. Vous ne pouvez pas reconstituer en 24 heures un historique que vous n’avez pas collecté en amont. C’est là que la capacité à tracer les flux en continu fait la différence entre une notification maîtrisée et une reconstitution dans l’urgence.

Deux points modifient la gouvernance. D’abord, la responsabilité des dirigeants est engagée directement, ce qui fait remonter le sujet jusqu’au comité de direction. Ensuite, les sanctions sont dissuasives : jusqu’à 10 millions d’euros ou 2 % du chiffre d’affaires annuel mondial pour les entités essentielles, comme le rappelle l’ANSSI.

Pourquoi cela touche directement la circulation des données

La plupart des exigences de NIS2 se ramènent à une question concrète : savez-vous où vont vos données, et pouvez-vous le prouver ? Le panorama des menaces de l’ENISA montre que les attaques passant par la chaîne d’approvisionnement et par les flux entre systèmes progressent d’année en année.

Or chaque fois qu’une donnée est copiée dans un entrepôt, dupliquée dans un système intermédiaire ou conservée « au cas où », vous ajoutez une zone à protéger, à surveiller et à justifier. Le rapport Cost of a Data Breach d’IBM chiffre chaque année ce que coûtent ces zones lorsqu’elles sont compromises.

Chaque copie de donnée que vous n’avez pas créée est une brèche que vous n’aurez pas à défendre.

Réduire la surface d’attaque n’est donc pas un simple principe de sécurité : c’est une manière directe de rendre la conformité plus tenable dans la durée. Moins vous accumulez de données au repos, moins vous avez de points à chiffrer, à tracer et à auditer. La logique de NIS2 pousse dans ce sens : maîtriser les flux, plutôt que multiplier les copies.

L’orchestration des données en transit, une réponse structurelle

Traiter la donnée « en transit » consiste à la faire circuler, la transformer et la distribuer en temps réel, sans la figer dans un stockage à chaque étape. Cette approche répond à plusieurs exigences de NIS2 en même temps, au lieu de les traiter comme des chantiers séparés.

Le premier gain concerne la surface d’attaque. Sans copie intermédiaire au repos, il y a mécaniquement moins de zones à défendre, un point que les analyses de Gartner sur la cybersécurité rappellent régulièrement. Le deuxième gain concerne la traçabilité : si chaque flux est journalisé, vous disposez d’un historique exploitable pour la notification d’incident comme pour l’audit.

Ce lien entre traçabilité et notification est souvent sous-estimé. Un incident se qualifie d’autant plus vite que l’on sait quels flux ont été affectés, vers quels destinataires et pendant combien de temps. Journaliser la circulation des données, plutôt que leur seul état final, transforme l’obligation de notification en une lecture d’un historique déjà constitué.

Le troisième gain touche la souveraineté et la résilience. Une orchestration qui reste dans le périmètre de l’organisation, déployable on-premise, limite les transferts vers des systèmes tiers dont vous ne maîtrisez ni la localisation ni la disponibilité. L’ENISA relie précisément cette maîtrise à la résilience et à la sécurité de la chaîne d’approvisionnement des données.

Une illustration d’approche

Pour rendre cette logique concrète, prenons le cas d’un middleware d’orchestration comme iD4Connect. Son principe est de traiter les flux en temps réel, sans stockage intermédiaire, ce qui limite par construction le nombre de copies créées le long du parcours de la donnée.

Concrètement, chaque flux transite, est transformé si nécessaire, puis distribué, tout en étant journalisé. L’ensemble reste déployable dans le périmètre de l’organisation, en on-premise, en cloud ou en edge, selon les contraintes de souveraineté. Ce n’est pas une solution miracle : c’est une façon d’aligner l’architecture technique sur les exigences de NIS2 plutôt que de les rattraper après coup.

Pour un DSI, l’intérêt est de raisonner en amont : réduire les points de stockage, tracer les échanges et garder la main sur la localisation. C’est une posture d’architecture, pas un produit que l’on ajoute à la fin pour cocher une case.

Par où commencer

La première étape n’est pas technique, elle est cartographique : recenser vos flux de données, leurs points d’entrée, leurs copies et leurs destinataires. Sans cette vision d’ensemble, aucune des obligations de la directive (UE) 2022/2555 ne peut être tenue durablement.

Cette cartographie n’est pas qu’un exercice de documentation. Elle sert de base à l’analyse de risques, à la sécurisation des interfaces avec vos fournisseurs et à la préparation des notifications. Sans elle, chaque nouvelle obligation se traite au coup par coup, ce qui coûte plus cher et protège moins bien dans la durée.

Vient ensuite la question à poser pour chaque flux : cette donnée doit-elle vraiment être stockée ici, ou peut-elle simplement transiter ? Chaque réponse « transiter » réduit d’autant votre exposition et votre charge de preuve le jour d’un incident.

Pour approfondir, appuyez-vous sur les sources officielles : le dossier de la Commission européenne, les recommandations de l’ENISA et la page de suivi de l’ANSSI. NIS2 n’est pas qu’une contrainte de plus : c’est l’occasion de remettre à plat une circulation de données souvent devenue trop complexe pour être défendue sereinement.

The NIS2 directive is now the reference framework for European cybersecurity. For CIOs and CISOs, it is not just another compliance box to tick: it forces a rethink of how data enters the information system, moves through it and leaves it. Here is what it actually requires, and why the way you route your data flows is becoming a front-line concern.

NIS2, a directive on a new scale

NIS2 is directive (EU) 2022/2555, adopted at the end of 2022 and in force since January 2023. It succeeds the first NIS directive of 2016, which had become too narrow given the scale reached by cyberattacks. The European Commission presents it as the foundation for a common, high level of cybersecurity across the Union.

The timeline is easy to remember: member states had to transpose it into national law before 17 October 2024. In France, ANSSI is leading this transposition and supporting the organisations concerned. The text does not merely add obligations: it significantly broadens the scope covered by NIS1, as ENISA points out.

This change of scale is anything but cosmetic. Where the first directive left member states a great deal of room for interpretation, NIS2 harmonises the criteria, thresholds and penalties. For a company already subject to NIS1, the challenge is to gauge what becomes stricter; for the newly affected entities, it often means starting from a near-blank page.

Who is affected, and on what basis

Where NIS1 targeted a limited number of players, NIS2 covers around eighteen sectors. These include critical infrastructure as much as digital and industrial activities, as the European Commission sets out in detail.

• Energy, transport, banking and financial markets
• Health, drinking water, wastewater
• Digital infrastructure, public administration, space
• Postal services, waste management, agri-food, manufacturing

Above all, NIS2 introduces a defining distinction: essential entities and important entities. The former group together the most critical players, subject to enhanced supervision; the latter fall under a lighter regime but remain fully liable in the event of a breach. ANSSI sets out the size and sector criteria that place an organisation in one category or the other.

This classification has a practical consequence: it determines the intensity of the controls, but not the nature of the obligations, which remain largely common to both. In other words, being classified as « important » rather than « essential » exempts you from almost nothing. It is therefore best to check your status early in order to size the necessary effort correctly.

What NIS2 requires in practice

The core of the directive lies in a series of obligations that every CIO or CISO must be able to demonstrate, not merely declare. ENISA, the Union’s agency for cybersecurity, provides the technical framework and guidelines for them.

• Cyber risk management measures, proportionate and documented
• Supply chain security, including suppliers and subcontractors
• Incident notification on a strict timeline
• The direct accountability of management bodies

Supply chain security deserves particular attention. NIS2 makes you responsible not only for your own systems, but also for links you do not directly control: service providers, software vendors, hosting companies. Yet these links exchange data with you constantly, which shifts the security question towards interfaces and flows.

The notification component is particularly tightly framed. According to the text of the directive, an early warning must be issued within 24 hours of detection, a fuller notification within 72 hours, then a final report within one month. This pace assumes that you know very quickly which data was affected, and by which paths it was travelling.

Meeting these deadlines is a demanding operational exercise. You cannot reconstruct in 24 hours a history you did not collect beforehand. This is where the ability to trace flows continuously makes the difference between a controlled notification and a last-minute reconstruction.

Two points change governance. First, senior managers are held directly liable, which pushes the subject all the way up to the executive committee. Second, the penalties are dissuasive: up to 10 million euros or 2% of annual worldwide turnover for essential entities, as ANSSI notes.

Why this directly affects how data flows

Most of NIS2’s requirements come down to one concrete question: do you know where your data goes, and can you prove it? ENISA’s threat landscape shows that attacks passing through the supply chain and through flows between systems are growing year after year.

Yet every time a piece of data is copied into a warehouse, duplicated in an intermediate system or kept « just in case », you add a zone to protect, monitor and justify. IBM’s Cost of a Data Breach report puts a figure each year on what these zones cost when they are compromised.

Every copy of data you did not create is a breach you will not have to defend.

Reducing the attack surface is therefore not merely a security principle: it is a direct way to make compliance more sustainable over time. The less data you accumulate at rest, the fewer points you have to encrypt, trace and audit. The logic of NIS2 pushes in this direction: master the flows, rather than multiply the copies.

Orchestrating data in transit, a structural response

Processing data « in transit » means moving it, transforming it and distributing it in real time, without freezing it in storage at each step. This approach addresses several NIS2 requirements at once, instead of treating them as separate projects.

The first benefit concerns the attack surface. Without an intermediate copy at rest, there are inherently fewer zones to defend, a point that Gartner’s cybersecurity analyses regularly underline. The second benefit concerns traceability: if every flow is logged, you have a usable history for incident notification as well as for audit.

This link between traceability and notification is often underestimated. An incident can be assessed all the faster when you know which flows were affected, to which recipients and for how long. Logging the movement of data, rather than only its final state, turns the notification obligation into simply reading a history that has already been built.

The third benefit touches on sovereignty and resilience. Orchestration that stays within the organisation’s perimeter, deployable on-premise, limits transfers to third-party systems whose location and availability you do not control. ENISA explicitly links this control to resilience and to the security of the data supply chain.

An illustration of the approach

To make this logic concrete, take the case of an orchestration middleware such as iD4Connect. Its principle is to process flows in real time, without intermediate storage, which by design limits the number of copies created along the data’s journey.

In practice, each flow passes through, is transformed if necessary, then distributed, all while being logged. The whole remains deployable within the organisation’s perimeter, on-premise, in the cloud or at the edge, depending on sovereignty constraints. This is not a silver bullet: it is a way to align the technical architecture with NIS2‘s requirements rather than catching up with them after the fact.

For a CIO, the value lies in thinking upstream: reducing storage points, tracing exchanges and keeping control over location. It is an architectural stance, not a product you bolt on at the end to tick a box.

Where to start

The first step is not technical, it is cartographic: mapping your data flows, their entry points, their copies and their recipients. Without this overall view, none of the obligations of directive (EU) 2022/2555 can be met sustainably.

This mapping is not just a documentation exercise. It serves as the basis for risk analysis, for securing the interfaces with your suppliers and for preparing notifications. Without it, each new obligation is handled piecemeal, which costs more and protects less well over time.

Then comes the question to ask for each flow: does this data really need to be stored here, or can it simply pass through? Every « pass through » answer reduces your exposure and your burden of proof accordingly on the day of an incident.

To go further, rely on the official sources: the European Commission’s dossier, ENISA‘s recommendations and ANSSI‘s tracking page. NIS2 is not just one more constraint: it is an opportunity to overhaul a data flow that has often become too complex to defend with any peace of mind.

La directiva NIS2 es ya el marco de referencia de la ciberseguridad europea. Para los CIO y los CISO, no se limita a una nueva casilla de conformidad que marcar: obliga a revisar la manera en que los datos entran en el sistema de información, circulan por él y salen de él. Esto es lo que realmente impone, y por qué la forma en que hace transitar sus flujos se convierte en un asunto de primer orden.

NIS2, una directiva que cambia de escala

NIS2 es la Directiva (UE) 2022/2555, adoptada a finales de 2022 y en vigor desde enero de 2023. Sucede a la primera directiva NIS de 2016, que se quedó demasiado corta ante la magnitud que alcanzaron los ciberataques. La Comisión Europea la presenta como la base de un nivel común y elevado de ciberseguridad en toda la Unión.

El calendario es fácil de recordar: los Estados miembros debían transponerla a su Derecho nacional antes del 17 de octubre de 2024. En Francia, es la ANSSI quien dirige esa transposición y acompaña a las organizaciones afectadas. El texto no se limita a añadir obligaciones: amplía notablemente el perímetro cubierto por NIS1, como subraya ENISA.

Este cambio de escala no tiene nada de cosmético. Allí donde la primera directiva dejaba mucho margen de interpretación a los Estados, NIS2 armoniza los criterios, los umbrales y las sanciones. Para una empresa ya sujeta a NIS1, el reto es medir qué se vuelve más estricto; para las nuevas entidades afectadas, a menudo hay que partir casi de cero.

Quién está afectado, y en calidad de qué

Allí donde NIS1 apuntaba a un número reducido de actores, NIS2 abarca cerca de dieciocho sectores. En ellos figuran tanto infraestructuras vitales como actividades digitales e industriales, como detalla la Comisión Europea.

• Energía, transporte, banca y mercados financieros
• Sanidad, agua potable, aguas residuales
• Infraestructuras digitales, administración pública, espacio
• Servicios postales, gestión de residuos, agroalimentación, fabricación

NIS2 introduce sobre todo una distinción estructurante: las entidades esenciales y las entidades importantes. Las primeras agrupan a los actores más críticos, sometidos a una supervisión reforzada; las segundas se rigen por un régimen más ligero, pero siguen siendo plenamente responsables en caso de incumplimiento. La ANSSI precisa los criterios de tamaño y de sector que hacen que una organización pase a una u otra categoría.

Esta clasificación tiene una consecuencia práctica: determina la intensidad de los controles, pero no la naturaleza de las obligaciones, que siguen siendo en gran medida comunes. Dicho de otro modo, estar clasificado como «importante» en lugar de «esencial» no exime de casi nada. Conviene, por tanto, comprobar pronto la propia condición para dimensionar correctamente los esfuerzos necesarios.

Lo que NIS2 impone en concreto

El núcleo de la directiva reside en una serie de obligaciones que todo CIO o CISO debe poder demostrar, y no solo declarar. ENISA, la agencia de la Unión para la ciberseguridad, aporta el marco técnico y las directrices.

• Medidas de gestión de los riesgos cibernéticos, proporcionadas y documentadas
• La seguridad de la cadena de suministro, incluidos proveedores y subcontratistas
• La notificación de los incidentes según un calendario estricto
• La responsabilidad directa de los órganos de dirección

La seguridad de la cadena de suministro merece una atención particular. NIS2 le hace responsable no solo de sus propios sistemas, sino también de eslabones que no controla directamente: proveedores de servicios, fabricantes de software y empresas de alojamiento. Y esos eslabones intercambian datos con usted de forma permanente, lo que traslada la cuestión de la seguridad hacia las interfaces y los flujos.

El apartado de notificación está especialmente reglado. Según el texto de la directiva, una alerta temprana debe enviarse en las 24 horas siguientes a la detección, una notificación más completa en un plazo de 72 horas, y después un informe final en el plazo de un mes. Ese ritmo exige saber muy pronto qué datos se han visto afectados, y por qué caminos transitaban.

Cumplir esos plazos es un ejercicio operativo exigente. No se puede reconstruir en 24 horas un historial que no se ha recopilado con antelación. Ahí es donde la capacidad de trazar los flujos de forma continua marca la diferencia entre una notificación bajo control y una reconstrucción a contrarreloj.

Dos aspectos modifican la gobernanza. En primer lugar, la responsabilidad de los directivos queda directamente comprometida, lo que eleva el asunto hasta el comité de dirección. En segundo lugar, las sanciones son disuasorias: hasta 10 millones de euros o el 2 % del volumen de negocios anual mundial para las entidades esenciales, como recuerda la ANSSI.

Por qué esto afecta directamente a la circulación de los datos

La mayoría de las exigencias de NIS2 se reducen a una pregunta concreta: ¿sabe a dónde van sus datos y puede demostrarlo? El panorama de amenazas de ENISA muestra que los ataques que pasan por la cadena de suministro y por los flujos entre sistemas aumentan año tras año.

Ahora bien, cada vez que un dato se copia en un almacén de datos, se duplica en un sistema intermedio o se conserva «por si acaso», usted añade una zona que proteger, vigilar y justificar. El informe Cost of a Data Breach de IBM cuantifica cada año lo que cuestan esas zonas cuando se ven comprometidas.

Cada copia de datos que no ha creado es una brecha que no tendrá que defender.

Reducir la superficie de ataque no es, por tanto, un simple principio de seguridad: es una forma directa de hacer que la conformidad sea más sostenible a largo plazo. Cuantos menos datos acumule en reposo, menos puntos tendrá que cifrar, trazar y auditar. La lógica de NIS2 empuja en esa dirección: controlar los flujos, en lugar de multiplicar las copias.

La orquestación de los datos en tránsito, una respuesta estructural

Tratar el dato «en tránsito» consiste en hacerlo circular, transformarlo y distribuirlo en tiempo real, sin fijarlo en un almacenamiento en cada etapa. Este enfoque responde a la vez a varias exigencias de NIS2, en lugar de abordarlas como proyectos separados.

La primera ventaja tiene que ver con la superficie de ataque. Sin copia intermedia en reposo, hay mecánicamente menos zonas que defender, un punto que los análisis de Gartner sobre ciberseguridad recuerdan con regularidad. La segunda ventaja tiene que ver con la trazabilidad: si cada flujo queda registrado, dispone de un historial aprovechable tanto para la notificación de incidentes como para la auditoría.

Este vínculo entre trazabilidad y notificación suele subestimarse. Un incidente se califica tanto más rápido cuanto que se sabe qué flujos se han visto afectados, hacia qué destinatarios y durante cuánto tiempo. Registrar la circulación de los datos, y no solo su estado final, convierte la obligación de notificación en la lectura de un historial ya constituido.

La tercera ventaja afecta a la soberanía y a la resiliencia. Una orquestación que permanece dentro del perímetro de la organización, desplegable on-premise, limita las transferencias hacia sistemas de terceros cuya ubicación y disponibilidad usted no controla. ENISA vincula precisamente ese control con la resiliencia y con la seguridad de la cadena de suministro de los datos.

Un ejemplo de enfoque

Para hacer concreta esta lógica, tomemos el caso de un middleware de orquestación como iD4Connect. Su principio es tratar los flujos en tiempo real, sin almacenamiento intermedio, lo que limita por diseño el número de copias creadas a lo largo del recorrido del dato.

En concreto, cada flujo transita, se transforma si es necesario y luego se distribuye, todo ello quedando registrado. El conjunto sigue siendo desplegable dentro del perímetro de la organización, en on-premise, en la nube o en edge, según las restricciones de soberanía. No es una solución milagrosa: es una manera de alinear la arquitectura técnica con las exigencias de NIS2 en lugar de correr tras ellas a posteriori.

Para un CIO, el interés está en razonar desde el principio: reducir los puntos de almacenamiento, trazar los intercambios y mantener el control sobre la ubicación. Es una postura de arquitectura, no un producto que se añade al final para marcar una casilla.

Por dónde empezar

El primer paso no es técnico, sino cartográfico: inventariar sus flujos de datos, sus puntos de entrada, sus copias y sus destinatarios. Sin esa visión de conjunto, ninguna de las obligaciones de la Directiva (UE) 2022/2555 puede cumplirse de forma duradera.

Esta cartografía no es solo un ejercicio de documentación. Sirve de base para el análisis de riesgos, para la protección de las interfaces con sus proveedores y para la preparación de las notificaciones. Sin ella, cada nueva obligación se aborda caso por caso, lo que sale más caro y protege peor a largo plazo.

Después viene la pregunta que hay que plantearse para cada flujo: ¿este dato debe almacenarse realmente aquí o puede simplemente transitar? Cada respuesta «transitar» reduce en igual medida su exposición y su carga de la prueba el día de un incidente.

Para profundizar, apóyese en las fuentes oficiales: el expediente de la Comisión Europea, las recomendaciones de ENISA y la página de seguimiento de la ANSSI. NIS2 no es solo una obligación más: es la ocasión de replantear desde cero una circulación de datos que a menudo se ha vuelto demasiado compleja para defenderla con serenidad.

Pendant trente ans, intégrer des données a voulu dire la même chose : les copier d’un endroit à un autre. L’ETL les extrait et les recharge dans un entrepôt, l’ESB les fait transiter par un hub central, le data lake les déverse toutes au même endroit « au cas où ». Trois générations d’outils, un seul réflexe : capturer, dupliquer, stocker. Mais en 2026, la donnée est devenue temps réel, distribuée et réglementée. Et le vieux postulat « stocker pour intégrer » se paie désormais en latence, en coûts cachés et en surface d’attaque.

ETL, ESB, Data Lake : trois réponses, un même postulat

Les trois piliers historiques de l’intégration répondent au même problème, à des époques différentes. L’ETL (Extract, Transform, Load) est né avec les entrepôts de données : il extrait la donnée des systèmes sources, la transforme, puis la recharge dans une base centrale, le plus souvent la nuit, par lots. L’ESB (Enterprise Service Bus) a généralisé le hub d’intégration : un bus central par lequel tout transite, avec ses files de messages et ses copies intermédiaires. Le data lake, enfin, a poussé la logique à l’extrême : déverser l’intégralité des données brutes dans un réservoir unique, en pariant qu’on saura les exploiter plus tard.

Le point commun saute aux yeux : dans les trois cas, pour faire circuler la donnée, on commence par la recopier et la poser quelque part. Ce marché reste massif et en croissance. L’intégration de données pesait 17,58 milliards de dollars en 2025 et devrait atteindre 33,24 milliards en 2030, soit une croissance annuelle de 13,6 % (source : MarketsandMarkets). Mais à l’intérieur de ce marché, le centre de gravité se déplace.

Le segment qui explose, c’est l’intégration cloud et temps réel. Le marché de l’iPaaS (Integration Platform as a Service) a dépassé 9 milliards de dollars de revenus en 2024, contre 7,8 milliards en 2023 et 5,9 milliards en 2022, et Gartner le voit franchir les 17 milliards d’ici 2028 (source : Gartner, via Informatica). À titre de comparaison, l’ensemble du marché du middleware applicatif a progressé de 11,9 % en 2024 pour atteindre 64,1 milliards de dollars (source : Gartner) : l’intégration moderne croît environ deux fois plus vite que le middleware classique. La direction est claire, même quand les vieux outils restent en place.

Le batch ne suit plus : la donnée est devenue temps réel

Le modèle ETL repose sur une hypothèse devenue fausse : que la donnée peut attendre. Or elle n’attend plus. IDC estimait que le volume mondial de données passerait de 33 zettaoctets en 2018 à 175 zettaoctets en 2025, et surtout que près de 30 % de cette donnée devrait être consommée en temps réel (source : IDC, Data Age 2025). Une donnée qui se décide à la seconde s’accommode mal d’un traitement nocturne par lots.

Cette donnée n’est pas seulement plus rapide, elle est aussi ailleurs. Gartner prévoyait dès 2018 que 75 % des données d’entreprise seraient créées et traitées en dehors d’un data center centralisé ou d’un cloud traditionnel d’ici 2025, contre environ 10 % à l’époque (source : Gartner). Ramener mécaniquement toute cette donnée vers un entrepôt central pour la traiter devient un contresens géographique autant qu’économique.

Le marché valide cette bascule. L’analytique en streaming, c’est à dire le traitement de la donnée pendant qu’elle circule, doit passer de 29,53 milliards de dollars en 2024 à 125,85 milliards en 2029, soit une croissance annuelle de 33,6 % (source : MarketsandMarkets). Côté terrain, plus de 80 % des entreprises du Fortune 100 utilisent déjà Apache Kafka pour faire circuler leurs flux en événementiel (source : Apache Kafka). Et la pression continue de monter : Gartner prévoit que l’adoption du streaming de données pour l’IA agentique dépassera 60 % d’ici 2028, contre moins de 15 % en 2025 (source : Gartner).

L’écart entre la valeur perçue et la réalité reste pourtant énorme. Une enquête menée pour Solace montrait que 85 % des organisations reconnaissent la valeur métier de l’architecture orientée événements, mais que seulement 13 % estiment avoir atteint sa pleine maturité (source : Coleman Parkes pour Solace). Le temps réel est compris et désiré. Ce qui manque, c’est une façon de l’atteindre sans rebâtir un entrepôt de plus.

Le data lake, du réservoir au marécage

Le data lake promettait de résoudre le problème en supprimant les silos : un seul endroit pour tout stocker, et on verra plus tard. Gartner avait pourtant prévenu dès 2014 avec sa « data lake fallacy » : sans métadonnées descriptives ni gouvernance, un lac de données se transforme en « data swamp », un marécage où l’information existe mais devient introuvable et inexploitable (source : Gartner).

Dix ans plus tard, le diagnostic se confirme dans les chiffres. La donnée stockée reste très largement dormante.

• 55 % des données d’une organisation sont des « dark data » : elles existent mais ne sont ni trouvées, ni préparées, ni analysées (Splunk, The State of Dark Data)
• 68 % des données dont disposent les entreprises ne sont jamais exploitées, selon une enquête menée auprès de 1 500 dirigeants (Seagate et IDC, Rethink Data)
• 60 à 73 % de l’ensemble des données d’une entreprise restent inutilisées pour l’analytique (Forrester)

Le problème n’est pas le volume, c’est la gouvernance de tout ce qui dort. Gartner prédit d’ailleurs que 80 % des initiatives de gouvernance des données et de l’analytique échoueront d’ici 2027 (source : Gartner). Accumuler n’a jamais été synonyme d’exploiter. Plus le réservoir grossit, plus il coûte cher à maintenir, à sécuriser et à gouverner, pour une fraction de valeur réellement utilisée.

Ce que coûte vraiment le déplacement des données

Copier et stocker n’est pas neutre, ni financièrement, ni en matière de risque. Chaque copie qui quitte un cloud est facturée : le transfert sortant standard d’AWS démarre à 0,09 dollar par gigaoctet au delà des 100 Go gratuits mensuels (source : AWS). Anodin à l’unité, ce coût devient structurel à l’échelle : Gartner estime que la plupart des clients consacrent 10 à 15 % de leur facture cloud aux seuls frais d’egress (source : Gartner, via Fierce Network). Sur une dépense mondiale en cloud public prévue à 723,4 milliards de dollars en 2025 (source : Gartner), l’addition donne le vertige. Le législateur s’en est saisi : le Data Act européen supprimera totalement les frais de changement de fournisseur, frais d’egress compris, à compter du 12 janvier 2027 (source : Commission européenne).

Le coût caché le plus dangereux n’est toutefois pas sur la facture, il est dans le risque. Chaque copie est une cible de plus. Le rapport d’IBM sur le coût des violations de données indique que 35 % des fuites impliquent des « shadow data », ces données dupliquées hors du périmètre de sécurité, et que ces violations coûtent en moyenne 16 % plus cher (source : IBM, Cost of a Data Breach 2024). Sachant que le coût moyen mondial d’une violation a atteint un pic de 4,88 millions de dollars en 2024 (source : IBM), chaque réplique inutile devient une dette de sécurité.

Reste la souveraineté. Les trois géants américains concentrent 70 % du marché cloud européen, quand la part des fournisseurs européens est tombée à environ 15 % (source : Synergy Research Group). Or beaucoup d’outils d’intégration et d’iPaaS sont des services américains, soumis au Cloud Act. Dans leur évaluation juridique commune, l’EDPB et l’EDPS concluent qu’en l’absence d’accord international, un fournisseur soumis au droit de l’Union ne peut légalement transférer des données vers les États Unis sur la base de telles demandes, en contradiction directe avec l’article 48 du RGPD (source : EDPB et EDPS). Faire transiter ses données par un hub d’intégration américain, c’est exposer chaque octet copié. Comme nous l’expliquions à propos de la souveraineté numérique, la nationalité du fournisseur prime sur la localisation des serveurs.

L’orchestration en transit : intégrer sans stocker

Si copier et stocker est la source du problème, la solution consiste à ne plus le faire. C’est le principe de l’orchestration en transit : traiter la donnée pendant qu’elle circule, au moment précis de son passage, sans jamais la poser ni la dupliquer. La donnée n’est plus aspirée vers un réservoir central, elle est transformée à la volée puis libérée vers sa destination.

C’est l’approche d’iD4Connect. Chaque DataCell est une unité de traitement autonome qui nettoie, transforme, enrichit, anonymise ou route la donnée pendant son transit, puis ne garde rien. L’orchestration de ces DataCells, organisée en DataGraph, permet de bâtir des flux complexes entre n’importe quelles applications, sur site, en cloud ou en hybride. Le Connecteur Universel prend en charge l’ingestion via tous les protocoles standards (REST, SQL, MQTT, Kafka, OPC-UA, SFTP…), sans imposer son propre format.

Le bénéfice est triple. La surface d’exposition tombe à zéro, puisqu’aucune donnée n’est stockée au passage. La souveraineté est garantie par construction, l’architecture étant conçue en Europe et exécutée dans le périmètre du client. Et le coût devient prévisible, sans entrepôt à maintenir ni egress à payer pour des copies que personne n’utilise. Là où l’ETL, l’ESB et le data lake ajoutent une couche de stockage entre vos systèmes, l’orchestration en transit la supprime. Pour aller plus loin, nous détaillons ce positionnement face aux outils existants.

L’ETL, l’ESB et le data lake n’ont pas démérité : ils ont résolu les problèmes de leur époque. Mais cette époque supposait une donnée lente, centralisée et peu réglementée. En 2026, la donnée est rapide, partout et sous surveillance juridique. La vraie question n’est plus « où stocker pour intégrer », mais « comment intégrer sans stocker ». Et la meilleure copie reste celle qu’on n’a jamais faite.

Découvrez comment iD4Connect orchestre vos données sans stockage intermédiaire →

For thirty years, integrating data has meant the same thing: copying it from one place to another. ETL extracts it and reloads it into a warehouse, the ESB routes it through a central hub, the data lake dumps it all in one spot « just in case. » Three generations of tools, one single reflex: capture, duplicate, store. But in 2026, data has become real-time, distributed and regulated. And the old premise of « storing in order to integrate » is now paid for in latency, hidden costs and attack surface.

ETL, ESB, Data Lake: three answers, one shared premise

The three historical pillars of integration address the same problem at different points in time. ETL (Extract, Transform, Load) was born with data warehouses: it extracts data from source systems, transforms it, then reloads it into a central database, most often overnight, in batches. The ESB (Enterprise Service Bus) generalized the integration hub: a central bus through which everything transits, with its message queues and intermediate copies. The data lake, finally, pushed the logic to the extreme: dump all raw data into a single reservoir, betting that we will know how to exploit it later.

The common thread is obvious: in all three cases, to move data around, you start by copying it and putting it somewhere. This market remains massive and growing. Data integration was worth 17.58 billion dollars in 2025 and is expected to reach 33.24 billion in 2030, a yearly growth rate of 13.6% (source: MarketsandMarkets). But within this market, the center of gravity is shifting.

The segment that is exploding is cloud and real-time integration. The iPaaS (Integration Platform as a Service) market exceeded 9 billion dollars in revenue in 2024, up from 7.8 billion in 2023 and 5.9 billion in 2022, and Gartner sees it crossing 17 billion by 2028 (source: Gartner, via Informatica). For comparison, the entire application middleware market grew 11.9% in 2024 to reach 64.1 billion dollars (source: Gartner): modern integration is growing roughly twice as fast as classic middleware. The direction is clear, even where the old tools remain in place.

Batch can no longer keep up: data has become real-time

The ETL model rests on an assumption that has become false: that data can wait. Yet it no longer waits. IDC estimated that the global volume of data would grow from 33 zettabytes in 2018 to 175 zettabytes in 2025, and above all that close to 30% of that data would need to be consumed in real time (source: IDC, Data Age 2025). Data that is decided by the second sits poorly with overnight batch processing.

This data is not only faster, it is also elsewhere. As early as 2018, Gartner predicted that 75% of enterprise data would be created and processed outside a centralized data center or a traditional cloud by 2025, compared with around 10% at the time (source: Gartner). Mechanically pulling all of this data back to a central warehouse to process it becomes a geographic as much as an economic absurdity.

The market confirms this shift. Streaming analytics, meaning the processing of data while it is in motion, is expected to grow from 29.53 billion dollars in 2024 to 125.85 billion in 2029, a yearly growth rate of 33.6% (source: MarketsandMarkets). On the ground, more than 80% of Fortune 100 companies already use Apache Kafka to move their event streams (source: Apache Kafka). And the pressure keeps rising: Gartner predicts that the adoption of data streaming for agentic AI will exceed 60% by 2028, compared with less than 15% in 2025 (source: Gartner).

The gap between perceived value and reality nonetheless remains enormous. A survey conducted for Solace showed that 85% of organizations recognize the business value of event-driven architecture, but that only 13% believe they have reached its full maturity (source: Coleman Parkes for Solace). Real time is understood and wanted. What is missing is a way to reach it without building yet another warehouse.

The data lake, from reservoir to swamp

The data lake promised to solve the problem by removing silos: a single place to store everything, and we will sort it out later. Yet Gartner warned as early as 2014 with its « data lake fallacy »: without descriptive metadata or governance, a data lake turns into a « data swamp, » a marsh where information exists but becomes impossible to find and impossible to use (source: Gartner).

Ten years later, the diagnosis is borne out in the numbers. Stored data remains very largely dormant.

• 55% of an organization’s data is « dark data »: it exists but is neither found, nor prepared, nor analyzed (Splunk, The State of Dark Data)
• 68% of the data available to companies is never used, according to a survey of 1,500 executives (Seagate and IDC, Rethink Data)
• 60 to 73% of all of a company’s data goes unused for analytics (Forrester)

The problem is not volume, it is the governance of everything that lies dormant. Gartner in fact predicts that 80% of data and analytics governance initiatives will fail by 2027 (source: Gartner). Accumulating has never been the same as exploiting. The larger the reservoir grows, the more it costs to maintain, secure and govern, for a fraction of the value actually used.

What moving data really costs

Copying and storing is not neutral, neither financially nor in terms of risk. Every copy that leaves a cloud is billed: AWS standard outbound transfer starts at 0.09 dollar per gigabyte beyond the free 100 GB per month (source: AWS). Trivial per unit, this cost becomes structural at scale: Gartner estimates that most customers devote 10 to 15% of their cloud bill to egress fees alone (source: Gartner, via Fierce Network). On worldwide public cloud spending forecast at 723.4 billion dollars in 2025 (source: Gartner), the total is staggering. Lawmakers have taken up the issue: the European Data Act will fully remove switching fees, including egress fees, as of January 12, 2027 (source: European Commission).

The most dangerous hidden cost, however, is not on the bill, it is in the risk. Every copy is one more target. IBM’s report on the cost of data breaches indicates that 35% of leaks involve « shadow data, » this data duplicated outside the security perimeter, and that these breaches cost on average 16% more (source: IBM, Cost of a Data Breach 2024). Knowing that the global average cost of a breach reached a peak of 4.88 million dollars in 2024 (source: IBM), every needless replica becomes a security debt.

Then there is sovereignty. The three American giants concentrate 70% of the European cloud market, while the share of European providers has fallen to around 15% (source: Synergy Research Group). Yet many integration and iPaaS tools are American services, subject to the Cloud Act. In their joint legal assessment, the EDPB and the EDPS conclude that, absent an international agreement, a provider subject to Union law cannot legally transfer data to the United States on the basis of such requests, in direct contradiction with Article 48 of the GDPR (source: EDPB and EDPS). Routing your data through an American integration hub means exposing every copied byte. As we explained regarding digital sovereignty, the provider’s nationality takes precedence over the location of the servers.

In-transit orchestration: integrate without storing

If copying and storing is the source of the problem, the solution is to stop doing it. That is the principle of in-transit orchestration: processing data while it is in motion, at the precise moment it passes through, without ever putting it down or duplicating it. Data is no longer pulled toward a central reservoir, it is transformed on the fly then released to its destination.

This is the approach of iD4Connect. Each DataCell is an autonomous processing unit that cleans, transforms, enriches, anonymizes or routes data during its transit, then keeps nothing. The orchestration of these DataCells, organized into a DataGraph, makes it possible to build complex flows between any applications, on-premise, in the cloud or in hybrid setups. The Universal Connector handles ingestion via all standard protocols (REST, SQL, MQTT, Kafka, OPC-UA, SFTP…), without imposing its own format.

The benefit is threefold. The exposure surface drops to zero, since no data is stored along the way. Sovereignty is guaranteed by design, the architecture being conceived in Europe and executed within the customer’s perimeter. And the cost becomes predictable, with no warehouse to maintain and no egress to pay for copies that no one uses. Where ETL, the ESB and the data lake add a storage layer between your systems, in-transit orchestration removes it. To go further, we detail this how we compare to existing tools.

ETL, the ESB and the data lake did not fail: they solved the problems of their era. But that era assumed slow, centralized and lightly regulated data. In 2026, data is fast, everywhere and under legal scrutiny. The real question is no longer « where to store in order to integrate, » but « how to integrate without storing. » And the best copy remains the one that was never made.

Discover how iD4Connect orchestrates your data without intermediate storage →

Durante treinta años, integrar datos ha significado lo mismo: copiarlos de un sitio a otro. El ETL los extrae y los recarga en un almacén, el ESB los hace transitar por un hub central, el data lake los vuelca todos en el mismo lugar « por si acaso ». Tres generaciones de herramientas, un solo reflejo: capturar, duplicar, almacenar. Pero en 2026 el dato se ha vuelto tiempo real, distribuido y regulado. Y el viejo postulado de « almacenar para integrar » se paga ahora en latencia, en costes ocultos y en superficie de ataque.

ETL, ESB, Data Lake: tres respuestas, un mismo postulado

Los tres pilares históricos de la integración responden al mismo problema, en épocas distintas. El ETL (Extract, Transform, Load) nació con los almacenes de datos: extrae el dato de los sistemas de origen, lo transforma y luego lo recarga en una base central, casi siempre de noche, por lotes. El ESB (Enterprise Service Bus) generalizó el hub de integración: un bus central por el que todo transita, con sus colas de mensajes y sus copias intermedias. El data lake, por último, llevó la lógica al extremo: volcar la totalidad de los datos en bruto en un único depósito, apostando a que ya se sabrá explotarlos más adelante.

El punto en común salta a la vista: en los tres casos, para hacer circular el dato, se empieza por copiarlo y dejarlo en algún sitio. Este mercado sigue siendo enorme y creciente. La integración de datos representaba 17.580 millones de dólares en 2025 y debería alcanzar los 33.240 millones en 2030, es decir, un crecimiento anual del 13,6 % (fuente: MarketsandMarkets). Pero dentro de este mercado, el centro de gravedad se desplaza.

El segmento que se dispara es la integración en cloud y en tiempo real. El mercado del iPaaS (Integration Platform as a Service) superó los 9.000 millones de dólares de ingresos en 2024, frente a los 7.800 millones de 2023 y los 5.900 millones de 2022, y Gartner prevé que rebase los 17.000 millones de aquí a 2028 (fuente: Gartner, vía Informatica). A modo de comparación, el conjunto del mercado del middleware aplicativo creció un 11,9 % en 2024 hasta alcanzar los 64.100 millones de dólares (fuente: Gartner): la integración moderna crece aproximadamente el doble de rápido que el middleware clásico. La dirección es clara, incluso cuando las viejas herramientas siguen en su sitio.

El batch ya no aguanta: el dato se ha vuelto tiempo real

El modelo ETL se apoya en una hipótesis que ha dejado de ser cierta: que el dato puede esperar. Pero ya no espera. IDC estimaba que el volumen mundial de datos pasaría de 33 zettabytes en 2018 a 175 zettabytes en 2025, y sobre todo que cerca del 30 % de ese dato debería consumirse en tiempo real (fuente: IDC, Data Age 2025). Un dato que se decide al segundo encaja mal con un procesamiento nocturno por lotes.

Este dato no solo es más rápido, también está en otra parte. Gartner ya preveía en 2018 que el 75 % de los datos de empresa se crearían y procesarían fuera de un centro de datos centralizado o de un cloud tradicional de aquí a 2025, frente a alrededor del 10 % de entonces (fuente: Gartner). Arrastrar mecánicamente todo ese dato hacia un almacén central para procesarlo se convierte en un sinsentido geográfico tanto como económico.

El mercado valida este vuelco. La analítica en streaming, es decir, el procesamiento del dato mientras circula, debe pasar de 29.530 millones de dólares en 2024 a 125.850 millones en 2029, es decir, un crecimiento anual del 33,6 % (fuente: MarketsandMarkets). Sobre el terreno, más del 80 % de las empresas del Fortune 100 ya utilizan Apache Kafka para hacer circular sus flujos en modo orientado a eventos (fuente: Apache Kafka). Y la presión sigue subiendo: Gartner prevé que la adopción del streaming de datos para la IA agéntica superará el 60 % de aquí a 2028, frente a menos del 15 % en 2025 (fuente: Gartner).

La brecha entre el valor percibido y la realidad sigue siendo, sin embargo, enorme. Una encuesta realizada para Solace mostraba que el 85 % de las organizaciones reconocen el valor de negocio de la arquitectura orientada a eventos, pero que solo el 13 % considera haber alcanzado su plena madurez (fuente: Coleman Parkes para Solace). El tiempo real se entiende y se desea. Lo que falta es una forma de alcanzarlo sin reconstruir un almacén más.

El data lake, del depósito al pantano

El data lake prometía resolver el problema eliminando los silos: un solo lugar para almacenarlo todo, y ya se verá más adelante. Gartner ya había advertido en 2014 con su « data lake fallacy »: sin metadatos descriptivos ni gobernanza, un lago de datos se transforma en « data swamp », un pantano donde la información existe pero se vuelve imposible de encontrar e inexplotable (fuente: Gartner).

Diez años después, el diagnóstico se confirma en las cifras. El dato almacenado sigue estando, en gran medida, inactivo.

• El 55 % de los datos de una organización son « dark data »: existen, pero no se encuentran, ni se preparan, ni se analizan (Splunk, The State of Dark Data)
• El 68 % de los datos de los que disponen las empresas no se explotan nunca, según una encuesta realizada a 1.500 directivos (Seagate e IDC, Rethink Data)
• Entre el 60 y el 73 % del conjunto de los datos de una empresa permanecen sin utilizar para la analítica (Forrester)

El problema no es el volumen, es la gobernanza de todo lo que duerme. Gartner predice, de hecho, que el 80 % de las iniciativas de gobernanza de los datos y de la analítica fracasarán de aquí a 2027 (fuente: Gartner). Acumular nunca ha sido sinónimo de explotar. Cuanto más crece el depósito, más cuesta mantenerlo, asegurarlo y gobernarlo, para una fracción de valor realmente utilizada.

Lo que cuesta de verdad el desplazamiento de los datos

Copiar y almacenar no es neutro, ni en lo financiero, ni en materia de riesgo. Cada copia que abandona un cloud se factura: la transferencia de salida estándar de AWS arranca en 0,09 dólares por gigabyte por encima de los 100 GB gratuitos mensuales (fuente: AWS). Anodino por unidad, este coste se vuelve estructural a escala: Gartner estima que la mayoría de los clientes destinan entre el 10 y el 15 % de su factura cloud solo a los gastos de egress (fuente: Gartner, vía Fierce Network). Sobre un gasto mundial en cloud público previsto en 723.400 millones de dólares en 2025 (fuente: Gartner), la cuenta da vértigo. El legislador ha tomado cartas en el asunto: el Data Act europeo suprimirá por completo los gastos de cambio de proveedor, gastos de egress incluidos, a partir del 12 de enero de 2027 (fuente: Comisión Europea).

El coste oculto más peligroso no está, sin embargo, en la factura, está en el riesgo. Cada copia es un objetivo más. El informe de IBM sobre el coste de las brechas de datos indica que el 35 % de las fugas implican « shadow data », esos datos duplicados fuera del perímetro de seguridad, y que esas brechas cuestan de media un 16 % más caras (fuente: IBM, Cost of a Data Breach 2024). Sabiendo que el coste medio mundial de una brecha alcanzó un máximo de 4,88 millones de dólares en 2024 (fuente: IBM), cada réplica inútil se convierte en una deuda de seguridad.

Queda la soberanía. Los tres gigantes estadounidenses concentran el 70 % del mercado cloud europeo, mientras que la cuota de los proveedores europeos ha caído a alrededor del 15 % (fuente: Synergy Research Group). Pero muchas herramientas de integración e iPaaS son servicios estadounidenses, sujetos al Cloud Act. En su evaluación jurídica conjunta, el EDPB y el EDPS concluyen que, a falta de un acuerdo internacional, un proveedor sujeto al derecho de la Unión no puede transferir legalmente datos hacia Estados Unidos sobre la base de tales solicitudes, en contradicción directa con el artículo 48 del RGPD (fuente: EDPB y EDPS). Hacer transitar los datos por un hub de integración estadounidense es exponer cada byte copiado. Como ya explicábamos a propósito de la soberanía digital, la nacionalidad del proveedor prima sobre la localización de los servidores.

La orquestación en tránsito: integrar sin almacenar

Si copiar y almacenar es el origen del problema, la solución consiste en dejar de hacerlo. Es el principio de la orquestación en tránsito: procesar el dato mientras circula, en el momento preciso de su paso, sin posarlo ni duplicarlo jamás. El dato ya no se aspira hacia un depósito central, se transforma al vuelo y luego se libera hacia su destino.

Es el enfoque de iD4Connect. Cada DataCell es una unidad de procesamiento autónoma que limpia, transforma, enriquece, anonimiza o enruta el dato durante su tránsito, y luego no guarda nada. La orquestación de estos DataCells, organizada en DataGraph, permite construir flujos complejos entre cualquier aplicación, on-premise, en cloud o en híbrido. El Conector Universal se encarga de la ingesta a través de todos los protocolos estándar (REST, SQL, MQTT, Kafka, OPC-UA, SFTP…), sin imponer su propio formato.

El beneficio es triple. La superficie de exposición cae a cero, ya que ningún dato se almacena de paso. La soberanía está garantizada por diseño, al estar la arquitectura concebida en Europa y ejecutada dentro del perímetro del cliente. Y el coste se vuelve previsible, sin almacén que mantener ni egress que pagar por copias que nadie utiliza. Allí donde el ETL, el ESB y el data lake añaden una capa de almacenamiento entre sus sistemas, la orquestación en tránsito la suprime. Para profundizar, detallamos nuestro posicionamiento frente a las herramientas existentes.

El ETL, el ESB y el data lake no han fracasado: resolvieron los problemas de su época. Pero aquella época suponía un dato lento, centralizado y poco regulado. En 2026 el dato es rápido, está en todas partes y bajo vigilancia jurídica. La verdadera pregunta ya no es « dónde almacenar para integrar », sino « cómo integrar sin almacenar ». Y la mejor copia sigue siendo la que nunca se hizo.

Descubra cómo iD4Connect orquesta sus datos sin almacenamiento intermedio →

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 →

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.