Cloud and AI Development Act (CADA) : l'UE veut tripler ses datacenters et définir le cloud souverain

Bruxelles veut changer d'échelle sur l'infrastructure. Le Cloud and AI Development Act (CADA), proposé par la Commission européenne le 3 juin 2026, poursuit deux objectifs qui intéressent directement les hébergeurs et ceux qui administrent un serveur : au moins tripler la capacité des datacenters de l'Union européenne d'ici cinq à sept ans, et donner pour la première fois une définition harmonisée du cloud souverain, avec quatre niveaux d'assurance et des critères d'achat pour le secteur public. Le texte est toujours en négociation : selon MLex, une version de compromis préparée par la présidence irlandaise du Conseil devait être discutée par les États membres ce 10 novembre 2026.

Sources : page de la Commission européenne consacrée au Cloud and AI Development Act, proposition de règlement COM(2026) 502 et ses annexes, fiche de procédure 2026/0138(COD) de l'Observatoire législatif du Parlement européen, article de MLex du 4 novembre 2026 sur le compromis du Conseil et directive (UE) 2022/2555, dite NIS2, pour les définitions du service cloud et du centre de données.

Pour un propriétaire de serveur de jeu ou un admin de VPS, la question est simple : qu'est-ce que ce règlement européen change concrètement ? Réponse courte : rien d'immédiat pour un serveur FiveM ou Minecraft communautaire, mais beaucoup pour quiconque héberge des données pour une collectivité, une école, un hôpital ou une entreprise soumise à NIS2. Le détail, article par article.

Le CADA en bref

Le CADA est une proposition de règlement du Parlement européen et du Conseil, fondée sur les articles 114 et 173 du traité sur le fonctionnement de l'Union européenne. Il fait partie du paquet « souveraineté technologique » de la Commission, présenté avec le Chips Act 2.0, et prolonge le plan d'action « Continent de l'IA ». Une fois adopté, ce règlement s'appliquera directement dans les 27 États membres, sans loi de transposition.

Le constat de départ figure dans l'exposé des motifs : la part de marché des fournisseurs de cloud européens est passée de 29 % en 2017 à 15 % en 2022, et trois hyperscalers non européens contrôlent plus de 70 % du marché européen du cloud. La Commission y voit un risque de souveraineté numérique : ces fournisseurs relèvent de juridictions dont certaines lois ont une portée extraterritoriale et peuvent imposer l'accès aux données, à l'image du CLOUD Act américain souvent cité dans ce débat.

Tripler la capacité des datacenters européens

Le premier pilier du texte (titre III) s'attaque au manque de capacité de calcul et de stockage de données. La Commission veut garantir une puissance de calcul suffisante pour l'IA, les services de cloud computing et les applications intensives en données (big data, analytique). Elle constate que, faute de centres de données en nombre suffisant, des entreprises européennes font passer des charges de travail critiques par l'infrastructure d'hyperscalers étrangers. Pour accélérer la construction de data-centers sur le sol européen, la proposition prévoit plusieurs outils :

• Des zones d'accélération pour datacenters (article 10) : chaque État membre où de la capacité est en cours de déploiement devra en désigner au moins une dans les six mois suivant l'entrée en vigueur. Le choix tient compte de la capacité du réseau électrique, de la connectivité, de la réutilisation de la chaleur fatale, du stockage et de la production d'énergie propre sur site, et privilégie les friches industrielles plutôt que les terrains vierges.
• Un permis de base agrégé (article 13) : l'État réalise en amont les évaluations environnementales et l'urbanisme à l'échelle de la zone, puis délivre un permis global. Un projet de datacenter installé dans la zone n'a plus à demander que les autorisations propres à son installation.
• Une instruction des permis limitée à 12 mois à compter du dépôt d'un dossier complet, pour les projets situés en zone d'accélération (article 13).
• Un guichet unique d'information (article 12) qui accompagne l'opérateur de datacenter pour le permis de construire, les prélèvements d'eau, la récupération de chaleur et le raccordement au réseau électrique, avec un canal dédié aux PME.
• Des projets stratégiques (article 14) désignés par la Commission sur appel à manifestation d'intérêt, s'ils remplissent au moins deux critères sur cinq : servir des fonctions publiques essentielles (santé, éducation, sécurité), intégrer des technologies très durables ou innovantes, stabiliser le réseau électrique, utiliser des puces ou serveurs conçus ou fabriqués dans l'UE, ou combler une pénurie locale de capacité.

