Le paquet européen sur la souveraineté technologique : ce qui change vraiment pour votre stack SaaS

Le 27 mai 2026, la Commission européenne a dévoilé son Tech Sovereignty Package, un ensemble coordonné d'instruments articulé autour du Cloud and AI Development Act (CADA), la loi cloud/IA que la Commission présente en même temps que le paquet et qui harmoniserait une définition européenne de la « cloud souverain » et faciliterait la construction de centres de données, accompagné de la seconde itération du Chips Act et d'une stratégie open source renouvelée. Sa mesure phare est une restriction proposée des hyperscalers américains (AWS, Azure et Google Cloud) pour les données sensibles du secteur public en santé, finance et justice, dans les 27 États membres. C'est une proposition, pas encore une loi : elle doit encore être approuvée par les États membres pour entrer en vigueur. L'annonce était attendue depuis des semaines ; le contenu, moins. Cette page propose une lecture pragmatique du point de vue de ceux qui doivent prendre de véritables décisions d'achat SaaS dans les douze mois à venir, non un texte d'explication politique.

Le cadrage le plus utile est le suivant : le paquet est la consolidation institutionnelle de mouvements déjà engagés, non un nouvel axe. NIS2 est en vigueur depuis octobre 2024. DORA depuis janvier 2025. L'appel d'offres souverain cloud de 180 M€ attribué le 17 avril 2026 à Scaleway, Clever Cloud, OVH et STACKIT (à l'exclusion d'AWS, Azure et Google Cloud) a signalé que de vrais budgets d'achat avaient commencé à bouger. La France migre 2,5 millions d'agents publics hors de Microsoft. Le Schleswig-Holstein est à 80 % sans Microsoft. La Cour pénale internationale a quitté Microsoft pour OpenDesk en novembre 2025. Les banques néerlandaises cherchent publiquement des alternatives. Le paquet est le cadre qui organise ces mouvements en doctrine.

Pour un acheteur, la question pratique n'est pas « les logiciels américains sont-ils désormais illégaux ». Ils ne le sont pas, et le paquet ne propose aucune interdiction générale pour les acheteurs privés. Ce qu'il propose, c'est une limite contraignante sur les hyperscalers américains pour les données sensibles du secteur public ; tout ce qui est hors de ce périmètre relève de la direction à suivre, non de l'interdiction. La question pratique est où votre stack actuel se situe sur le spectre de la résilience, et quelle part vous devez modifier avant le prochain cycle de renouvellement.

Trois choses changent pour les acheteurs SaaS européens au second semestre 2026, et elles changent à des vitesses différentes.

Les achats du secteur public se durcissent immédiatement, et nomment désormais les hyperscalers. La restriction phare du paquet vise directement AWS, Azure et Google Cloud pour les données sensibles du secteur public en santé, finance et justice. Au-delà de ces secteurs, les appels d'offres pour les entités UE régulées (administration publique, chaîne défense, reste du secteur financier) écriront de plus en plus directement les exigences de cloud souverain et de sous-traitants UE dans l'offre. Pour les éditeurs vendant sur ces marchés, l'absence de région d'hébergement UE ou d'une chaîne de sous-traitants propre n'est plus une objection mineure. C'est une disqualification au stade de l'examen préalable. Le premier signe se verra dans les formulations standard mises à jour des marchés des Länder allemands, des ministères français et des grandes institutions européennes.

Les acheteurs privés subissent une pression d'achat transmise par cascade. Un SaaS français qui vend à un ministère soumis à SecNumCloud doit lui-même se positionner en conformité SecNumCloud, sinon il perd l'appel d'offres. Une fintech allemande sous DORA doit démontrer que ses sous-fournisseurs critiques (analytics, identité, signature électronique, observabilité) respectent des exigences équivalentes en matière de résilience opérationnelle. Cette pression descend. Une PME DACH qui se croyait isolée des considérations de souveraineté se retrouve à remplir des questionnaires de due diligence fournisseurs qu'elle n'avait pas à remplir il y a douze mois.

La question par défaut change. Jusqu'en 2025, la question par défaut dans un appel d'achat était « cet outil est-il fonctionnellement adapté, avec un DPA signé ? ». En 2026, elle est : « cet outil est-il fonctionnellement adapté, avec un DPA signé, et la chaîne hébergement + sous-traitants est-elle défendable face à une analyse d'impact Schrems II ? » Le troisième segment relevait jadis du spécialiste. Il fait désormais partie de la liste standard.

Une lecture lucide doit aussi nommer ce que le paquet ne change pas, car les cycles médiatiques autour de ces annonces peuvent pousser des acheteurs vers des projets de migration inutiles.

