Le 08/07/2026, Aire a organisé la première session de Déployez votre Cloud, une série de rencontres conçues pour éclaircir les décisions techniques, juridiques et économiques entourant l’infrastructure numérique. Zigor Gaubeca, DSI d’Aire, et David Aibar Carretero, Head of Sales, ont concentré le webinaire sur une question que de nombreuses entreprises ne savent toujours pas répondre : où se trouvent leurs données, qui peut exercer une autorité sur elles et combien de temps il leur faudrait pour les transférer si les conditions changeaient. L’enregistrement complet est disponible sur le profil LinkedIn d’Aire.
Les clés de la souveraineté cloud en 20 secondes
- Héberger des données dans un centre de données européen n’implique pas qu’elles soient exclusivement soumises à la législation européenne.
- La nationalité, la structure sociétaire et le contrôle effectif du fournisseur déterminent également l’exposition juridique.
- Le CLOUD Act américain permet d’exiger de certains fournisseurs des données en leur possession, garde ou contrôle, même si elles sont stockées hors des États-Unis.
- Ce n’est pas une demande arbitraire à toute entreprise : elle doit suivre une procédure légale pour des informations spécifiques et inclut des mécanismes de contestation.
- Le futur Cloud and AI Development Act européen, connu sous le nom de CADA, est une proposition présentée en juin 2026 et doit encore faire l’objet de négociations.
- Le Data Act oblige déjà à faciliter la portabilité et à mieux préparer la sortie d’un prestataire cloud.
- La souveraineté ne signifie pas abandonner les hyperscalers, mais éviter que toute la continuité de l’activité dépende d’un seul fournisseur.
- La première mesure concrète consiste à classifier les données et tester un plan de sortie avant d’en avoir besoin.
Le point de départ de la rencontre était le cadre réglementaire complexe qui s’élabore autour du cloud. RGPD, Data Act, NIS2, le Règlement IA et la future initiative CADA ne constituent pas des éléments isolés. Ensemble, ils obligent entreprises et administrations à mieux connaître leurs dépendances, les pays d’où leurs services sont fournis, et les conditions pour récupérer leurs données.
Pendant la session, Gaubeca et Aibar ont souligné que la souveraineté numérique ne doit pas être considérée comme un débat théorique ni comme un choix entre « Europe » et « cloud public ». C’est une gestion des risques : savoir ce qu’il se passerait si un fournisseur modifiait ses prix, ses licences, recevait une instruction d’une autorité étrangère ou cessait de fournir un service essentiel.
L’emplacement du serveur n’est qu’une partie de la réponse
Pendant des années, beaucoup de décisions cloud se sont réduites à une question apparemment simple : dans quelle région sont hébergées les données ? Choisir Madrid, Paris, Francfort ou Dublin était considéré comme une mesure suffisante pour garder l’information en Europe.
La localisation physique est importante, mais ne suffit pas à elle seule pour répondre à la question juridique. Il faut aussi connaître qui contrôle l’entreprise contractante, quelles sociétés interviennent dans le service, quelles personnes peuvent gérer la plateforme et quelles lois étrangères peuvent l’exiger.
Le CLOUD Act adopté aux États-Unis en mars 2018 stipule que les fournisseurs soumis à leur juridiction doivent fournir, via une procédure légale, des données en leur possession, garde ou contrôle, même si elles sont stockées à l’étranger. Ainsi, un service déployé dans une région européenne n’est pas automatiquement hors de portée.
Il est important de préciser que le CLOUD Act ne permet pas à n’importe quel juge américain de demander sans restriction toutes les données d’une entreprise : ces demandes doivent porter sur des informations précises et soutenir des ordonnances, requêtes ou instruments juridiques valides. Les fournisseurs peuvent également faire appel de certaines demandes en cas de conflit avec des droits étrangers.
Le véritable risque n’est pas une porte grande ouverte sans contrôles, mais la superposition de deux cadres juridiques. Une entreprise européenne peut être obligée par le RGPD tout en dépendant d’un fournisseur soumis à une autorité américaine. Ce conflit a été souligné par les autorités européennes de protection des données peu après la mise en place de la réglementation.
D’où l’insuffisance de l’expression « les données sont en Europe ». Pour connaître la véritable exposition, il faut poser d’autres questions : qui contrôle les clés de chiffrement ? D’où est fourni le support ? Quels sous-traitants participent ? La société mère peut-elle accéder techniquement aux systèmes ? Quelles informations le fournisseur publie-t-il sur les demandes gouvernementales ? Existe-t-il une entité européenne véritablement indépendante ?
Le chiffrement réduit le risque, mais n’est pas une solution universelle. Lorsque le fournisseur détient les clés ou doit accéder en clair au contenu pour fournir le service, une ordonnance peut toujours affecter les données. Les garanties sont accrues si le client conserve la maîtrise exclusive des clés, et si la conception empêche l’opérateur de les reconstituer, même si cela n’est pas possible pour toutes les applications.
L’Europe veut rendre la souveraineté une condition mesurable
La Commission européenne a présenté le 03/06/2026 un paquet pour réduire la dépendance technologique extérieure. Une de ses œuvres principales est le Cloud and AI Development Act, CADA, qui vise à renforcer la capacité européenne en cloud, intelligence artificielle et centres de données.
CADA n’est pas encore une norme en vigueur. Elle devra être négociée avec le Parlement européen et le Conseil avant de connaître sa rédaction définitive. Cette précision est importante pour les entreprises : aujourd’hui, aucune obligation directement applicable ne découle du texte, même si sa orientation est déjà visible dans la commande publique et l’infrastructure critique.
La proposition intègre des critères de souveraineté pour les services utilisés dans des secteurs sensibles et pour les marchés publics. La localisation des données continuera à compter, mais seront aussi pris en compte la législation applicable, le contrôle sociétaire, la technologie utilisée et la possibilité pour une autorité étrangère d’interrompre le service ou d’accéder aux informations.
La Commission a exprimé son souci face aux « kill switches » : la capacité pour une entité ou un gouvernement étranger de suspendre une technologie essentielle pour les hôpitaux, réseaux énergétiques, administrations ou services financiers. Le débat ne se limite plus à la confidentialité mais inclut la continuité, la capacité industrielle et l’autonomie pour maintenir les systèmes clés durant une crise.
Gaubeca a expliqué lors du webinaire que ce cadre s’ajoute au RGPD, au Règlement IA et à NIS2. Chacun agit sur un risque différent, mais tous renforcent la responsabilité des entreprises quant à leurs fournisseurs, flux d’informations et plans de continuité.
NIS2 étend le nombre de secteurs soumis à des obligations de cybersécurité et intègre fournisseurs cloud, centres de données et prestataires de services managés dans une chaîne qui doit évaluer les risques, protéger ses opérations et notifier les incidents. L’Espagne procédait encore à sa transposition lors du webinaire.
Le Règlement IA ajoute une autre dimension : lorsqu’une entreprise transfère ses données à un outil génératif, elle doit non seulement vérifier où se trouve l’infrastructure, mais aussi contrôler quelles informations sont introduites par ses employés, si une base juridique existe pour leur traitement, comment prévenir la fuite de données et quels fournisseurs secondaires participent.
Un contrat garantissant que le modèle ne s’entraînera pas avec les données d’entreprise est utile, mais ne remplace pas les contrôles de prévention, classification, permissions et traçabilité des données. L’utilisation de l’IA en entreprise augmente la sortie d’informations sensibles via des actions simples comme copier un texte dans une fenêtre de chat.
Le plan de sortie n’est plus optionnel
L’un des messages les plus pratiques de la session : il faut concevoir la sortie avant d’entrer. David Aibar a pris l’exemple de la location d’un bureau : celui qui occupe un espace doit non seulement prévoir l’adaptation et le loyer mensuel, mais aussi estimer combien coûtera sa libération et son restitution dans les conditions convenues.
Ce qui ne se produit pas toujours avec le cloud. Les entreprises budgétisent la migration initiale, les ressources informatiques et la consommation mensuelle, mais rarement réservent des fonds pour extraire les données, transformer les applications et reconstruire des services chez un autre fournisseur.
Le problème survient lorsque la sortie devient involontaire. Une augmentation de prix, un changement de licences, une acquisition, une réglementation ou un conflit géopolitique peuvent transformer une architecture rentable en une dépendance difficile à maintenir.
Le Data Act européen cherche à réduire certains de ces obstacles. Ses dispositions principales entrent en vigueur le 12/09/2025 et obligent les fournisseurs à inclure des conditions transparentes pour changer de service ou revenir à une infrastructure propre.
La norme prévoit un délai transitoire max de 30 jours pour effectuer le changement après préavis contractuel. Si le fournisseur démontre que ce délai n’est pas techniquement réalisable, il peut proposer une alternative ne dépassant pas sept mois. Il doit aussi coopérer, maintenir la continuité et indiquer quelles données et actifs numériques peuvent être exportés.
Le règlement oblige aussi les fournisseurs à indiquer la juridiction applicable à leur infrastructure et les mesures prises pour éviter les accès gouvernementaux étrangers en conflit avec le droit européen. C’est une obligation de transparence en lien direct avec la question posée par Aire : sous quelle législation les données vivent-elles réellement ?
Les coûts liés au changement, y compris certains frais de sortie, doivent être limités pendant la période transitoire. À partir du 12/01/2027, les fournisseurs ne pourront plus faire payer les opérations obligatoires, bien que des services additionnels, coûts tiers ou pénalités contractuelles hors de cette opération puissent continuer à s’appliquer.
Supprimer une tarification ne rend pas automatiquement une application portable. Une plateforme construite autour de services propriétaires, bases de données, fonctions serverless et outils exclusifs peut demander des mois de développement pour fonctionner ailleurs.
Le blocage le plus difficile ne se trouve pas toujours dans les contrats, mais dans l’architecture.
Souveraineté ne signifie pas renoncer aux hyperscalers
La session n’a pas stigmatisé AWS, Microsoft Azure ou Google Cloud comme des ennemis. Leurs plateformes offrent une échelle, des services avancés et une vitesse d’innovation difficile à égaler, et restent une option raisonnable pour beaucoup de charges.
La souveraineté opérationnelle consiste à garder la capacité de décider ce qui s’exécute où, évitant qu’un seul fournisseur ait le pouvoir sur toutes les fonctions essentielles. Une entreprise peut utiliser un hyperscaler pour des services globaux ou d’innovation, tout en réservant une cloud européenne, une infrastructure privée ou un second opérateur pour les données critiques, les copies et la continuité.
Aibar a rappelé un principe classique en développement logiciel : faible couplage et haute cohésion. Depuis des décennies, on enseigne à programmer en évitant qu’un composant conditionne toute l’application, mais beaucoup ont construit des infrastructures entièrement dépendantes d’une plateforme unique.
La diversification ne doit pas se limiter à une répartition improvisée des charges. Un multicloud improvisé augmente la complexité, duplique les outils et complique la sécurité. L’organisation doit définir quels risques elle souhaite réduire et quelles applications justifient réellement une alternative.
La première étape consiste à classer l’information. Les données publiques, applications internes, dossiers médicaux, identifiants, algorithmes propriétaires et sauvegardes n’ont pas le même niveau de protection.
Une stratégie consiste à séparer trois groupes. Les charges sans données sensibles peuvent rester où c’est plus efficace. Les systèmes critiques peuvent être conçus pour fonctionner en environnement hybride. Les données dont la perte, l’accès ou l’interruption compromettraient l’activité doivent bénéficier du contrôle juridique, technique et opérationnel le plus strict.
Quatre actions qu’une entreprise doit entreprendre avant 2027
| Area | Question à laquelle répondre | Travail recommandé |
|---|---|---|
| Juridiction | Quels pays et sociétés peuvent exercer un contrôle sur le service ? | Élaborer une cartographie des fournisseurs, matrices, sous-traitants, localisations, personnel administratif et législation applicable |
| Classification | Quelles données supportent l’activité et celles qui peuvent être déplacées avec un risque moindre ? | Classer l’information et les charges selon leur sensibilité, dépendance, RTO, RPO et impact réglementaire |
| Sortie | Combien de temps et d’argent coûterait le changement de fournisseur ? | Documenter formats, volumes, bande passante, outils, transformations, personnel et coûts de migration |
| Test technique | Le plan fonctionne-t-il hors d’un document ? | Réaliser exportations, restaurations et démarrages périodiques dans une infrastructure alternative |
Le plan doit dépasser une simple clause contractuelle : il faut connaître combien de téraoctets doivent être transférés, combien le processus prendrait avec la bande passante disponible, et quels services ne peuvent pas être reproduits en dehors du fournisseur d’origine.
Les copies doivent aussi être récupérables dans un environnement différent. Une copie stockée chez le même fournisseur et dépendant de ses outils ne protège pas contre un blocage commercial, juridique ou technique global.
Le contrat doit préciser quels données peuvent être exportées, dans quels formats, avec quelle assistance, en combien de temps et à quel coût. Il doit également définir la suppression ultérieure, la disponibilité des registres, la restitution des clés et l’assistance durant la transition.
La dernière étape est le test. Une organisation ne sait pas si elle est souveraine parce que le fournisseur le déclare lors d’une présentation. Elle le sait lorsqu’elle peut restaurer une application, reconstruire un réseau et continuer le service dans un autre environnement dans un délai connu.
C’est l’idée qui anime la première session de Déployez votre Cloud : la souveraineté n’est pas une étiquette commerciale ni une localisation sur la carte. C’est la capacité à garder le contrôle lorsque change une loi, un contrat, un prix ou le contexte géopolitique.
L’enregistrement du webinaire avec Zigor Gaubeca et David Aibar Carretero est disponible à nouveau sur le profil LinkedIn d’Aire. La session ouvre une discussion qui, dans les mois à venir, ne sera plus limitée aux départements juridiques. CADA, le Data Act, NIS2 et la croissance de l’IA placeront la juridiction, la portabilité et le plan de sortie à l’ordre du jour de tout responsable technologie et continuité.
Questions fréquemment posées
La localisation des serveurs en Europe garantit-elle que le CLOUD Act ne s’applique pas ?
Non. La localisation physique n’est qu’un des facteurs. Il faut aussi vérifier si le fournisseur est soumis à la juridiction américaine et s’il possède, contrôle ou peut accéder aux données demandées.
Les États-Unis peuvent-ils accéder librement à toutes les données stockées chez un fournisseur américain ?
Non. Une procédure juridique valable doit viser des informations précises. Les fournisseurs peuvent faire appel à certaines demandes, même si la portée extraterritoriale de la loi crée des conflits avec le droit européen.
CADA oblige-t-il déjà les entreprises à utiliser un cloud européen ?
Non. La proposition de loi a été présentée en juin 2026 et doit encore passer par le processus législatif européen.
Que doit faire une entreprise soucieuse de sa souveraineté cloud en premier lieu ?
Inventorier ses fournisseurs et juridictions, classifier ses données sensibles et estimer le coût de leur transfert. Ensuite, il faut effectuer un test réel de sortie.