La durabilité n'est pas oubliée : les exigences fixées dans les zones d'accélération doivent s'appuyer sur les indicateurs de performance du règlement délégué (UE) 2024/1364, pris en application de la directive sur l'efficacité énergétique, et l'accès aux ressources de la zone (énergie, terrain) doit rester équitable et non discriminatoire, sans réservation spéculative (article 11). La Commission suivra enfin la capacité de calcul disponible, edge computing compris, la demande et l'écart à combler (article 15).

Ces mesures visent les opérateurs qui construisent des centres de données. Un hébergeur comme ElypseCloud, qui installe ses propres serveurs dans un datacenter existant à Paris, n'est pas concerné par les zones d'accélération. En revanche, plus de capacité disponible en Europe, c'est à terme plus de place en baie et d'énergie pour le housing de serveurs et les machines GPU dédiées à l'IA. Si vous découvrez la colocation, notre guide Housing en datacenter : comment ça marche explique le vocabulaire (U, baie, alimentation redondée A/B).

Une définition harmonisée du cloud souverain

Le deuxième pilier (titre IV) répond à une question restée floue jusqu'ici : qu'est-ce qu'un cloud souverain ? Aucune définition commune n'existait au niveau européen, et le Conseil avait lui-même demandé des critères partagés. En France, les acheteurs publics connaissent par exemple la qualification SecNumCloud délivrée par l'ANSSI. Le CADA crée un cadre européen de souveraineté du cloud unique, avec quatre niveaux d'assurance dont les critères figurent à l'annexe II du règlement. La définition du « service d'informatique en nuage » reprend celle de la directive NIS2, et inclut l'accès à distance à des systèmes d'IA hébergés.

Concrètement, un fournisseur de cloud qui veut être reconnu à un niveau dépose une demande auprès de l'autorité nationale compétente de son pays d'établissement (article 17). Pour le niveau 1, il suffit d'une auto-évaluation documentée (article 19). Point important pour les petits hébergeurs : la déclaration UE de conformité d'une PME au niveau 1 est reconnue directement et automatiquement dans tous les États membres, sans validation préalable par l'autorité. Les niveaux 2 à 4 exigent un audit par un organisme indépendant (article 20). La Commission tiendra un registre central des services reconnus (article 22), et tout changement important susceptible de remettre en cause la reconnaissance d'un fournisseur devra être signalé (article 23), sous peine de sanctions (article 24).

Les annexes seront revues au moins tous les 18 mois pour suivre l'évolution technique et juridique (article 16). La Commission précise aussi que les travaux reprendront sur le schéma européen de certification de cybersécurité du cloud (EUCS), qui traite de la sécurité technique, quand le CADA traite de la souveraineté et de la dépendance aux pays tiers.

IaaS, PaaS, SaaS : quels services cloud sont concernés ?

Le CADA ne réinvente pas la notion de cloud computing. Il reprend la définition du « service d'informatique en nuage » de la directive NIS2 (article 6, point 30) : un service numérique qui permet l'administration à la demande et un large accès à distance à un ensemble modulable et variable de ressources informatiques partageables, y compris quand ces ressources sont réparties sur plusieurs sites. Le considérant 33 de NIS2 précise que cette définition couvre tous les modèles de service, IaaS (infrastructure en tant que service), PaaS (plateforme), SaaS (logiciel) et NaaS (réseau), et tous les modèles de déploiement : cloud privé, communautaire, public et cloud hybride.

Les niveaux d'assurance peuvent donc concerner aussi bien un hébergement cloud d'infrastructure (serveurs virtuels, stockage, réseau) qu'une base de données managée ou une messagerie en SaaS. Le tableau rappelle qui gère quoi dans chaque modèle, et donc qui aura à démontrer la maîtrise de la chaîne.

Le housing n'est pas un service cloud au sens de NIS2. Il se rapproche du « service de centre de données » (article 6, point 31), défini comme les structures dédiées à l'hébergement, à l'interconnexion et à l'exploitation centralisées d'équipements informatiques et de réseau qui fournissent du stockage, du traitement et du transport de données, avec leurs installations électriques et de contrôle environnemental. Le cadre de souveraineté du CADA s'adresse, lui, aux fournisseurs de services cloud. Un data center loué en colocation laisse au client la main sur le matériel et sur toute la couche logicielle, à lui de documenter où et comment ses données sont traitées.

