Catégorie : Souveraineté

Après sept ans de procédure, la Plateforme des Données de Santé (Health Data Hub) a choisi Scaleway pour héberger les données de santé françaises. Cette décision institutionnelle, combinée à la recommandation de la DGSI d’exclure certains SaaS étrangers et au plan européen de 180 millions d’euros pour le cloud souverain, dessine un alignement sans précédent. Pour les établissements de santé, les organismes publics et les industriels soumis à NIS2, une question se pose : l’hébergement souverain suffit-il, ou faut-il repenser la chaîne entière de traitement des données ?

Sept ans pour une décision

La Plateforme des Données de Santé a été créée en 2019 pour centraliser et valoriser les données de santé des Français à des fins de recherche. Dès son lancement, son hébergement a été confié à Microsoft Azure, sans appel d’offres et en pleine montée en puissance du CLOUD Act américain. Le choix a immédiatement suscité des recours de la part de la CNIL, du Conseil d’État, d’associations de patients et du conseil national de l’ordre des médecins, tous réunis autour d’une même question : confier des données médicales hautement sensibles à une entreprise soumise au droit extraterritorial américain est-il compatible avec le RGPD ?

La réponse institutionnelle, longue à venir, est désormais claire. En avril 2026, Scaleway devient l’hébergeur officiel de la Plateforme. Le groupe français, certifié SecNumCloud, soumis au seul droit français, succède à Microsoft Azure et valide concrètement un modèle que les textes appelaient de leurs vœux depuis des années : un cloud de confiance, qualifié par l’ANSSI, imperméable aux injonctions des juridictions étrangères.

Ce basculement n’est pas un événement isolé. Il s’inscrit dans une séquence institutionnelle qui s’accélère.

Un alignement institutionnel sans précédent

Trois signaux, quasi simultanés, convergent au printemps 2026.

La DGSI recommande officiellement aux entreprises françaises de bannir certaines solutions SaaS étrangères pour des raisons de sécurité économique. La recommandation, rare de la part de ce service, cible explicitement les acteurs américains et asiatiques dont l’accès aux données est susceptible d’être contraint par une autorité étrangère.

La Commission européenne alloue 180 millions d’euros au cloud souverain, marquant un passage concret du discours aux actes. Ce financement, modeste à l’échelle des investissements hyperscalers, a une valeur de signal : il confirme l’existence d’une stratégie industrielle européenne assumée, qui ne se limite plus à la régulation.

La CNIL a signé le 10 mars 2026 un partenariat avec la Haute Autorité de Santé sur les données sensibles du secteur sanitaire et médico-social. Dans le même temps, la consultation publique du Comité européen de la protection des données (CEPD) sur les Analyses d’Impact relatives à la Protection des Données (AIPD) est ouverte jusqu’au 9 juin 2026. Les établissements de santé sont explicitement identifiés comme adopteurs prioritaires des nouvelles exigences.

Pour la première fois, régulateur, renseignement économique, Commission et opérateur public d’infrastructure santé envoient le même message, dans la même fenêtre de temps : la souveraineté des données n’est plus une option, c’est une obligation opérationnelle.

Les chiffres qui cadrent le contexte :

• 763 incidents de cybersécurité enregistrés dans le secteur santé français en 2025.

• 63 % des organisations de santé et sciences de la vie expérimentent ou déploient l’IA agentique.

• 180 millions d’euros alloués par la Commission européenne au cloud souverain.

• 9 juin 2026 : date limite de la consultation publique du CEPD sur les AIPD.

• 7 ans : durée écoulée entre l’attribution initiale de la Plateforme des Données de Santé à Azure et sa migration vers Scaleway.

L’hébergement souverain est nécessaire, pas suffisant

La migration de la Plateforme des Données de Santé vers Scaleway résout une question essentielle : celle de la juridiction qui s’applique aux données au repos. Un serveur exploité en France par un opérateur français sous droit français ne peut être contraint de livrer ses données à une autorité étrangère sans passer par les canaux de coopération judiciaire reconnus.

Mais une donnée de santé ne passe pas sa vie au repos. Elle est ingérée, transformée, rapprochée d’autres sources, anonymisée, analysée, projetée dans des indicateurs, parfois exposée à des modèles d’intelligence artificielle. À chacune de ces étapes, elle est lue, copiée, recomposée. Et à chaque étape, la question de la souveraineté se repose. Si le traitement s’appuie sur une API, un moteur analytique ou un modèle d’IA opérés par une entité soumise au CLOUD Act, la protection apportée par l’hébergement souverain s’évapore au moment du traitement.

C’est ici que se joue la vraie bascule de 2026. La souveraineté de l’hébergement est une condition nécessaire. Elle n’est pas une condition suffisante. Les établissements qui considèrent la question réglée avec le choix de Scaleway ou d’OVHcloud découvrent, à l’usage, qu’une partie significative de leur chaîne de valeur data reste dépendante de fournisseurs étrangers à travers les couches d’orchestration, de transformation et d’analytique.

La souveraineté ne se mesure pas à l’endroit où les données dorment. Elle se mesure à la chaîne complète par laquelle elles deviennent exploitables.

Ce que la pression réglementaire impose concrètement

Pour les directions des systèmes d’information hospitaliers, les groupements hospitaliers de territoire, les laboratoires de recherche médicale et les industriels de la santé, la convergence de NIS2, DORA, du RGPD et de l’AI Act se traduit par trois obligations opérationnelles.

Traçabilité native. Chaque transformation d’une donnée doit pouvoir être reconstituée, horodatée, attribuée. Les pipelines ETL traditionnels, qui empilent les couches de traitement sans traçabilité unifiée, deviennent des passifs réglementaires. L’épisode CNIL des 739 signalements lors des municipales 2026, dont 63 % liés à de la prospection non conforme, a démontré à quelle vitesse l’absence de traçabilité se retourne contre les responsables de traitement.

Conformité by design. Une conformité ajoutée après déploiement dépend de la bonne volonté du fournisseur et de la stabilité de sa feuille de route. Une conformité by design est une propriété de l’architecture elle-même : anonymisation à la source, absence de stockage intermédiaire, règles RGPD intégrées au moteur de traitement. La nuance est invisible tant qu’aucun audit n’a lieu. Elle devient décisive le jour de l’inspection.

Résilience documentée. NIS2 et DORA exigent une démonstration de résilience, pas une déclaration. Cela suppose de pouvoir reconstituer rapidement les flux, les dépendances, les points de défaillance. McKinsey le résume dans un rapport récent : quatre étapes de consolidation des capacités data doivent précéder tout déploiement agentique à grande échelle. L’orchestration n’est plus un chantier technique secondaire. C’est un prérequis de conformité.

Trois questions que chaque DSI santé devrait se poser

1. Où mes données sont-elles stockées, mais surtout où sont-elles traitées ? Le choix de l’hébergeur est visible. Celui de la couche d’orchestration l’est beaucoup moins. Les données qui transitent par un moteur analytique étranger ne bénéficient pas de la souveraineté de leur hébergeur.

2. Mes partenaires technologiques sont-ils à l’abri des injonctions extraterritoriales ? Une filiale européenne d’un groupe américain reste soumise, en dernier ressort, au droit de sa maison mère. La souveraineté effective passe par une chaîne de dépendances intégralement européenne, vérifiable de l’infrastructure à la couche applicative.

3. Ma conformité est-elle native dans l’architecture ou ajoutée en couche ? La consultation AIPD du CEPD se termine le 9 juin 2026. Les établissements qui anticipent dès maintenant une architecture de traitement compatible AIPD prennent de l’avance sur ceux qui attendront la publication des lignes directrices finales pour réagir.

La migration Azure vers Scaleway de la Plateforme des Données de Santé n’est pas une fin. C’est un début. L’hébergement souverain résout la question de la juridiction. Reste à traiter celle du traitement. Les établissements qui s’appuient sur une couche d’orchestration européenne, sans stockage intermédiaire et avec traçabilité native, ne prennent pas simplement une précaution juridique : ils préparent leur conformité 2027, celle qui ne se rattrape pas en urgence.

Découvrez comment iD4Connect adresse ces enjeux pour le secteur santé →

