Cloud souverain : les quatre niveaux du cadre européen expliqués aux acheteurs

Depuis quelques mois, les consultations publiques françaises parlent une langue nouvelle. Il n'y est plus seulement question de certification ou d'hébergement de données sensibles, mais de niveaux de souveraineté numérotés. Derrière ce vocabulaire se trouve un texte européen dont les acheteurs vont devoir maîtriser la mécanique avant de rédiger leur prochain cahier des charges.

L'intérêt de cette construction graduée est qu'elle met fin à une question mal posée. Pendant des années, le débat opposait deux camps : le cloud était souverain ou il ne l'était pas, selon des critères que chacun définissait à sa convenance. Un barème à plusieurs marches oblige à dire quelle exigence précise on achète, ce qu'elle coûte et ce qu'elle protège réellement.

Cet article détaille les marches de ce barème, précise ce que chacune impose au fournisseur, signale le point que le texte européen laisse volontairement ouvert et propose une grille de lecture pour évaluer une candidature. Il se termine sur le premier dossier français où ces questions se posent concrètement.

Un cadre gradué, pensé d'abord pour l'achat public

CIO Online décrit un Cloud and AI Development Act qui installe un cadre de souveraineté à quatre niveaux pour les services cloud destinés au secteur public, assorti d'une certification à l'échelle de l'Union. Le point de départ est donc l'achat public, non l'ensemble du marché. Cette précision compte : une entreprise privée ne sera pas contrainte de la même manière, mais elle héritera des offres façonnées par cette demande publique.

La gradation change la nature de la discussion commerciale. Un fournisseur ne répond plus à une question binaire, il se positionne sur une marche et doit tenir les exigences correspondantes. Un acheteur, symétriquement, ne peut plus se contenter d'exiger de la souveraineté en général : il doit désigner le niveau qui correspond à la sensibilité réelle de ses traitements, et assumer l'écart de prix qui en découle.

Le niveau 2, seuil d'entrée du cadre européen

Le premier palier réellement exigeant est le niveau 2. CIO Online en résume trois composantes : la localisation du personnel dans l'Union, le maintien des données sur le continent et la documentation des composants logiciels, autrement dit la nomenclature des briques qui constituent le service. Trois exigences de nature différente, qui protègent contre trois risques différents.

La localisation des données répond au risque de transfert, celle du personnel au risque d'accès distant par des équipes soumises à un autre droit. La troisième exigence est la plus sous estimée : documenter les composants logiciels revient à rendre visible ce qui compose réellement le service, y compris les bibliothèques tierces et les dépendances héritées que personne n'inventorie spontanément.

Pour un acheteur, cette nomenclature est un outil de contrôle bien plus qu'une formalité. Elle permet de vérifier après coup qu'une brique critique n'a pas été remplacée par une autre, de suivre l'exposition à une vulnérabilité publiée et d'objecter lors d'un changement de sous traitant. Un service dont on ne connaît pas les composants ne peut pas être surveillé sérieusement, quel que soit le lieu de ses serveurs.

Niveaux 3 et 4 : nationalité des équipes et conditions cumulatives

Aux niveaux supérieurs, l'exigence se déplace des lieux vers les personnes et vers le droit. CIO Online indique que les niveaux 3 et 4 supposent un personnel d'exploitation composé de citoyens de l'Union et des habilitations pour le traitement d'informations classifiées. On quitte la logique de la localisation pour entrer dans celle du contrôle des accès humains, qui suppose des processus de recrutement et d'habilitation lourds.

S'y ajoutent, selon la même source, six conditions cumulatives portant notamment sur le risque de législation extraterritoriale et sur l'impossibilité, pour un pays tiers, d'interrompre le service ou d'accéder aux données. Le mot important est cumulatives : il ne s'agit pas d'un score global où une bonne note compenserait une faiblesse. Une seule condition non tenue fait tomber le niveau entier.

L'exigence d'impossibilité d'interruption mérite une attention particulière, parce qu'elle vise un scénario que les contrats classiques ignorent. Il ne s'agit pas d'un incident technique ni d'une faillite du fournisseur, mais d'une décision politique étrangère qui couperait un service en fonctionnement. Répondre à cette exigence suppose une continuité démontrée, avec des moyens propres, et non une clause de bonne volonté.

Le point que le cadre européen ne tranche pas : le capital du fournisseur

C'est la différence la plus commentée et la plus mal comprise. CIO Online relève que le cadre européen n'impose pas le contrôle capitalistique européen du fournisseur, là où le référentiel français en fait une condition. Un service opéré par une filiale européenne d'un groupe non européen n'est donc pas exclu par principe du barème communautaire.

Ce choix déplace le débat du terrain de l'actionnariat vers celui de la démonstration. La question n'est plus qui possède le fournisseur, mais si l'architecture, la gouvernance des accès et les engagements juridiques rendent effectivement impossible une injonction étrangère. C'est un critère plus difficile à vérifier, mais aussi plus proche du risque réel, puisqu'un capital européen ne garantit pas à lui seul l'absence de dépendance technique.

