CADA : le nouveau cadre cloud/IA européen qui force les DSI à revoir leurs arbitrages

# CADA : le nouveau cadre cloud/IA européen qui force les DSI à revoir leurs arbitrages

*Analyse approfondie — Sécurité & Conformité — RiffLab Media, 2026*

Depuis le début de la décennie, les directions des systèmes d'information européennes naviguent dans un environnement réglementaire en accélération permanente. RGPD, NIS2, DORA, le Data Act : chaque texte a apporté son lot de contraintes nouvelles, parfois difficiles à absorber dans des structures où les cycles de transformation SI s'étalent sur plusieurs années. Avec le règlement CADA — *Cloud and AI Data Act* — entré en application progressive depuis début 2026, c'est une nouvelle couche qui s'ajoute, mais avec une particularité structurante : pour la première fois, un texte européen aborde simultanément les questions de dépendance infrastructurelle aux acteurs cloud non-européens et les obligations liées au déploiement de systèmes d'intelligence artificielle dans des environnements critiques.

Il ne s'agit pas d'un texte de plus. Il s'agit d'un signal politique clair : l'Union européenne ne considère plus la question de la souveraineté numérique comme un débat théorique réservé aux colloques institutionnels. Elle en fait une obligation de gestion du risque.

Pour les DSI, CTO et RSSI de PME et d'ETI, la question n'est plus de savoir si ces textes les concernent — ils les concernent — mais de comprendre ce qu'ils impliquent concrètement dans les choix d'architecture, de fournisseurs et de gouvernance des données.

Ce que le règlement CADA introduit réellement

Le CADA repose sur trois piliers distincts, qu'il est utile de distinguer avant d'en analyser les implications.

Le premier pilier porte sur la portabilité et la réversibilité des données hébergées dans des environnements cloud. Le texte renforce les obligations déjà esquissées dans le Data Act de 2023 en imposant des délais contractuels stricts pour la migration des données hors d'une plateforme, et en interdisant les pratiques tarifaires qui pénalisent économiquement le changement de fournisseur — ce qu'on appelait jusqu'ici les *egress fees*, ces frais de sortie de données qui constituaient, en pratique, un verrou de dépendance.

Le deuxième pilier concerne le traitement automatisé et les systèmes d'IA déployés sur des données à caractère sensible au sens large : données personnelles, données relatives aux infrastructures critiques, données de santé, données financières. Le CADA impose ici une traçabilité renforcée des décisions algorithmiques et une exigence de localisation des traitements pour certaines catégories, avec des critères qui croisent le niveau de risque de l'AI Act et les périmètres sectoriels de DORA et NIS2.

Le troisième pilier, souvent sous-estimé dans les analyses préliminaires, est celui de l'audit et de la certification des fournisseurs de services cloud et d'IA opérant sur le marché européen. Le CADA s'appuie sur le schéma EUCS — *European Union Cybersecurity Certification Scheme for Cloud Services* — que l'ENISA a finalisé dans une version révisée en 2025, et en fait une référence contractuelle opposable dans certains secteurs.

L'ensemble crée un cadre qui, pour la première fois, donne des outils juridiques concrets aux organisations européennes pour remettre en question des contrats avec des fournisseurs qui ne satisferaient pas aux nouvelles exigences.

Le nœud gordien de l'extraterritorialité américaine

On ne peut analyser le CADA sans replacer la question centrale qu'il tente de traiter : la dépendance des organisations européennes à des infrastructures numériques soumises au droit américain.

Le *Cloud Act* américain de 2018 — toujours en vigueur — autorise les autorités américaines à demander l'accès aux données stockées par des entreprises américaines, quelle que soit la localisation physique des serveurs concernés. C'est un point qui n'a pas évolué, malgré plusieurs tentatives de négociation transatlantique. Le *Privacy Shield* a été invalidé en 2020, son successeur l'*EU-US Data Privacy Framework* fait l'objet de contentieux persistants devant la CJUE. En 2026, le risque juridique lié à l'hébergement de données européennes chez un opérateur soumis au droit américain reste structurellement non résolu.

Or, la grande majorité des stacks logiciels des PME et ETI européennes s'appuie, pour tout ou partie, sur des services fournis par des acteurs américains : messagerie, collaboration, CRM, ERP en SaaS, infrastructure de calcul pour les applications IA. Ce n'est pas un jugement de valeur sur la qualité de ces services. C'est un constat de dépendance juridique.

Le CADA ne résout pas ce problème par magie, mais il crée une obligation nouvelle pour les organisations de *cartographier* et de *documenter* leur exposition à ce risque. Pour un RSSI, cela signifie concrètement qu'il doit être en mesure de répondre à la question : sur quels de mes traitements critiques mes données sont-elles potentiellement accessibles à des autorités non-européennes ? Et quelle est ma capacité contractuelle à m'y opposer ?

Les textes sectoriels — DORA pour la finance, NIS2 pour les opérateurs d'importance essentielle — imposent déjà des analyses de risque fournisseurs qui intègrent ce vecteur. Le CADA généralise cette logique à un spectre plus large d'organisations et l'articule explicitement avec les traitements IA.

Les implications pratiques pour les architectures SI

Face à ce cadre, plusieurs questions concrètes se posent aux équipes techniques et dirigeantes.

La question de la segmentation des données

La première réponse opérationnelle que développent les organisations avancées n'est pas une substitution totale de leur stack — ce serait irréaliste à court terme — mais une segmentation raisonnée entre les données et traitements qui peuvent rester dans des environnements à risque juridique élevé, et ceux qui doivent impérativement être relocalisés dans des environnements certifiés.