After seven years of legal and political back-and-forth, France’s Health Data Hub has chosen Scaleway to host the country’s health data. This institutional decision, combined with the DGSI’s recommendation to exclude certain foreign SaaS providers and the European €180 million sovereign cloud plan, draws an unprecedented alignment. For healthcare institutions, public bodies and industries subject to NIS2, one question remains: is sovereign hosting enough, or is it time to rethink the entire data processing chain?

Seven years for a decision

The Health Data Hub was created in 2019 to centralise and make better use of French health data for research purposes. From its launch, hosting was awarded to Microsoft Azure without a public tender, just as the U.S. CLOUD Act was gaining momentum. The choice immediately drew legal challenges from the CNIL, the Council of State, patient associations and the National Council of the Order of Physicians, all united around a single question: is entrusting highly sensitive medical data to a company subject to U.S. extraterritorial law compatible with the GDPR?

The institutional answer, slow in coming, is now clear. In April 2026, Scaleway became the official host of the platform. The French group, certified SecNumCloud and subject to French law alone, succeeds Microsoft Azure and concretely validates a model the texts have been calling for over the years: a trusted cloud, qualified by the ANSSI, impervious to foreign jurisdictional injunctions.

This shift is not an isolated event. It fits into an institutional sequence that is accelerating.

An unprecedented institutional alignment

Three signals, near-simultaneous, converge in spring 2026.

The DGSI (France’s domestic intelligence service) officially recommends that French companies ban certain foreign SaaS solutions for economic security reasons. The recommendation, rare from this service, explicitly targets American and Asian providers whose access to data may be compelled by a foreign authority.

The European Commission allocates €180 million to sovereign cloud, marking a concrete shift from rhetoric to action. This funding, modest at the scale of hyperscaler investments, has signal value: it confirms the existence of a deliberate European industrial strategy, no longer limited to regulation.

The CNIL signed a partnership with the French National Authority for Health (HAS) on 10 March 2026, covering sensitive data in the healthcare and medico-social sector. At the same time, the public consultation of the European Data Protection Board (EDPB) on Data Protection Impact Assessments (DPIAs) is open until 9 June 2026. Healthcare institutions are explicitly identified as priority adopters of the new requirements.

For the first time, the regulator, economic intelligence, the Commission and a public health infrastructure operator are sending the same message in the same time window: data sovereignty is no longer an option, it is an operational obligation.

The figures that frame the context

• 763 cybersecurity incidents recorded in the French health sector in 2025.

• 63% of healthcare and life sciences organisations are piloting or deploying agentic AI.

• €180 million allocated by the European Commission to sovereign cloud.

• 9 June 2026: deadline for the EDPB public consultation on DPIAs.

• 7 years: time elapsed between the initial Health Data Hub award to Azure and its migration to Scaleway.

Sovereign hosting is necessary, not sufficient

The migration of the Health Data Hub to Scaleway resolves an essential question: that of the jurisdiction applicable to data at rest. A server operated in France by a French operator under French law cannot be compelled to deliver its data to a foreign authority without going through recognised judicial cooperation channels.

But health data does not spend its life at rest. It is ingested, transformed, joined with other sources, anonymised, analysed, projected into indicators, sometimes exposed to artificial intelligence models. At each of these stages, it is read, copied, recombined. And at each stage, the question of sovereignty arises again. If processing relies on an API, an analytics engine or an AI model operated by an entity subject to the CLOUD Act, the protection provided by sovereign hosting evaporates at the moment of processing.

This is where the real shift of 2026 plays out. Sovereignty of hosting is a necessary condition. It is not a sufficient one. Institutions that consider the matter settled with the choice of Scaleway or OVHcloud discover, in practice, that a significant portion of their data value chain remains dependent on foreign vendors through orchestration, transformation and analytics layers.

Sovereignty is not measured by where data sleeps. It is measured by the entire chain through which data becomes usable.

What regulatory pressure concretely imposes

For hospital information system departments, regional hospital groupings, medical research laboratories and healthcare industries, the convergence of NIS2, DORA, the GDPR and the AI Act translates into three operational obligations.

Native traceability. Every transformation of a piece of data must be reconstructible, timestamped, attributable. Traditional ETL pipelines, which stack processing layers without unified traceability, are becoming regulatory liabilities. The CNIL episode of 739 reports during the 2026 municipal elections, 63% of which were linked to non-compliant prospecting, demonstrated how quickly an absence of traceability turns against data controllers.

Compliance by design. Compliance added after deployment depends on the goodwill of the vendor and the stability of their roadmap. Compliance by design is a property of the architecture itself: anonymisation at source, absence of intermediate storage, GDPR rules embedded in the processing engine. The nuance is invisible until an audit takes place. It becomes decisive on the day of inspection.

Documented resilience. NIS2 and DORA require a demonstration of resilience, not a declaration. This means being able to quickly reconstitute flows, dependencies, points of failure. McKinsey summarises it in a recent report: four steps of data capability consolidation must precede any large-scale agentic deployment. Orchestration is no longer a secondary technical project. It is a compliance prerequisite.

Three questions every healthcare CIO should ask

1. Where is my data stored, but more importantly where is it processed? The choice of host is visible. The choice of orchestration layer is much less so. Data that transits through a foreign analytics engine does not benefit from the sovereignty of its host.

2. Are my technology partners shielded from extraterritorial injunctions? A European subsidiary of an American group ultimately remains subject to the law of its parent company. Effective sovereignty requires a fully European chain of dependencies, verifiable from infrastructure to application layer.

3. Is my compliance native to the architecture or added on top? The EDPB’s DPIA consultation closes on 9 June 2026. Institutions that are now anticipating a processing architecture compatible with DPIAs are taking the lead over those who will wait for the publication of the final guidelines to react.

The Health Data Hub’s migration from Azure to Scaleway is not an end. It is a beginning. Sovereign hosting resolves the jurisdictional question. The processing question remains. Institutions that rely on a European orchestration layer, with no intermediate storage and native traceability, are not simply taking a legal precaution: they are preparing for 2027 compliance, the kind that cannot be caught up in a hurry.

Discover how iD4Connect addresses these challenges in healthcare →

Tras siete años de procedimientos jurídicos y políticos, la Plataforma de Datos de Salud francesa (Health Data Hub) ha elegido Scaleway para alojar los datos de salud del país. Esta decisión institucional, combinada con la recomendación de la DGSI de excluir ciertas soluciones SaaS extranjeras y el plan europeo de 180 millones de euros para el cloud soberano, dibuja una alineación sin precedentes. Para los establecimientos de salud, los organismos públicos y los industriales sujetos a NIS2, queda una pregunta: ¿basta el alojamiento soberano, o hay que repensar toda la cadena de tratamiento de los datos?

Siete años para una decisión

La Plataforma de Datos de Salud fue creada en 2019 para centralizar y valorizar los datos de salud de los franceses con fines de investigación. Desde su lanzamiento, su alojamiento se confió a Microsoft Azure, sin licitación pública y en plena expansión de la CLOUD Act estadounidense. La elección suscitó de inmediato recursos por parte de la CNIL, del Consejo de Estado, de asociaciones de pacientes y del Consejo Nacional del Colegio de Médicos, todos reunidos en torno a una misma pregunta: ¿es compatible con el RGPD confiar datos médicos altamente sensibles a una empresa sujeta al derecho extraterritorial estadounidense?

La respuesta institucional, lenta en llegar, es ahora clara. En abril de 2026, Scaleway se convierte en el alojador oficial de la Plataforma. El grupo francés, certificado SecNumCloud, sometido únicamente al derecho francés, sucede a Microsoft Azure y valida concretamente un modelo que los textos invocaban desde hacía años: una nube de confianza, calificada por la ANSSI, impermeable a las requisitorias de jurisdicciones extranjeras.

Este giro no es un acontecimiento aislado. Se inscribe en una secuencia institucional que se acelera.

Una alineación institucional sin precedentes

Tres señales, casi simultáneas, convergen en la primavera de 2026.