Les critères d'achat pour le secteur public

C'est la partie la plus concrète pour le marché de l'hébergement. Le CADA impose des règles aux acheteurs publics (pouvoirs adjudicateurs, institutions de l'UE) qui achètent des services cloud pour leur propre usage :

1. Évaluation des risques (article 29) : un an après l'entrée en vigueur, puis tous les deux ans, chaque État membre identifie les activités publiques qui contribuent à l'ordre public. Sont visés les secteurs des annexes I et II de NIS2 (énergie, santé, transports, eau, infrastructures numériques, etc.), ainsi que la sécurité nationale, la défense, la justice, la police et la gestion des frontières. L'analyse tient compte de la sensibilité des données, du risque d'accès illégal par un pays tiers et du risque d'interruption de service.
2. Niveau 1 au minimum (article 30) : un organisme public dont l'activité n'est pas liée à l'ordre public ne pourra utiliser que des services cloud reconnus au moins au niveau 1, donc avec des données hébergées dans l'UE.
3. Niveaux 2, 3 ou 4 pour l'ordre public : les activités identifiées comme sensibles ne pourront être confiées qu'à des services reconnus à l'un de ces niveaux. La méthodologie de la Commission devra imposer le niveau le plus élevé pour les activités les plus critiques, défense comprise.
4. Migration en 12 mois maximum : si l'évaluation des risques impose de changer de fournisseur, l'organisme dispose d'une période de transition plafonnée à 12 mois. L'analyse doit aussi envisager une stratégie multi-cloud ou multi-fournisseurs.
5. Dérogations encadrées : un acheteur peut s'écarter de ces règles s'il n'existe aucun service reconnu adapté dans le registre central, si un appel d'offres similaire lancé l'année précédente est resté sans offre convenable, ou si le coût serait disproportionné.

S'y ajoute un critère de valeur ajoutée de l'Union (article 32). Dans les marchés publics de services cloud et de systèmes d'IA innovants, les acheteurs devront noter, à côté du prix, la contribution du candidat à l'écosystème européen : logiciels ou matériel conçus ou fabriqués dans l'UE, technologies issues de la recherche européenne, composants de calcul, de stockage et de réseau d'origine européenne quand le marché le permet. Ces critères restent « accessoires et non décisifs » : ce n'est pas une préférence européenne obligatoire.

Enfin, la Commission pourra mener des achats groupés de services cloud, de datacenter et d'IA pour le compte des acheteurs publics volontaires (articles 37 à 40), une fédération européenne de cloud public baptisée EuroCloud permettra aux administrations de partager leur capacité inutilisée (article 34), et les organismes publics seront encouragés à privilégier l'open source (article 41). Les entreprises privées des secteurs NIS2 ne sont pas obligées de suivre ces règles, mais pourront conduire des analyses similaires, et la Commission pourra les y contraindre par acte délégué dans les secteurs de haute criticité (article 31).

Ce que ça change pour un admin de serveur

Le CADA ne crée aucune obligation pour un particulier ou une association qui fait tourner un serveur de jeu. Ses obligations visent les États, les acheteurs publics et les fournisseurs qui veulent vendre du cloud au secteur public. Voici les cas où il vous concerne vraiment :

• Vous hébergez des services pour un client public (mairie, établissement scolaire, hôpital, université) : une fois le règlement applicable, l'hébergement de ses données dans l'Union deviendra le plancher, et les marchés liés à l'ordre public exigeront un fournisseur reconnu à un niveau plus élevé. Une application métier, un Nextcloud auto-hébergé ou un portail sur un VPS Linux hébergé en France correspond déjà au critère de localisation décrit pour le niveau 1, mais aucune reconnaissance officielle n'existe tant que le texte n'est pas adopté.
• Votre entreprise relève de NIS2 : sans obligation directe, les analyses de risque du CADA risquent de devenir la référence de vos audits et de vos appels d'offres. Mieux vaut documenter dès maintenant où sont vos données, qui les opère et de quels prestataires vous dépendez.
• Vous faites tourner de l'IA sur votre infrastructure : la définition du service cloud retenue par le CADA inclut l'accès à distance à des systèmes d'IA hébergés. Un modèle servi depuis votre propre serveur dédié avec Ollama garde les données d'inférence sur une machine que vous contrôlez.
• Vous administrez un serveur FiveM, Minecraft ou Rust : rien à faire. Les règles de localisation des données ne s'appliquent pas à un serveur de jeu communautaire.

Mutualisé, VPS, dédié, cloud hybride : quel hébergement pour quelles données ?

Quand un client public ou un auditeur NIS2 pose la question de la souveraineté, il faut savoir où héberger quoi. Aucun mode d'hébergement n'est souverain par nature. Pour le niveau 1, ce qui compte est le lieu de traitement et de stockage. Pour les niveaux 2 à 4, s'ajoutent l'indépendance du fournisseur vis-à-vis des pays tiers, son contrôle depuis l'UE et la maîtrise de la chaîne logicielle.

Le CADA va dans le sens du cloud hybride quand il demande aux acheteurs publics d'envisager une stratégie multi-cloud ou multi-fournisseurs dans leur analyse de risques (article 30). Un montage courant consiste à garder les bases de données et les données personnelles sur un cloud privé virtualisé, monté sur un serveur dédié hébergé en France (notre comparatif Proxmox ou VMware aide à choisir l'hyperviseur), et à réserver le cloud public aux traitements sans données sensibles. Pour un simple site vitrine sans données métier, un hébergement web reste suffisant.