Cette logique de segmentation suppose un travail de classification préalable, souvent sous-réalisé dans les PME et ETI. Le CADA, en renforçant les obligations de traçabilité des traitements IA, pousse de facto les organisations à formaliser cette cartographie. C'est une contrainte, mais c'est aussi une opportunité de rationalisation.

Les certifications comme levier de négociation contractuelle

L'articulation du CADA avec l'EUCS crée une dynamique nouvelle dans les négociations fournisseurs. Les niveaux de certification EUCS — Basic, Substantial, High — ne sont pas équivalents en matière de protection contre les accès non-européens. Le niveau High impose des exigences d'immunité aux lois extraterritoriales que seuls des acteurs opérant sous droit européen peuvent aujourd'hui satisfaire pleinement.

Des acteurs comme **T-Systems** (filiale de Deutsche Telekom) ou **Scaleway** (groupe Iliad) se positionnent explicitement sur ce segment, avec des offres cloud certifiables EUCS High. Ce n'est pas une publicité pour ces acteurs : c'est une réalité de marché que les DSI doivent intégrer dans leur analyse. Pour les traitements les plus sensibles, la certification du fournisseur devient un critère de sélection objectif et défendable en cas d'audit.

L'IA embarquée dans les applicatifs SaaS : un angle mort à traiter

Un point particulièrement délicat concerne l'intégration croissante de capacités d'IA dans des applicatifs SaaS standard — suites bureautiques, outils de gestion de projet, plateformes CRM. En 2026, il est devenu difficile de trouver un logiciel de productivité qui ne propose pas une fonctionnalité d'assistance automatisée basée sur un modèle de langage.

Le CADA pose une question précise à ce sujet : lorsqu'un utilisateur soumet des données à une fonctionnalité IA intégrée dans un applicatif SaaS hébergé chez un acteur américain, ces données sont-elles traitées dans un environnement conforme aux obligations du nouveau cadre ? La réponse dépend de la configuration contractuelle, de la localisation effective du traitement IA, et du niveau de certification de l'infrastructure sous-jacente.

Beaucoup d'organisations n'ont tout simplement pas la réponse à cette question. C'est précisément ce manque de visibilité que le CADA cherche à corriger, en imposant des obligations de transparence aux fournisseurs. Mais tant que les audits ne seront pas systématiques, la charge reposera en pratique sur les équipes techniques internes.

Ce que cela change pour la gouvernance des risques

Au-delà des questions d'architecture, le CADA modifie la chaîne de responsabilité au sein des organisations.

Pour les RSSI d'abord : la conformité au CADA n'est pas une question purement IT. Elle suppose une articulation fine avec la direction juridique sur les clauses contractuelles fournisseurs, avec la direction générale sur les arbitrages stratégiques liés à la dépendance technologique, et avec les métiers sur la classification des données traitées par les nouveaux outils IA. C'est un mandat élargi qui suppose des ressources et une légitimité organisationnelle que toutes les structures n'ont pas encore accordées à la fonction.

Pour les CTO ensuite : les choix d'architecture qui étaient jusqu'ici principalement motivés par des critères de performance et de coût intègrent désormais un troisième vecteur structurant — la conformité réglementaire et la maîtrise du risque de souveraineté. Ce n'est pas nécessairement plus cher ou moins performant que les alternatives dominantes américaines, mais c'est un paramètre supplémentaire qui requiert une expertise nouvelle.

Pour les DSI enfin : le CADA, en s'articulant avec NIS2 et DORA, renforce la nécessité d'une vision intégrée du risque SI. Les entreprises qui abordent chaque texte réglementaire comme un projet isolé accumulent de la complexité et de la dette de conformité. Celles qui construisent une architecture de gouvernance cohérente — avec une cartographie des données, une analyse de risque fournisseurs centralisée, et une politique de certification claire — absorbent ces nouvelles contraintes à moindre coût.

Vers une fenêtre d'opportunité pour les acteurs européens ?

La question mérite d'être posée sans naïveté. Le CADA crée objectivement une pression nouvelle sur les stacks dominants américains, en particulier pour les traitements IA sur données sensibles. Il ne crée pas mécaniquement une demande pour des alternatives européennes si ces alternatives ne sont pas en mesure de répondre aux attentes fonctionnelles des organisations.

La réalité de 2026 est que l'écosystème européen a progressé de façon significative sur les couches infrastructure et sur certains segments applicatifs, mais que les gaps fonctionnels restent réels sur d'autres segments — notamment les modèles de langage intégrés à grande échelle, ou certaines capacités analytiques avancées. Une transition précipitée, motivée uniquement par la conformité sans validation fonctionnelle, serait une erreur de gestion.

La voie raisonnable est celle de la migration progressive et priorisée : identifier d'abord les traitements où le risque réglementaire est le plus élevé, évaluer les alternatives européennes disponibles sur ces segments spécifiques, et construire un plan de migration qui s'appuie sur les nouvelles obligations contractuelles de portabilité introduites par le CADA pour sécuriser les transitions.

Le règlement CADA est, en définitive, moins une contrainte supplémentaire qu'un accélérateur d'une prise de conscience déjà en cours. Les organisations qui attendaient un signal formel pour engager leur travail de souveraineté numérique l'ont maintenant. Celles qui avaient commencé ce travail disposent désormais d'un levier juridique pour le consolider.

Dans les deux cas, le temps de l'attente et de l'indécision est comptabilisé — et il a un coût.

*Article rédigé par la rédaction de RiffLab Media. Les analyses exprimées reflètent la ligne éditoriale du média, indépendant de tout acteur commercial ou institutionnel.*