La DGSI (servicio francés de inteligencia interior) recomienda oficialmente a las empresas francesas prohibir ciertas soluciones SaaS extranjeras por razones de seguridad económica. La recomendación, poco habitual por parte de este servicio, apunta explícitamente a actores estadounidenses y asiáticos cuyo acceso a los datos puede ser obligado por una autoridad extranjera.

La Comisión Europea asigna 180 millones de euros al cloud soberano, marcando un paso concreto del discurso a los hechos. Esta financiación, modesta a la escala de las inversiones de los hiperescaladores, tiene un valor de señal: confirma la existencia de una estrategia industrial europea asumida, que ya no se limita a la regulación.

La CNIL firmó el 10 de marzo de 2026 una colaboración con la Alta Autoridad de Salud (HAS) sobre los datos sensibles del sector sanitario y médico-social. Al mismo tiempo, la consulta pública del Comité Europeo de Protección de Datos (EDPB) sobre las Evaluaciones de Impacto relativas a la Protección de Datos (DPIA) está abierta hasta el 9 de junio de 2026. Los establecimientos de salud están explícitamente identificados como adoptantes prioritarios de las nuevas exigencias.

Por primera vez, regulador, inteligencia económica, Comisión y operador público de infraestructura sanitaria envían el mismo mensaje, en la misma ventana temporal: la soberanía de los datos ya no es una opción, es una obligación operativa.

Las cifras que enmarcan el contexto

• 763 incidentes de ciberseguridad registrados en el sector salud francés en 2025.

• 63 % de las organizaciones de salud y ciencias de la vida experimentan o despliegan IA agéntica.

• 180 millones de euros asignados por la Comisión Europea al cloud soberano.

• 9 de junio de 2026: fecha límite de la consulta pública del EDPB sobre las DPIA.

• 7 años: tiempo transcurrido entre la atribución inicial de la Plataforma de Datos de Salud a Azure y su migración a Scaleway.

El alojamiento soberano es necesario, no suficiente

La migración de la Plataforma de Datos de Salud a Scaleway resuelve una cuestión esencial: la de la jurisdicción que se aplica a los datos en reposo. Un servidor explotado en Francia por un operador francés bajo derecho francés no puede ser obligado a entregar sus datos a una autoridad extranjera sin pasar por los canales de cooperación judicial reconocidos.

Pero un dato de salud no pasa su vida en reposo. Es ingerido, transformado, cruzado con otras fuentes, anonimizado, analizado, proyectado en indicadores, a veces expuesto a modelos de inteligencia artificial. En cada una de estas etapas, es leído, copiado, recompuesto. Y en cada etapa, la cuestión de la soberanía vuelve a plantearse. Si el tratamiento se apoya en una API, un motor analítico o un modelo de IA operados por una entidad sujeta a la CLOUD Act, la protección aportada por el alojamiento soberano se evapora en el momento del tratamiento.

Es aquí donde se juega el verdadero giro de 2026. La soberanía del alojamiento es una condición necesaria. No es una condición suficiente. Los establecimientos que consideran la cuestión zanjada con la elección de Scaleway o de OVHcloud descubren, en la práctica, que una parte significativa de su cadena de valor data sigue dependiendo de proveedores extranjeros a través de las capas de orquestación, transformación y analítica.

La soberanía no se mide por dónde duermen los datos. Se mide por la cadena completa por la que se vuelven explotables.

Lo que la presión regulatoria impone concretamente

Para las direcciones de sistemas de información hospitalarios, las agrupaciones hospitalarias de territorio, los laboratorios de investigación médica y los industriales de la salud, la convergencia de NIS2, DORA, del RGPD y del AI Act se traduce en tres obligaciones operativas.

Trazabilidad nativa. Cada transformación de un dato debe poder ser reconstituida, fechada, atribuida. Los pipelines ETL tradicionales, que apilan capas de tratamiento sin trazabilidad unificada, se convierten en pasivos regulatorios. El episodio CNIL de los 739 reportes durante las elecciones municipales de 2026, de los cuales el 63 % vinculados a prospección no conforme, demostró con qué rapidez la ausencia de trazabilidad se vuelve contra los responsables de tratamiento.

Conformidad by design. Una conformidad añadida tras el despliegue depende de la buena voluntad del proveedor y de la estabilidad de su hoja de ruta. Una conformidad by design es una propiedad de la propia arquitectura: anonimización en origen, ausencia de almacenamiento intermedio, reglas RGPD integradas en el motor de tratamiento. El matiz es invisible mientras no haya auditoría. Se vuelve decisivo el día de la inspección.

Resiliencia documentada. NIS2 y DORA exigen una demostración de resiliencia, no una declaración. Eso supone poder reconstituir rápidamente los flujos, las dependencias, los puntos de fallo. McKinsey lo resume en un informe reciente: cuatro etapas de consolidación de las capacidades data deben preceder a todo despliegue agéntico a gran escala. La orquestación ya no es una obra técnica secundaria. Es un requisito previo de conformidad.

Tres preguntas que todo CIO de salud debería plantearse

1. ¿Dónde están almacenados mis datos, pero sobre todo dónde son tratados? La elección del alojador es visible. La de la capa de orquestación lo es mucho menos. Los datos que transitan por un motor analítico extranjero no se benefician de la soberanía de su alojador.

2. ¿Mis socios tecnológicos están a salvo de las requisitorias extraterritoriales? Una filial europea de un grupo estadounidense sigue sujeta, en última instancia, al derecho de su empresa matriz. La soberanía efectiva pasa por una cadena de dependencias íntegramente europea, verificable de la infraestructura a la capa aplicativa.

3. ¿Mi conformidad es nativa en la arquitectura o añadida en capa? La consulta DPIA del EDPB se cierra el 9 de junio de 2026. Los establecimientos que anticipan desde ahora una arquitectura de tratamiento compatible DPIA toman ventaja sobre los que esperarán la publicación de las directrices finales para reaccionar.

La migración de Azure a Scaleway de la Plataforma de Datos de Salud no es un fin. Es un comienzo. El alojamiento soberano resuelve la cuestión de la jurisdicción. Queda por tratar la del tratamiento. Los establecimientos que se apoyan en una capa de orquestación europea, sin almacenamiento intermedio y con trazabilidad nativa, no toman simplemente una precaución jurídica: preparan su conformidad 2027, esa que no se recupera con prisas.

Descubra cómo iD4Connect aborda estos desafíos en el sector salud →

Le 14 avril 2026, le Comité européen de la protection des données a ouvert à consultation son premier template DPIA harmonisé à l’échelle de l’UE. Derrière la promesse de simplification administrative, une bascule méthodologique plus silencieuse : la séparation entre les risques de conception et les risques d’incident. Une distinction qui redistribue les cartes entre les plateformes qui protègent les données, et celles qui conçoivent l’absence de risque.

L’harmonisation que les DPO attendaient depuis 2018

Le 14 avril 2026, l’EDPB a rendu public son premier template harmonisé de Data Protection Impact Assessment, adopté en version 1.0 dès le 10 mars par procédure écrite. Le document est ouvert à consultation publique jusqu’au 9 juin 2026. Après cette date, toutes les autorités européennes (CNIL incluse) devront l’adopter comme modèle unique, ou comme méta-modèle avec lequel leurs templates nationaux devront rester compatibles.

Pour les DPO qui gèrent des traitements transfrontaliers, c’est la fin d’une fragmentation qui durait depuis sept ans. Jusqu’ici, une DPIA structurée selon une approche nationale n’était pas nécessairement reconnue par une autre autorité. Le template EDPB met fin à cette asymétrie.

C’est la lecture consensuelle du texte. Elle est juste, mais elle passe à côté de l’essentiel.

Deux risques, deux sections, deux logiques

La vraie innovation du template 2026 n’est pas formelle. Elle est méthodologique. Pour la première fois dans un document opposable à l’échelle européenne, le template distingue deux natures de risques que la plupart des méthodologies DPIA de la première génération mélangeaient dans une matrice unique.

Dans la section 3, le contrôleur documente les risques inhérents au traitement lui-même. Ceux qui existent même si tout fonctionne parfaitement, si aucune configuration ne dérape, si aucun attaquant n’entre dans le système. Centralisation des données, durées de conservation étendues, identifiants persistants, combinaison de jeux hétérogènes. Ces risques sont des conséquences de choix architecturaux, pas d’événements.