Le CLOUD Act demeure. Une société constituée aux États-Unis, même si elle stocke toutes les données à Francfort, reste soumise aux assignations extraterritoriales américaines. Le paquet ne change pas (et ne peut pas changer) le droit américain. Ce qu'il fait : il rend l'exposition au CLOUD Act un signal d'achat plus visible, particulièrement pour les acheteurs régulés. Le signal existait déjà ; le paquet en augmente le poids.

Schrems II exige toujours une analyse d'impact propre à l'éditeur. Aucune certification (y compris SecNumCloud ou BSI C5) ne décharge globalement un responsable du traitement de l'obligation Schrems II. L'analyse reste à faire par responsable, par flux de données. Le paquet devrait référencer ces cadres positivement, mais une référence n'est pas une exemption.

Européen ne signifie pas automatiquement compatible Schrems. Plusieurs éditeurs européens font tourner des workloads substantiels sur des hyperscalers américains, acheminent leurs e-mails via Mailgun ou Postmark, ou expédient leurs analytics via Segment. La propriété est un signal indépendant ; la chaîne de sous-traitants en est un autre ; l'hébergement physique un troisième. Ils doivent être évalués séparément, c'est précisément la pratique que ce répertoire essaie de rendre routinière.

La plupart des logiciels américains ne vont nulle part rapidement. La vitesse de remplacement pour des outils horizontaux profondément installés (Slack, Notion, Salesforce, GitHub) est freinée par les coûts de migration, la prolifération des intégrations et l'habitude des équipes. Le paquet accélère la direction du mouvement ; il ne réduit pas le calendrier. Attendez-vous à des migrations catégorie par catégorie, en commençant là où l'acheteur a le plus de levier (e-mail, signature électronique, gestion des mots de passe, stockage de fichiers) avant d'aborder les suites de collaboration profondément intégrées.

Pour un acheteur disposant de peu de temps, la lecture opérationnelle la plus utile est un audit en quatre questions, appliqué à chaque outil déjà présent dans le stack.

1. Qui est propriétaire de l'entité opérante ? Capital européen, siège européen avec financement américain, capital américain. C'est le signal de propriété : le plus simple à vérifier et celui qui détermine l'exposition de base au CLOUD Act.
2. Où résident les données au repos, dans quelle région, sur l'infrastructure de qui, et qui détient les clés ? Un outil « européen » dont le stockage primaire est us-east-1 n'est pas un outil hébergé en UE. Le datacenter compte plus que le drapeau de l'entreprise. Selon les critères émergents de « cloud souverain » de CADA, même une région UE ne devrait plus suffire à elle seule : la garde des clés de chiffrement hors du contrôle du fournisseur devient une partie du test.
3. Quels sous-traitants touchent aux données ? Lisez le document public des sous-traitants. Marquez chaque entrée à capitaux américains. Un éditeur avec deux sous-traitants américains transitoires et sans exposition de données au repos est dans une situation très différente d'un éditeur qui envoie des événements vers Segment et Mixpanel.
4. Que dit réellement le DPA public sur les transferts internationaux ? Les Clauses Contractuelles Types sont nécessaires mais ne suffisent plus. Mesures supplémentaires, région d'hébergement nommée, sous-traitants nommés et clause de droit d'audit : voilà ce que contient aujourd'hui un dossier d'achat défendable.

Appliquez cet audit aux dix principaux outils du stack. Ceux qui échouent à deux questions ou plus sont ceux pour lesquels planifier une migration au prochain renouvellement, pas forcément tous en même temps, mais avec un calendrier associé.

Le cadre que ce répertoire utilise, et que le paquet valide implicitement, est celui de la résilience comme spectre, non comme un état binaire. Un stack SaaS est rarement soit « souverain » soit « compromis ». Il est généralement une combinaison : outils à capitaux européens avec sous-traitants américains ; outils américains avec données résidant en Allemagne ; open source auto-hébergé ; SecNumCloud-qualifié pour les workloads régulés ; choix américains pragmatiques là où aucune alternative crédible n'existe encore.

Le travail d'un acheteur en 2026 n'est pas de chasser un maximum de souveraineté. C'est de rendre les arbitrages visibles, de les documenter et d'agir d'abord sur les remplacements à plus fort levier. Le Tech Sovereignty Package est le cadre qui affirme : ces arbitrages sont des préoccupations d'achat légitimes. Le travail de les faire reste à la charge de l'acheteur.

Parcourez nos fournisseurs cloud européens vérifiés, services qualifiés SecNumCloud, stockages cloud européens, messageries e-mail sécurisées, gestionnaires de mots de passe open source et VPN européens. Chaque fiche est annotée avec propriété, hébergement, chaîne de sous-traitants, exposition au CLOUD Act et date de la dernière vérification des divulgations publiques. C'est le format que les douze prochains mois récompenseront.