Checklist : cartographier son système d'information

Quel que soit votre cas, le contrôle de base est le même : savoir où se trouvent réellement vos données, et celles de vos utilisateurs. Cinq points à vérifier dès maintenant, sans attendre le texte final :

1. Le stockage de données : serveurs de production, bases de données, sauvegardes hors site (pensez à les chiffrer avant l'envoi), journaux, sans oublier les environnements de test et de préproduction, souvent remplis avec une copie de la production.
2. Les services SaaS annexes : supervision, messagerie, gestion des tickets, intégration continue, partage de fichiers. Chacun peut contenir des copies de données clients hébergées hors de l'UE sans que personne l'ait décidé.
3. Qui administre : en cas d'externalisation ou d'infogérance, l'accès administrateur à distance fait partie de la chaîne. Pour le niveau 3, la Commission cite la nationalité du personnel parmi les critères supplémentaires.
4. La sécurité des données : chiffrement au repos et en transit, clés conservées hors des mains du prestataire quand c'est possible, accès SSH durcis (voir sécuriser un serveur dédié). Le CADA traite la souveraineté, la sécurité technique reste l'affaire de NIS2 et, à terme, de l'EUCS.
5. La redondance et la réversibilité : une copie des données dans un second site de l'UE, et la possibilité de les récupérer dans un format standard. Un organisme public qui devra changer de fournisseur n'aura que 12 mois de transition au plus : un export qui n'a jamais été testé fera perdre du temps. Chez nous, ces règles sont écrites dans notre politique de sauvegarde et de réversibilité.

Le compromis discuté au Conseil autoriserait d'ailleurs, selon MLex, certains transferts de métadonnées et de télémétrie hors de l'UE à des fins de cybersécurité : un rappel que la donnée ne se limite pas au contenu de votre base de données.

Calendrier : quand le CADA s'appliquera-t-il ?

Le CADA n'est pas encore une loi. La proposition suit la procédure législative ordinaire : le Parlement européen et le Conseil de l'UE doivent chacun arrêter leur position, puis s'accorder sur un texte commun. Côté Conseil, l'Irlande assure la présidence jusqu'à la fin de l'année 2026. D'après MLex, son compromis réduirait certains pouvoirs de la Commission sur les exigences de souveraineté, assouplirait la mise en conformité et allongerait les délais de migration.

Les articles cités dans cette actualité correspondent à la proposition initiale de la Commission. Ils peuvent changer pendant les négociations, notamment sur les niveaux d'assurance et les délais de migration.

Où se situe ElypseCloud

ElypseCloud est un hébergeur français indépendant : nos propres serveurs physiques sont installés dans le datacenter Equinix PA6 à Paris (Tier III), et les données hébergées dessus restent en France. C'est le critère de localisation décrit pour le niveau 1. Nous ne revendiquons aucun niveau d'assurance CADA : le règlement n'est pas adopté et la procédure de reconnaissance n'existe pas encore. Nous suivrons la suite des négociations et mettrons cette actualité à jour quand le texte final sera publié. Pour l'autre grand chantier numérique européen du moment, lisez aussi notre actualité sur le Digital Omnibus et le RGPD.