Dans la section 4, séparément, on documente les risques opérationnels. Bugs, mauvaises configurations, erreurs humaines, accès abusifs, attaques externes. Ce sont les risques d’incident.

Cette séparation paraît technique. Elle est en réalité politique. Elle force une question que les DPIA de la première génération éludaient régulièrement : cette architecture est-elle compatible avec les droits et libertés des personnes, même quand elle fonctionne comme prévu ?

Autrement dit, avant même de parler de sécurité, est-ce que le design lui-même pose problème ? La réponse à cette question ne se trouve pas dans la qualité des pare-feux. Elle se trouve dans le plan d’architecture.

Quand la sécurité ne répare pas la conception

La réponse, pour un grand nombre d’architectures actuelles, est inconfortable. Un data lake construit autour d’un stockage centralisé long-durée, même parfaitement opéré, porte des risques structurels qui se documentent désormais dans une section à part, sans que l’ajout de mesures opérationnelles n’y réponde.

Le chiffrement ne transforme pas une rétention de dix ans en une absence de rétention. Le contrôle d’accès ne rend pas anodin le fait de concentrer en un endroit unique les données sensibles de millions de personnes. La section 3 du template obligera à documenter ces choix pour eux-mêmes.

Les plateformes qui ont grandi sur le modèle « collecter largement, stocker durablement, protéger intensivement » vont devoir affronter ce miroir. Ce n’est pas une accusation, c’est un constat. Le template EDPB n’invente rien : il rend explicite ce que l’article 25 du RGPD demandait depuis 2018. Mais il le rend explicite dans une section dédiée, traçable, comparable d’un dossier à l’autre.

L’autre miroir : les architectures qui n’ont rien à stocker

Le miroir renvoie une image très différente quand on regarde des architectures conçues autrement.

Une plateforme qui traite les données pendant leur transport, sans les déplacer ni les stocker, compresse par conception la section 3 du template. Il n’y a pas de centralisation à documenter, parce qu’il n’y a pas de centralisation. Il n’y a pas de durée de rétention à justifier, parce que le traitement est in-transit. Les jeux combinés ne laissent pas de trace persistante, parce que la combinaison se dissout avec le contexte d’usage. Les identifiants persistants disparaissent, parce que la plateforme n’en fabrique pas.

C’est le principe de la technologie DataCell d’iD4Connect : chaque unité de traitement agit sur la donnée pendant son transit, puis la libère. Rien ne persiste côté plateforme. DataGraph assure l’intelligence contextuelle, qui se dissout avec le contexte d’usage. L’architecture n’est pas une couche de protection ajoutée sur une topologie classique. C’est une autre topologie (voir l’architecture complète).

Et la section 4, sur les incidents ? Elle reste à remplir, bien sûr. Aucune architecture ne dispense d’analyser ses propres défaillances. Mais quand l’actif à défendre n’inclut ni data lake ni warehouse, la question « que se passe-t-il si un attaquant entre » change de nature. Il n’y a pas de patrimoine à exfiltrer hors des sources, qui restent dans le périmètre du contrôleur d’origine avec leurs propres mesures.

Une architecture qui n’a rien à perdre ne se défend pas comme une architecture qui a tout à protéger.

Cinq questions pour tester votre DPIA actuelle

Avant la finalisation du template en juin, il peut être utile de passer votre DPIA actuelle, ou votre dernière revue, au filtre de cinq questions. Elles ne remplacent pas une analyse de conformité, mais elles donnent un signal rapide.

1. Votre section sur les risques distingue-t-elle clairement ceux qui viennent de la conception du traitement et ceux qui viennent d’incidents opérationnels, ou les deux sont-ils traités dans une matrice unique ?
2. Quand vous décrivez vos mesures au titre de l’article 25 (data protection by design), s’agit-il de paramétrages ajoutés sur une architecture existante, ou de propriétés intrinsèques de l’architecture elle-même ?
3. Si une autorité vous demandait demain : « que se passerait-il pour les personnes concernées si toute l’architecture fonctionnait parfaitement, sans incident aucun », votre réponse serait-elle courte ou longue ?
4. Votre inventaire d’actifs (section 1.3 du template) comprend-il des composants de stockage long-durée qui existent principalement pour des raisons d’historique, et dont la valeur métier serait dure à défendre aujourd’hui ?
5. Si vous recommenciez l’architecture à zéro, avec les standards 2026 en tête, choisiriez-vous la même topologie de données, ou une autre ?

Ces questions ne se posaient pas dans les mêmes termes il y a un an. Elles vont se poser dans ces termes pendant les cinq prochaines.

Selon votre rôle, ce que cela change

Pour un DPO : à mission égale, le volume de documentation nécessaire dépend désormais du type d’architecture. Défendre une DPIA devant l’autorité devient mécaniquement plus simple quand l’architecture sous-jacente n’oblige pas à justifier chaque risque structurel par une mesure compensatoire.

Pour un RSSI : un nouveau type d’outil entre dans la conversation. Non pas un produit de sécurité additionnel, mais une architecture de données qui réduit mécaniquement la surface à défendre. « Une donnée qu’on ne peut pas voler n’a pas besoin d’être défendue » cesse d’être un aphorisme pour devenir une catégorie documentaire.

Pour un DSI ou un CTO : un arbitrage économique se formalise. Les plateformes d’analytique centralisée ont un coût d’opération et un coût de conformité. Jusqu’ici, le second restait diffus, inégal, difficile à chiffrer. Le template EDPB le rend visible section par section. Dans les secteurs régulés (finance & banque, santé, énergie, secteur public), où chaque DPIA est documentée, auditée et revue, cet arbitrage cesse d’être théorique.

Pour une autorité de régulation : un critère de différenciation gagne en lisibilité. Les architectures qui incarnent l’article 25 par conception et non par paramétrage ont désormais un langage commun pour le démontrer, et un langage pour les autorités pour le reconnaître.

Contribuer à la consultation, pendant qu’elle est ouverte

La consultation EDPB est ouverte jusqu’au 9 juin. Toute contribution sera publiée sur le site de l’autorité.

Nous pensons que le template gagnerait à reconnaître explicitement, dans sa section sur le data protection by design, la catégorie des architectures data-at-source et stateless. Non pas parce qu’elles seraient meilleures en soi (ce jugement appartient aux contrôleurs et à leurs autorités), mais parce qu’elles transforment qualitativement, et non quantitativement, le profil de risque d’un traitement.

C’est pourquoi nous invitons les DPO, juristes, intégrateurs et éditeurs qui ont une expérience concrète de ces architectures à participer à la consultation. Une consultation publique n’est utile que si ceux qui font le travail prennent la peine d’écrire.

Dans six semaines, le template sera finalisé. Dans quelques mois, il sera la référence opposable à tous les éditeurs de plateformes de données présents en Europe. Deux questions se posent à ce moment-là, une technique et une stratégique. La première, nous venons de la poser.

La seconde est plus simple : et si vous recommenciez l’architecture demain, choisiriez-vous la même ?

Le template DPIA de l’EDPB n’invente aucune obligation nouvelle. Il rend simplement lisible ce que l’article 25 du RGPD demandait depuis 2018 : séparer ce qui relève de la conception du traitement et ce qui relève de l’incident. Dans cette grille de lecture, les architectures qui ne stockent pas les données n’ont pas à compenser leur design par des mesures : elles réduisent mécaniquement le périmètre à documenter. D’ici juin, ce ne sera plus une intuition. Ce sera un format opposable.

Découvrez comment iD4Connect adresse ces enjeux →

On 14 April 2026, the European Data Protection Board opened its first EU-wide harmonised DPIA template for public consultation. Behind the promise of administrative simplification, a quieter methodological shift: the separation between design risks and incident risks. A distinction that redistributes the cards between platforms that protect data, and those that engineer the absence of risk.

The harmonisation DPOs have been waiting for since 2018