Pour un acheteur français, la conséquence pratique est qu'il devra articuler deux référentiels dont les conditions ne se recouvrent pas. Une offre peut satisfaire un niveau européen élevé sans satisfaire le référentiel national, et l'inverse est possible. Le cahier des charges doit donc désigner explicitement le régime exigé, sous peine de recevoir des candidatures incomparables entre elles.

Lire une candidature quand la preuve incombe au prestataire

Le point commun des deux régimes, souligne CIO Online, est que la charge de la preuve d'immunité aux lois extraterritoriales pèse sur le prestataire non européen. Cette règle de répartition est décisive pour l'analyse d'une offre : ce n'est pas à l'acheteur de démontrer un risque, c'est au candidat d'établir qu'il est écarté. Une réponse qui se contente d'affirmer sa conformité ne répond donc pas à la question posée.

Cette répartition a un effet secondaire utile pour l'acheteur : elle rend l'absence de réponse aussi informative que la réponse elle-même. Un candidat qui traite la question en une phrase générale, ou qui renvoie à une politique de groupe sans décrire le mécanisme applicable au service vendu, a déjà répondu sur le fond. L'analyse des candidatures gagne à consigner ces silences plutôt qu'à les combler par des hypothèses favorables.

Concrètement, une démonstration recevable décrit une architecture, nomme les entités juridiques concernées, précise qui détient les clés de chiffrement et les droits d'administration, et documente ce qui se passe en cas d'injonction. Une déclaration, à l'inverse, reprend le vocabulaire du texte sans jamais descendre au niveau des mécanismes. La distinction est simple à opérer une fois qu'on la cherche.

Suivre ces dossiers suppose de lire beaucoup de documents publics à mesure qu'ils paraissent, avis de marché, référentiels, avis techniques et publications sectorielles. NewsCore (www.newscore.fr) couvre en continu ces sources dans plusieurs langues, trie le flux par intelligence artificielle et relie chaque signalement au document d'origine, ce qui met une pièce de consultation sous les yeux de l'équipe concernée le jour de sa parution.

Un niveau de souveraineté n'est pas une promesse commerciale : c'est une liste de conditions dont chacune se vérifie séparément.

Un premier cas d'application déjà engagé

Ces exigences ne restent pas théoriques longtemps. Solutions Numériques rapporte que la Plateforme des données de santé quitte Microsoft Azure pour une infrastructure qualifiée SecNumCloud située dans l'Union européenne, avec un cahier des charges publié le 10 février 2026 et une copie complète de la base visée pour la fin 2026. Le dossier sert de banc d'essai grandeur nature aux questions décrites plus haut.

Le montage retenu, un marché interministériel, en fait un précédent contractuel dont les clauses de réversibilité auront valeur de modèle pour les acheteurs publics suivants. Ce qui se négocie sur ce dossier en matière de conditions de sortie, de localisation du support et de propriété des sauvegardes fixera de fait le niveau d'exigence attendu ailleurs, bien au delà du secteur de la santé.

Les travaux de l'Observatoire de l'Intelligence Économique sur les dépendances au cloud non européen convergent sur un point souvent négligé : l'exposition ne se concentre pas dans le contrat principal, elle se loge dans les services annexes, sauvegarde, supervision, outils d'administration, rarement inventoriés au moment de la décision. C'est exactement ce que la documentation des composants logiciels du niveau 2 oblige à mettre sur la table.

Questions fréquentes

Quelle différence entre le cadre européen et le référentiel français ?

La principale porte sur l'actionnariat. Selon CIO Online, le cadre européen à quatre niveaux n'impose pas le contrôle capitalistique européen du fournisseur, alors que le référentiel français en fait une condition. Les deux régimes se rejoignent en revanche sur la charge de la preuve : c'est au prestataire non européen d'établir son immunité aux lois extraterritoriales, et non à l'acheteur de démontrer l'existence d'un risque.

Quel niveau viser pour un traitement donné ?

Le choix se fait à partir de la sensibilité réelle des données et du scénario que l'on veut écarter. Le niveau 2 traite le risque de transfert et d'accès distant. Les niveaux 3 et 4 traitent le risque d'injonction étrangère et d'interruption politique du service, au prix d'exigences de nationalité et d'habilitation coûteuses. Viser trop haut renchérit inutilement le marché et réduit le nombre de candidats capables de répondre.

Comment vérifier qu'un fournisseur tient réellement le niveau annoncé ?

En lisant la démonstration plutôt que la déclaration. Une réponse solide nomme les entités juridiques, décrit qui détient les clés et les droits d'administration, fournit la nomenclature des composants logiciels et explique le comportement du service en cas d'injonction. Les conditions des niveaux supérieurs étant cumulatives, il suffit qu'un seul de ces éléments manque pour que le niveau annoncé ne soit pas tenu.