On 14 April 2026, the EDPB released its first harmonised Data Protection Impact Assessment template, adopted as version 1.0 on 10 March through written procedure. The document is open for public consultation until 9 June 2026. After that date, all European authorities (including France’s CNIL) will have to adopt it as their sole standard, or as a meta-template with which their national templates must remain compatible.

For DPOs handling cross-border processing, this ends a fragmentation that has lasted seven years. Until now, a DPIA structured according to one national approach was not necessarily recognised by another authority. The EDPB template puts an end to this asymmetry.

That is the consensus reading of the text. It is accurate, but it misses the essential point.

Two risks, two sections, two logics

The real innovation of the 2026 template is not formal. It is methodological. For the first time in a document enforceable across Europe, the template distinguishes two natures of risks that most first-generation DPIA methodologies mixed into a single matrix.

In section 3, the controller documents the risks inherent to the processing itself. Those that exist even if everything works perfectly, if no configuration goes wrong, if no attacker enters the system. Data centralisation, extended retention periods, persistent identifiers, combination of heterogeneous datasets. These risks are consequences of architectural choices, not events.

In section 4, separately, operational risks are documented. Bugs, misconfigurations, human errors, abusive access, external attacks. These are incident risks.

This separation seems technical. It is in fact political. It forces a question that first-generation DPIAs regularly sidestepped: is this architecture compatible with people’s rights and freedoms, even when it operates as intended?

In other words, before even talking about security, does the design itself pose a problem? The answer to this question is not found in the quality of firewalls. It is found in the architecture blueprint.

When security does not repair design

The answer, for a large number of current architectures, is uncomfortable. A data lake built around centralised long-duration storage, even perfectly operated, carries structural risks that will now be documented in a separate section, without operational measures answering them.

Encryption does not turn a ten-year retention into an absence of retention. Access control does not make it harmless to concentrate in a single place the sensitive data of millions of people. Section 3 of the template will require documenting these choices for what they are.

Platforms that grew on the « collect broadly, store durably, protect intensively » model will have to face this mirror. This is not an accusation, it is an observation. The EDPB template invents nothing: it makes explicit what Article 25 of the GDPR has required since 2018. But it makes it explicit in a dedicated, traceable, comparable section from one file to another.

The other mirror: architectures that have nothing to store

The mirror returns a very different image when we look at architectures designed differently.

A platform that processes data during its transport, without moving or storing it, compresses section 3 of the template by design. There is no centralisation to document, because there is no centralisation. There is no retention period to justify, because processing is in-transit. Combined datasets leave no persistent trace, because the combination dissolves with the usage context. Persistent identifiers disappear, because the platform does not manufacture any.

This is the principle of iD4Connect’s DataCell technology: each processing unit acts on the data during its transit, then releases it. Nothing persists on the platform side. DataGraph provides contextual intelligence, which dissolves with the usage context. The architecture is not a protection layer added on top of a classic topology. It is a different topology (see the full architecture).

And section 4, on incidents? It still needs to be filled in, of course. No architecture exempts one from analysing its own failures. But when the asset to defend includes neither a data lake nor a warehouse, the question « what happens if an attacker gets in » changes in nature. There is no estate to exfiltrate outside the sources, which remain within the original controller’s perimeter with their own measures.

An architecture that has nothing to lose is not defended like one that has everything to protect.

Five questions to test your current DPIA

Before the template is finalised in June, it may be useful to run your current DPIA, or your latest review, through five questions. They do not replace a compliance analysis, but they give a quick signal.

1. Does your risk section clearly distinguish risks coming from the design of the processing from those coming from operational incidents, or are both treated in a single matrix?
2. When you describe your measures under Article 25 (data protection by design), are they parameters added on top of an existing architecture, or intrinsic properties of the architecture itself?
3. If an authority asked you tomorrow: « what would happen to data subjects if the entire architecture worked perfectly, without any incident », would your answer be short or long?
4. Does your asset inventory (section 1.3 of the template) include long-duration storage components that exist mainly for historical reasons, and whose business value would be hard to defend today?
5. If you started the architecture from scratch, with 2026 standards in mind, would you choose the same data topology, or a different one?

These questions were not asked in these terms a year ago. They will be asked in these terms for the next five.

What it changes depending on your role

For a DPO: at equal scope, the volume of documentation required now depends on the type of architecture. Defending a DPIA before an authority becomes mechanically simpler when the underlying architecture does not require justifying each structural risk with a compensatory measure.

For a CISO: a new type of tool enters the conversation. Not an additional security product, but a data architecture that mechanically reduces the surface to defend. « Data that cannot be stolen does not need to be defended » stops being an aphorism and becomes a documentary category.

For a CIO or CTO: an economic trade-off becomes formal. Centralised analytics platforms carry both an operational cost and a compliance cost. Until now, the latter remained diffuse, uneven, hard to quantify. The EDPB template makes it visible section by section. In regulated sectors (finance & banking, healthcare, energy, public sector), where every DPIA is documented, audited and reviewed, this trade-off stops being theoretical.

For a regulatory authority: a differentiation criterion gains legibility. Architectures that embody Article 25 by design rather than by parameter now have a common language to demonstrate it, and authorities have a common language to recognise it.

Contributing to the consultation while it is open

The EDPB consultation is open until 9 June. Every contribution will be published on the authority’s website.

We believe the template would benefit from explicitly recognising, in its section on data protection by design, the category of data-at-source and stateless architectures. Not because they would be better in themselves (that judgment belongs to controllers and their authorities), but because they transform qualitatively, and not quantitatively, the risk profile of a processing operation.

That is why we invite DPOs, lawyers, integrators and vendors with concrete experience of these architectures to participate in the consultation. A public consultation is only useful if those who do the work take the time to write.

In six weeks, the template will be finalised. In a few months, it will be the benchmark applicable to every data platform vendor operating in Europe. Two questions arise at that point, one technical and one strategic. We have just asked the first.

The second is simpler: if you were starting the architecture tomorrow, would you choose the same one?

The EDPB DPIA template creates no new obligation. It simply makes legible what Article 25 of the GDPR has required since 2018: to separate what relates to the design of processing from what relates to incidents. Within this reading grid, architectures that do not store data have no need to compensate for their design with measures: they mechanically reduce the perimeter to document. By June, it will no longer be an intuition. It will be an enforceable format.

Discover how iD4Connect addresses these challenges →

El 14 de abril de 2026, el Comité Europeo de Protección de Datos abrió a consulta su primera plantilla DPIA armonizada a escala de la UE. Detrás de la promesa de simplificación administrativa, un giro metodológico más silencioso: la separación entre los riesgos de diseño y los riesgos de incidente. Una distinción que redistribuye las cartas entre las plataformas que protegen los datos y las que conciben la ausencia de riesgo.

La armonización que los DPO esperaban desde 2018

El 14 de abril de 2026, el EDPB hizo pública su primera plantilla armonizada de Data Protection Impact Assessment, adoptada en versión 1.0 el 10 de marzo mediante procedimiento escrito. El documento está abierto a consulta pública hasta el 9 de junio de 2026. Después de esa fecha, todas las autoridades europeas (incluida la CNIL francesa) deberán adoptarla como modelo único, o como meta-modelo con el que sus plantillas nacionales deberán permanecer compatibles.

Para los DPO que gestionan tratamientos transfronterizos, es el fin de una fragmentación que duraba desde hace siete años. Hasta ahora, un DPIA estructurado según un enfoque nacional no era necesariamente reconocido por otra autoridad. La plantilla EDPB pone fin a esta asimetría.

Es la lectura consensuada del texto. Es acertada, pero pasa por alto lo esencial.

Dos riesgos, dos secciones, dos lógicas

La verdadera innovación de la plantilla 2026 no es formal. Es metodológica. Por primera vez en un documento oponible a escala europea, la plantilla distingue dos naturalezas de riesgos que la mayoría de las metodologías DPIA de primera generación mezclaban en una matriz única.

En la sección 3, el responsable documenta los riesgos inherentes al propio tratamiento. Los que existen incluso si todo funciona perfectamente, si ninguna configuración se descontrola, si ningún atacante entra en el sistema. Centralización de datos, duraciones de conservación prolongadas, identificadores persistentes, combinación de conjuntos heterogéneos. Estos riesgos son consecuencias de elecciones arquitectónicas, no de eventos.

En la sección 4, por separado, se documentan los riesgos operativos. Bugs, malas configuraciones, errores humanos, accesos abusivos, ataques externos. Son los riesgos de incidente.

Esta separación parece técnica. Es en realidad política. Obliga a plantear una pregunta que los DPIA de primera generación eludían con frecuencia: ¿es esta arquitectura compatible con los derechos y libertades de las personas, incluso cuando funciona como está previsto?

Dicho de otro modo, antes incluso de hablar de seguridad, ¿es el propio diseño el que plantea un problema? La respuesta a esta pregunta no se encuentra en la calidad de los cortafuegos. Se encuentra en el plano de arquitectura.

Cuando la seguridad no repara el diseño

La respuesta, para un gran número de arquitecturas actuales, es incómoda. Un data lake construido en torno a un almacenamiento centralizado de larga duración, incluso perfectamente operado, comporta riesgos estructurales que ahora se documentan en una sección aparte, sin que la adición de medidas operativas los responda.

El cifrado no transforma una retención de diez años en una ausencia de retención. El control de accesos no hace inocuo el hecho de concentrar en un único lugar los datos sensibles de millones de personas. La sección 3 de la plantilla obligará a documentar estas elecciones por sí mismas.

Las plataformas que han crecido sobre el modelo «recolectar ampliamente, almacenar duraderamente, proteger intensamente» tendrán que enfrentarse a este espejo. No es una acusación, es una constatación. La plantilla EDPB no inventa nada: hace explícito lo que el artículo 25 del RGPD pedía desde 2018. Pero lo hace explícito en una sección dedicada, trazable, comparable de un expediente a otro.

El otro espejo: las arquitecturas que no tienen nada que almacenar

El espejo devuelve una imagen muy diferente cuando se observan arquitecturas concebidas de otro modo.

Una plataforma que trata los datos durante su transporte, sin desplazarlos ni almacenarlos, comprime por diseño la sección 3 de la plantilla. No hay centralización que documentar, porque no hay centralización. No hay duración de retención que justificar, porque el tratamiento es in-transit. Los conjuntos combinados no dejan traza persistente, porque la combinación se disuelve con el contexto de uso. Los identificadores persistentes desaparecen, porque la plataforma no los fabrica.

Es el principio de la tecnología DataCell de iD4Connect: cada unidad de tratamiento actúa sobre el dato durante su tránsito y luego lo libera. Nada persiste del lado de la plataforma. DataGraph garantiza la inteligencia contextual, que se disuelve con el contexto de uso. La arquitectura no es una capa de protección añadida sobre una topología clásica. Es otra topología (ver la arquitectura completa).

¿Y la sección 4, sobre los incidentes? Hay que rellenarla, por supuesto. Ninguna arquitectura exime de analizar sus propios fallos. Pero cuando el activo que se debe defender no incluye ni data lake ni warehouse, la pregunta «qué ocurre si un atacante entra» cambia de naturaleza. No hay patrimonio que exfiltrar fuera de las fuentes, que permanecen dentro del perímetro del responsable original con sus propias medidas.

Una arquitectura que no tiene nada que perder no se defiende como una arquitectura que tiene todo que proteger.

Cinco preguntas para poner a prueba su DPIA actual

Antes de la finalización de la plantilla en junio, puede ser útil pasar su DPIA actual, o su última revisión, por el filtro de cinco preguntas. No sustituyen a un análisis de cumplimiento, pero dan una señal rápida.

1. ¿Distingue claramente su sección sobre los riesgos los que provienen del diseño del tratamiento de los que provienen de incidentes operativos, o se tratan ambos en una matriz única?
2. Cuando describe sus medidas en el marco del artículo 25 (data protection by design), ¿se trata de parámetros añadidos sobre una arquitectura existente, o de propiedades intrínsecas de la propia arquitectura?
3. Si una autoridad le pidiera mañana: «¿qué ocurriría para las personas afectadas si toda la arquitectura funcionara perfectamente, sin incidente alguno?», ¿sería su respuesta corta o larga?
4. ¿Incluye su inventario de activos (sección 1.3 de la plantilla) componentes de almacenamiento de larga duración que existen principalmente por razones históricas, y cuyo valor de negocio sería difícil defender hoy?
5. Si recomenzara la arquitectura desde cero, con los estándares de 2026 en mente, ¿elegiría la misma topología de datos, u otra?

Estas preguntas no se planteaban en los mismos términos hace un año. Se plantearán en estos términos durante los cinco próximos.

Según su rol, lo que esto cambia

Para un DPO: a misión igual, el volumen de documentación necesario depende ahora del tipo de arquitectura. Defender un DPIA ante la autoridad se vuelve mecánicamente más sencillo cuando la arquitectura subyacente no obliga a justificar cada riesgo estructural mediante una medida compensatoria.

Para un CISO: un nuevo tipo de herramienta entra en la conversación. No un producto de seguridad adicional, sino una arquitectura de datos que reduce mecánicamente la superficie que defender. «Un dato que no se puede robar no necesita ser defendido» deja de ser un aforismo para convertirse en una categoría documental.

Para un CIO o un CTO: un arbitraje económico se formaliza. Las plataformas de analítica centralizada tienen un coste de operación y un coste de cumplimiento. Hasta ahora, el segundo permanecía difuso, desigual, difícil de cuantificar. La plantilla EDPB lo hace visible sección por sección. En los sectores regulados (finanzas y banca, salud, energía, sector público), donde cada DPIA es documentado, auditado y revisado, este arbitraje deja de ser teórico.

Para una autoridad de regulación: un criterio de diferenciación gana en legibilidad. Las arquitecturas que encarnan el artículo 25 por diseño y no por parámetro disponen ahora de un lenguaje común para demostrarlo, y las autoridades disponen de un lenguaje común para reconocerlo.

Contribuir a la consulta mientras está abierta

La consulta EDPB está abierta hasta el 9 de junio. Toda contribución será publicada en el sitio de la autoridad.

Creemos que la plantilla ganaría si reconociera explícitamente, en su sección sobre data protection by design, la categoría de las arquitecturas data-at-source y stateless. No porque fueran mejores en sí mismas (ese juicio corresponde a los responsables y a sus autoridades), sino porque transforman cualitativamente, y no cuantitativamente, el perfil de riesgo de un tratamiento.

Por eso invitamos a los DPO, juristas, integradores y editores que tienen experiencia concreta de estas arquitecturas a participar en la consulta. Una consulta pública solo es útil si quienes hacen el trabajo se toman la molestia de escribir.

Dentro de seis semanas, la plantilla estará finalizada. En unos meses, será la referencia oponible a todos los editores de plataformas de datos presentes en Europa. Dos preguntas se plantean en ese momento, una técnica y una estratégica. La primera, acabamos de plantearla.

La segunda es más simple: ¿y si recomenzara la arquitectura mañana, elegiría la misma?

La plantilla DPIA del EDPB no crea ninguna obligación nueva. Simplemente hace legible lo que el artículo 25 del RGPD pedía desde 2018: separar lo que corresponde al diseño del tratamiento y lo que corresponde al incidente. En esta rejilla de lectura, las arquitecturas que no almacenan los datos no tienen que compensar su diseño con medidas: reducen mecánicamente el perímetro que documentar. De aquí a junio, ya no será una intuición. Será un formato oponible.

Descubra cómo iD4Connect aborda estos desafíos →

Your emails run through American servers. Your files are stored with a Californian tech giant. Your work tools depend on companies subject to foreign laws. What if it all stopped tomorrow? Digital sovereignty is no longer a debate reserved for experts. In 2026, it’s an issue that concerns every European business.

Digital sovereignty: a simple definition

Digital sovereignty is the ability of a country, an organisation or a company to maintain control over its data, its infrastructure and its digital tools. In practical terms, it means knowing where your data is stored, who can access it, which laws govern it, and above all: do you really have the final say?

Today, the answer is often no. The majority of European businesses use cloud services, collaborative software and management tools provided by American companies. Microsoft 365 for emails, AWS or Azure for hosting, Google for analytics, Salesforce for CRM. The list is long and spans every business function.

This is not a problem in itself: these tools are powerful and have helped millions of businesses accelerate their digital transformation. The problem is what this concentration implies on a legal and strategic level. Because when your data passes through or is stored with a foreign provider, it is subject to the laws of that provider’s home country. Not yours. This is precisely the observation that led to the creation of iD4Connect, and it is the central thread of this article.

Why has this become a burning issue in 2026?

A few years ago, digital sovereignty looked like a niche debate. Not anymore. Several factors have tipped the subject into urgency.

The numbers first. According to the Cigref, 83% of European cloud and software spending goes to American players, roughly 264 billion euros per year (source: Roboto / Cigref). In France, 70% of data is hosted on non-European clouds (source: Institut Montaigne). And in Germany, a Bitkom survey reveals that 96% of businesses would not survive more than two years if the United States cut off its technology exports to Europe (source: France 24).

These figures are not theoretical. They reflect a structural dependency, built over twenty years of massive adoption of GAFAM solutions, often for good reasons: simplicity, cost, performance. But dependency comes at a price.

An unprecedented legal conflict between the US and Europe

The American Cloud Act, adopted in 2018, allows US authorities to access data hosted by American companies, even when that data is physically located in Europe (source: InCyber). This law directly contradicts the GDPR, which requires companies to protect the personal data of European citizens.

In other words: your files may sit in a data centre in Paris or Frankfurt, but if the provider is an American company, they remain subject to US jurisdiction. The geographical location of the server is not enough. It is the provider’s nationality that matters. This is one of the reasons why European players such as iD4Connect choose architectures where data is never stored: what exists nowhere cannot be seized anywhere.

Since September 2025, the European Data Act has strengthened the EU’s position by requiring cloud providers to implement technical measures to prevent any illegal access by foreign governments (source: Kiteworks). Meanwhile, Brussels launched a formal investigation into AWS, Azure and Google Cloud under the Digital Markets Act in late 2025 (source: CTOL Digital Solutions). The showdown is underway.

A geopolitical context that accelerates everything

Trade tensions between the United States and Europe, threats of retaliation over aggressive GAFAM regulation, and the rise of AI have changed the game. As French Digital Minister Clara Chappaz puts it: “there is no AI without cloud.” And sovereign AI means sovereign cloud (source: Banque des Territoires).

In January 2026, the French National Assembly voted to create a parliamentary inquiry committee on France’s digital dependencies (source: Roboto). The issue is no longer confined to CIOs: it has become political.

Key figures on European dependency

83% of European cloud and software spending goes to American players: 264 billion euros per year. (Cigref)

70% of French data is hosted on non-European clouds. (Institut Montaigne)

96% of German businesses would not survive two years without American technologies. (Bitkom / France 24)

The European sovereign cloud market is worth 12.4 billion euros in 2026, growing at 34%. (Markess / Tech Insider)

What paths forward to regain control ?

The good news is that European alternatives exist and are growing stronger every year. The European sovereign cloud market now exceeds 12 billion euros and is growing at over 30% annually (source: Tech Insider / Markess). First option: choose hosting providers and cloud vendors subject exclusively to European law. The ANSSI’s SecNumCloud certification is a reliable benchmark.

But beyond the choice of hosting provider, it is the very architecture of data processing that deserves rethinking. The traditional logic of “store everything, centralise everything” multiplies exposure surfaces. A different approach consists of processing data in transit, without intermediate storage, without duplication. This is the principle behind iD4Connect’s DataCell technology: each processing unit acts on the data during transit, then releases it. Nothing persists, nothing accumulates. Everything is deployed within the client’s own infrastructure (see the architecture).

This paradigm shift from data “at rest” to data “in motion” is probably one of the most structurally sound responses to sovereignty challenges. And it has the advantage of integrating with existing infrastructure without breaking anything.

Sus correos electrónicos pasan por servidores estadounidenses. Sus archivos están almacenados en un gigante tecnológico californiano. Sus herramientas de trabajo dependen de empresas sometidas a leyes extranjeras. ¿Y si mañana todo se detuviera? La soberanía digital ya no es un debate reservado a los expertos. En 2026, es un desafío que concierne a cada empresa europea.

Soberanía digital: una definición sencilla

La soberanía digital es la capacidad de un país, una organización o una empresa de mantener el control sobre sus datos, sus infraestructuras y sus herramientas digitales. En la práctica, significa saber dónde se almacenan sus datos, quién puede acceder a ellos, bajo qué leyes se rigen y, sobre todo: ¿tiene usted realmente la última palabra?

Hoy, la respuesta suele ser no. La mayoría de las empresas europeas utilizan servicios en la nube, software colaborativo y herramientas de gestión proporcionados por empresas estadounidenses. Microsoft 365 para el correo, AWS o Azure para el alojamiento, Google para la analítica, Salesforce para el CRM. La lista es larga y abarca todos los departamentos.

Esto no es un problema en sí mismo: estas herramientas son potentes y han permitido a millones de empresas acelerar su transformación digital. El problema es lo que esta concentración implica a nivel jurídico y estratégico. Porque cuando sus datos transitan o se almacenan en un proveedor extranjero, están sometidos a las leyes de su país de origen. No a las suyas. Precisamente esta constatación motivó la creación de iD4Connect, y es el hilo conductor de este artículo.

¿Por qué se ha convertido en un tema candente en 2026?

Hace unos años, la soberanía digital parecía un debate de nicho. Ya no. Varios factores han llevado el tema a la urgencia.

Las cifras primero. Según el Cigref, el 83 % del gasto europeo en cloud y software va a parar a actores estadounidenses, unos 264 000 millones de euros al año (fuente: Roboto / Cigref). En Francia, el 70 % de los datos se alojan en nubes no europeas (fuente: Institut Montaigne). Y en Alemania, una encuesta de Bitkom revela que el 96 % de las empresas no sobreviviría más de dos años si Estados Unidos cortara sus exportaciones tecnológicas a Europa (fuente: France 24).

Estas cifras no son teóricas. Reflejan una dependencia estructural, construida en veinte años de adopción masiva de soluciones GAFAM, a menudo por buenas razones: sencillez, coste, rendimiento. Pero la dependencia tiene un precio.

Un conflicto jurídico sin precedentes entre EE. UU. y Europa

La Cloud Act estadounidense, aprobada en 2018, permite a las autoridades de Estados Unidos acceder a los datos alojados por empresas estadounidenses, incluso cuando esos datos se encuentran físicamente en Europa (fuente: InCyber). Este texto entra en contradicción directa con el RGPD, que obliga a las empresas a proteger los datos personales de los ciudadanos europeos.

Dicho de otro modo: sus archivos pueden estar en un centro de datos en París o en Fráncfort, pero si el proveedor es una empresa estadounidense, siguen sometidos a la jurisdicción de Estados Unidos. La ubicación geográfica del servidor no basta. Lo que cuenta es la nacionalidad del proveedor. Esta es una de las razones por las que actores europeos como iD4Connect optan por arquitecturas donde el dato nunca se almacena: lo que no existe en ningún sitio no puede ser incautado en ningún sitio.

Desde septiembre de 2025, la Data Act europea ha reforzado la posición de la UE exigiendo a los proveedores cloud que implementen medidas técnicas para impedir cualquier acceso ilegal por parte de gobiernos extranjeros (fuente: Kiteworks). Paralelamente, Bruselas lanzó a finales de 2025 una investigación formal sobre AWS, Azure y Google Cloud en el marco del Digital Markets Act (fuente: CTOL Digital Solutions). El pulso está en marcha.

Un contexto geopolítico que lo acelera todo

Las tensiones comerciales entre Estados Unidos y Europa, las amenazas de represalias ante una regulación demasiado agresiva de los GAFAM y el auge de la IA han cambiado las reglas del juego. Como resume la ministra francesa de lo Digital, Clara Chappaz: «no hay IA sin cloud». Y quien dice IA soberana dice cloud soberano (fuente: Banque des Territoires).

En enero de 2026, la Asamblea Nacional francesa votó la creación de una comisión de investigación parlamentaria sobre las dependencias digitales de Francia (fuente: Roboto). El tema ya no es exclusivo de los directores de sistemas: se ha convertido en político.

Cifras clave de la dependencia europea

El 83 % del gasto europeo en cloud y software va a actores estadounidenses: 264 000 millones de euros al año. (Cigref)

El 70 % de los datos franceses se alojan en nubes no europeas. (Institut Montaigne)

El 96 % de las empresas alemanas no sobreviviría dos años sin tecnologías estadounidenses. (Bitkom / France 24) El mercado europeo de cloud soberano alcanza los 12 400 millones de euros en 2026, con un crecimiento del 34 %. (Markess / Tech Insider)

¿Qué caminos para recuperar el control?

La buena noticia es que las alternativas europeas existen y se fortalecen cada año. El mercado europeo de cloud soberano supera ya los 12 000 millones de euros y crece a más del 30 % anual (fuente: Tech Insider / Markess). Primera vía: elegir proveedores de alojamiento y cloud sometidos exclusivamente al derecho europeo. La certificación SecNumCloud de la ANSSI es un buen referente.

Pero más allá de la elección de proveedor, es la propia arquitectura del tratamiento de datos la que merece ser repensada. La lógica tradicional de «almacentar todo, centralizar todo» multiplica las superficies de exposición. Un enfoque diferente consiste en tratar los datos en tránsito, sin almacenamiento intermedio, sin duplicación. Es el principio de la tecnología DataCell de iD4Connect: cada unidad de tratamiento actúa sobre el dato durante su tránsito y luego lo libera. Nada persiste, nada se acumula. Todo se despliega dentro de la infraestructura del propio cliente (ver la arquitectura).

Este cambio de paradigma — del dato «en reposo» al dato «en movimiento» — es probablemente una de las respuestas más estructurantes a los desafíos de soberanía. Y tiene la ventaja de integrarse en las infraestructuras existentes sin romper nada.

Vos emails passent par des serveurs américains. Vos fichiers sont stockés chez un géant de la tech californien. Vos outils de travail dépendent d’entreprises soumises à des lois étrangères. Et si demain, tout s’arrêtait ? La souveraineté numérique n’est plus un débat réservé aux experts. En 2026, c’est un enjeu qui concerne chaque entreprise européenne.

Souveraineté numérique : une définition simple

La souveraineté numérique, c’est la capacité d’un pays, d’une organisation ou d’une entreprise à garder le contrôle sur ses données, ses infrastructures et ses outils numériques. Concrètement, cela signifie savoir où sont stockées vos données, qui peut y accéder, sous quelles lois elles sont régies, et surtout : est-ce que vous avez vraiment le dernier mot ?

Aujourd’hui, la réponse est souvent non. La majorité des entreprises européennes utilisent des services cloud, des logiciels collaboratifs et des outils de gestion fournis par des entreprises américaines. Microsoft 365 pour les emails, AWS ou Azure pour l’hébergement, Google pour l’analytique, Salesforce pour le CRM. La liste est longue et touche tous les métiers.

Ce n’est pas un problème en soi : ces outils sont performants et ont permis à des millions d’entreprises d’accélérer leur transformation numérique. Le problème, c’est ce que cette concentration implique sur le plan juridique et stratégique. Car quand vos données transitent ou sont stockées chez un prestataire étranger, elles sont soumises aux lois de son pays d’origine. Pas aux vôtres. C’est précisément ce constat qui a motivé la création d’iD4Connect, et c’est le fil rouge de cet article.

Pourquoi c’est devenu un sujet brûlant en 2026 ?

Il y a encore quelques années, la souveraineté numérique ressemblait à un débat de niche. Plus maintenant. Plusieurs facteurs ont fait basculer le sujet dans l’urgence.

Les chiffres d’abord. Selon le Cigref, 83 % des dépenses européennes en cloud et logiciels profitent à des acteurs américains, soit environ 264 milliards d’euros par an (source : Roboto / Cigref). En France, 70 % des données sont hébergées sur des clouds non européens (source : Institut Montaigne). Et en Allemagne, un sondage du Bitkom révèle que 96 % des entreprises ne survivraient pas plus de deux ans si les États-Unis coupaient leurs exportations technologiques vers l’Europe (source : France 24).

Ces chiffres ne sont pas théoriques. Ils traduisent une dépendance structurelle, construite en vingt ans d’adoption massive des solutions GAFAM, souvent pour de bonnes raisons : simplicité, coût, performance. Mais la dépendance a un prix.

Un conflit juridique inédit entre les États-Unis et l’Europe

Le Cloud Act américain, adopté en 2018, permet aux autorités des États-Unis d’accéder aux données hébergées par des entreprises américaines, y compris quand ces données se trouvent physiquement en Europe (source : InCyber). Ce texte entre en contradiction directe avec le RGPD, qui impose aux entreprises de protéger les données personnelles des citoyens européens.

Autrement dit : vos fichiers peuvent se trouver dans un datacenter à Paris ou à Francfort, mais si le fournisseur est une entreprise américaine, ils restent soumis à la juridiction des États-Unis. L’emplacement géographique du serveur ne suffit pas. C’est la nationalité du fournisseur qui compte. C’est l’une des raisons pour lesquelles des acteurs européens comme iD4Connect font le choix d’architectures où la donnée n’est jamais stockée : ce qui n’existe nulle part ne peut être saisi nulle part.

Depuis septembre 2025, le Data Act européen est venu renforcer la position de l’UE en exigeant des fournisseurs cloud qu’ils mettent en place des mesures techniques pour empêcher tout accès illégal de gouvernements étrangers (source : Kiteworks). En parallèle, Bruxelles a lancé fin 2025 une enquête formelle sur AWS, Azure et Google Cloud dans le cadre du Digital Markets Act (source : CTOL Digital Solutions). Le bras de fer est engagé.

Un contexte géopolitique qui accélère tout

Les tensions commerciales entre les États-Unis et l’Europe, les menaces de représailles en cas de régulation trop agressive des GAFAM, et la montée en puissance de l’IA ont changé la donne. Comme le résume la ministre française du Numérique Clara Chappaz : « il n’y a pas d’IA sans cloud ». Et qui dit IA souveraine dit cloud souverain (source : Banque des Territoires).

En janvier 2026, l’Assemblée nationale a voté la création d’une commission d’enquête parlementaire sur les dépendances numériques de la France (source : Roboto). Le sujet n’est plus cantonné aux DSI : il est devenu politique.

Les chiffres clés de la dépendance européenne

83 % des dépenses cloud et logiciels européennes vont à des acteurs américains, soit 264 milliards d’euros par an. (Cigref)

70 % des données françaises sont hébergées sur des clouds non européens. (Institut Montaigne)

96 % des entreprises allemandes ne survivraient pas deux ans sans technologies américaines. (Bitkom / France 24)

Le marché du cloud souverain européen pèse 12,4 milliards d’euros en 2026, en croissance de 34 %. (Markess / Tech Insider)

Quelles pistes pour reprendre le contrôle ?

La bonne nouvelle, c’est que les alternatives européennes existent et se renforcent chaque année. Le marché du cloud souverain européen pèse désormais plus de 12 milliards d’euros et croît de plus de 30 % par an (source : Tech Insider / Markess). Première piste : choisir des hébergeurs et fournisseurs cloud soumis exclusivement au droit européen. La certification SecNumCloud de l’ANSSI est un bon repère pour s’y retrouver.

Mais au-delà du choix d’hébergeur, c’est l’architecture même du traitement des données qui mérite d’être repensée. La logique traditionnelle du « tout stocker, tout centraliser » multiplie les surfaces d’exposition. Une approche différente consiste à traiter les données en transit, sans stockage intermédiaire, sans duplication. C’est le principe de la technologie DataCell d’iD4Connect : chaque unité de traitement agit sur la donnée pendant son transit, puis la libère. Rien ne persiste, rien ne s’accumule. Le tout se déploie dans l’infrastructure du client (voir l’architecture).

Ce changement de paradigme, de la donnée « au repos » vers la donnée « en mouvement », est probablement l’une des réponses les plus structurantes aux enjeux de souveraineté. Et elle a l’avantage de s’intégrer aux infrastructures existantes sans tout casser.