« Cloud souverain ». Deux mots qu’on prononce avec gravité en comité, et qui ne veulent rien dire tant qu’on ne les a pas ouverts. La plupart des dirigeants qui les emploient croient acheter une couleur de drapeau. Ils achètent un contrat, soumis à un droit, opéré par quelqu’un. Le reste est de l’habillage.
Posons les mots. Sans charger personne, et sans théâtre.
Ce que le mot désigne, avant tout
Le mot « cloud » ne vient pas d’une métaphore poétique. Il vient d’un dessin. Depuis les années 1970-80, les ingénieurs réseau représentent par un petit nuage la partie de l’infrastructure qu’ils ne contrôlent pas : d’abord le réseau étendu de l’opérateur télécom, le WAN, puis Internet tout entier. Une convention graphique, rien d’autre. Ce que tu maîtrises, tu le dessines en boîtes et en câbles. Ce que tu ne maîtrises pas, tu le dessines en nuage. Le terme a glissé du schéma vers le marché, mais l’idée d’origine reste juste : le cloud, c’est la part de l’informatique qui échappe à ton contrôle direct.
D’où une série d’a priori à casser. iCloud n’est pas du cloud computing : c’est un service de synchronisation de fichiers entre les appareils Apple. Google Drive non plus : c’est du stockage en ligne. « Tout ce qui n’est pas dans nos datacenters » n’est pas une définition. « Hébergé en France » non plus. Ces raccourcis confondent un usage grand public ou une localisation avec un modèle de fourniture précis.
Ce modèle, le NIST l’a fixé en 2011, dans la publication SP 800-145, et il sert de référence mondiale depuis. Cinq critères cumulatifs définissent le cloud computing : le self-service à la demande (le client provisionne ses ressources seul, sans intervention humaine du fournisseur), l’accès réseau large bande (les ressources sont disponibles sur le réseau via des mécanismes standards), la mutualisation des ressources (un même parc physique sert plusieurs clients, qui ignorent l’emplacement exact de leurs données), l’élasticité rapide (la capacité monte et descend en quasi-temps réel), et le service mesuré (l’usage est compté et facturé à la consommation). Un service qui ne coche pas ces cinq cases n’est pas du cloud au sens strict : c’est de l’hébergement dédié, ou de l’infogérance.
Deloitte résume le basculement d’une formule : le cloud, c’est la transformation de l’informatique en service public, sur le modèle de l’électricité. Tu ne produis pas ton courant, tu le tires du réseau et tu paies ce que ton compteur relève. Le cloud applique cette logique au calcul et au stockage. La perspective est utile à garder en tête : ce que tu achètes, ce n’est pas une machine, c’est un raccordement.
Un cloud, ce n’est pas un lieu, c’est un contrat
On imagine le cloud comme un endroit, un nuage, quelque part au-dessus. C’est l’inverse d’un endroit. De la capacité informatique louée à la demande, facturée à l’usage, administrée par un tiers. Trois étages, du plus brut au plus fini. L’infrastructure (IaaS) : vous louez des machines et du stockage. La plateforme (PaaS) : vous louez de quoi faire tourner vos applications sans gérer les machines. Le logiciel (SaaS) : vous louez l’application finie, votre messagerie, votre CRM.
À chaque étage, vous déléguez davantage. À chaque étage, quelqu’un d’autre tient les clés de vos données. La question utile n’est pas « où sont mes données ». C’est « qui peut y accéder, et sous quel droit ».
Ce que « cloud » recouvre quand on dit OVH et AWS
La grille Deloitte donne un repère simple. Acheter du cloud, ce n’est pas acheter une machine, c’est acheter un raccordement. Vous ne possédez pas la centrale, vous branchez une prise et vous tirez le courant dont vous avez besoin. La facture suit le compteur : vous payez ce que votre usage relève, ni plus ni moins. La question utile vient juste après. Tout ce que le marché range sous le mot « cloud » coche-t-il vraiment les cinq cases de la définition NIST, ou s’agit-il parfois d’autre chose qu’on a rebaptisé pour suivre la mode ?
AWS répond à la question de la façon la plus nette. Lancé en 2006, le service a bâti une infrastructure mondiale qui répond aux cinq critères point par point. Self-service total : une console, des API, du Terraform, vous provisionnez sans parler à personne. Accès réseau universel : la ressource se consomme depuis n’importe quel terminal connecté. Mutualisation à l’échelle planétaire : des dizaines de régions, des millions de clients sur un socle partagé. Élasticité qui tient à la milliseconde : vous montez et vous descendez en charge sans préavis. Facturation au tick d’horloge : le compteur relève la seconde, la requête, le gigaoctet transféré. Au-dessus de ce socle, des centaines de services managés, tous interopérables, transforment l’informatique en utilité aussi transparente que le courant du réseau. C’est l’industrialisation du modèle Deloitte portée à grande échelle.
OVH, devenu OVHcloud en 2021, raconte une histoire différente. La société naît en 1999 comme hébergeur de serveurs dédiés, et grandit en vendant de la puissance brute au meilleur prix du marché. Le modèle fonctionne sur des serveurs dédiés, du mutualisé, du VPS : on loue une machine ou une part de machine, on la garde, on paie un loyer. Quand le marché bascule vers le modèle du raccordement élastique, l’entreprise colle le mot « cloud » sur son catalogue existant.
Or une partie de ce catalogue ne coche pas les cinq critères. Un serveur dédié n’a pas d’élasticité : c’est une machine fixe qu’on loue au mois, pas une ressource qui enfle et dégonfle à la demande. Certains VPS ne sont pas facturés à l’usage en temps réel mais au forfait. Certains services n’offrent pas le self-service complet qui définit le modèle. Ce n’est pas un jugement de valeur, c’est la définition NIST appliquée ligne à ligne. Une bonne partie de ces offres relève de l’hébergement, pas du cloud au sens strict.
Le changement de nom en OVHcloud en est le reflet commercial : on colmate le mot « cloud » sur une offre hétérogène pour rester dans la conversation du moment. OVH demeure un acteur important du marché de l’hébergement low-cost à grande échelle, et ce marché a sa propre légitimité. Mais l’amalgame entre cet hébergement et le cloud industrialisé fausse la lecture, parce qu’il met sur le même plan deux produits qui ne fonctionnent pas selon la même logique.
Cette différence n’a rien d’accidentel : elle reflète deux contextes industriels qui n’avaient pas les mêmes ressources. AWS se construit dans un pays de trois cent trente millions d’habitants, sur un marché intérieur homogène où une offre déployée une fois s’adresse d’emblée à une base de clients immense. Le capital de risque y coule sans limite, prêt à financer des années de pertes pour bâtir une infrastructure planétaire. Et l’État fédéral joue le rôle de premier client de référence, des contrats du Pentagone à ceux de la CIA, ce qui garantit un débouché massif et une caution de crédibilité. OVH grandit dans un environnement où aucune de ces trois conditions n’existe : un marché fragmenté en langues et en droits nationaux, un capital de risque rare et frileux, des commandes publiques qui ne se tournent pas spontanément vers un acteur local naissant. Ce n’est pas une affaire de talent ni d’ambition, c’est une affaire de moyens structurels. On ne bâtit pas la même chose avec les mêmes mains quand le sol sous les pieds n’est pas le même.
Cette inégalité de départ est elle-même une dimension de la souveraineté numérique, et la plus souvent oubliée. Quand on parle de cloud souverain en France ou en Europe, les options disponibles sont bornées par ce que ce contexte industriel a permis de construire. Un pays qui ne possède pas d’hyperscaler propre ne peut pas tenir la même conversation sur la souveraineté qu’un pays qui en possède un : il lui manque la brique de base. Voilà pourquoi opposer OVH et AWS pour en tirer des conclusions de souveraineté produit des raisonnements faussés. Les deux acteurs ne poussent pas dans le même sol. Les questions de dépendance, de portabilité et de droit applicable ne se posent pas dans les mêmes termes selon qu’on regarde un hébergeur né d’une contrainte budgétaire ou une utilité industrielle née d’un projet de puissance, adossé à un capital, à un marché et à un État qui en voulaient une.
La conséquence se voit dès qu’on compare. Quand on oppose OVH et AWS sous l’angle de la « souveraineté cloud », on compare souvent deux objets différents. Les questions de réversibilité, de dépendance et de droit applicable ne se posent pas dans les mêmes termes selon qu’on loue un serveur dédié ou qu’on souscrit un raccordement élastique. Sur un serveur dédié, la réversibilité tient surtout à la portabilité de vos données et de votre configuration. Sur un raccordement élastique, elle dépend de votre degré d’adhérence à des services managés propriétaires, ce qui est un tout autre problème.
Il faut commencer par savoir de quoi on parle avant de poser la question. Nommer correctement l’objet, hébergement ou cloud, n’est pas un détail de vocabulaire : c’est la condition pour poser la bonne question de souveraineté, celle qui correspond au produit qu’on a réellement entre les mains.
La vraie question n’est pas le drapeau, c’est la loi
Voilà le point que le marketing contourne. Un service peut afficher un drapeau français, des serveurs en France, une équipe à Paris, et rester exposé au droit d’un autre pays. Le CLOUD Act américain, voté en 2018, autorise les autorités des États-Unis à exiger les données détenues par une entreprise relevant de leur juridiction, où que ces données soient physiquement stockées. La localisation ne protège pas. Le rattachement juridique de l’opérateur, oui.
Un cloud souverain au sens fort, c’est un service qu’aucune loi étrangère ne peut atteindre. Pas un logo. Une propriété qui se vérifie : sous quel droit tombe l’opérateur, qui peut le contraindre, et ce qu’il advient le jour où on lui coupe l’accès.
Le seul marqueur qui tienne
En France, un seul repère fait foi. La qualification SecNumCloud, délivrée par l’ANSSI. La CNIL le dit sans détour : c’est à ce jour le seul marqueur qu’elle reconnaisse pour qualifier un cloud de souverain, parce qu’il vise précisément l’imperméabilité aux lois extraterritoriales. Une qualification, pas une certification : un visa de sécurité, adossé à la doctrine d’État « Cloud au centre », puis à la loi SREN, dont l’article 31 impose aux projets cloud de l’État un service immunisé contre ces lois.
La qualification reste le marqueur que la CNIL reconnaît, mais elle ne garantit pas la souveraineté à elle seule : elle en est la condition nécessaire, pas la condition suffisante. Deux raisons. D’abord, le périmètre qualifié peut ne pas couvrir l’ensemble des services réellement utilisés : une offre peut être qualifiée sur sa couche infrastructure (IaaS) sans l’être sur sa couche plateforme (PaaS), et une organisation qui consomme les deux ne couvre alors qu’une partie de son usage. Ensuite, la qualification ne préjuge ni de la qualité opérationnelle au quotidien ni de la réversibilité effective, qui ne se vérifie qu’à l’épreuve d’une sortie réelle. AWS dispose d’une infrastructure en France, sans qualification SecNumCloud à ce jour sur son offre standard : la preuve que la localisation seule ne suffit pas, et que la qualification est précisément ce que la présence physique sur le territoire ne garantit jamais.
L’écosystème se structure vite, et il avance par des chemins qui surprennent. Bleu, porté par Capgemini et Orange, vise la qualification en encapsulant les technologies Microsoft Azure, isolées de l’infrastructure mondiale du groupe. S3NS, coentreprise de Thales et Google, a décroché la sienne en décembre 2025, première à couvrir infrastructure et plateforme d’un seul tenant. Des offres bâties sur la technologie des géants qu’on disait vouloir éviter, refermées pour répondre au droit. Le réel est plus retors que les tribunes. En mars 2026, l’ANSSI et son homologue allemande ont publié des critères communs de souveraineté, signe que l’échelon européen cherche enfin un socle, après des années de blocage sur le schéma EUCS.
Structurellement, S3NS et Bleu répondent à une même équation. Ce sont des coentreprises entre un acteur français et un hyperscaler américain : Capgemini et Orange face à Microsoft Azure pour Bleu, Thales face à Google Cloud pour S3NS. Leur rôle tient en une phrase : opérer une instance isolée et qualifiée SecNumCloud du stack de leur partenaire américain. L’enveloppe est française, le périmètre est étanche, mais le code, les algorithmes et les services restent ceux de Microsoft et de Google.
De là vient la tension centrale. Répondre à SecNumCloud résout le problème légal : les données ne transitent pas hors du périmètre qualifié, et le droit français s’applique sans interférence d’une loi étrangère. La dépendance technologique et industrielle, elle, reste entière. Si Microsoft ou Google arrête la technologie sous-jacente, ferme le partenariat ou change ses conditions, la souveraineté légale ne protège pas la continuité opérationnelle. Ce n’est pas un défaut de conception de ces offres : c’est une tension de structure entre deux lectures du mot « souveraineté » qu’on a tendance à confondre.
La question posée au dirigeant se formule alors avec précision. La souveraineté légale et réglementaire, SecNumCloud et imperméabilité aux lois extraterritoriales, répond à une catégorie de risque bien réelle. La souveraineté industrielle, maîtrise de la stack et possibilité de changer de fournisseur sans tout réécrire, répond à une autre catégorie, tout aussi réelle. Les deux ne se substituent pas l’une à l’autre. Un contrat SecNumCloud réduit l’exposition juridique : il ne garantit ni la réversibilité ni l’indépendance technologique. Savoir laquelle des deux on achète, et laquelle il reste à construire, voilà la décision.
Comment on y répond aujourd’hui
Le dirigeant n’a pas à devenir juriste ni ingénieur. Il a besoin de poser quatre questions, et d’exiger des réponses écrites. Sous quel droit tombe le contrat. Quelles données partent, et où. Le service est-il qualifié, et pour quel périmètre exact. Que se passe-t-il si le fournisseur disparaît ou se voit couper, ce qu’on appelle la réversibilité.
La souveraineté n’est pas une couleur de logo ni la nationalité d’un actionnaire. C’est un faisceau de propriétés qu’on vérifie ligne à ligne. Tant qu’on parle drapeau, on parle communication. Le jour où on parle droit applicable, qualification et réversibilité, on parle enfin du sujet.
Sources
- ANSSI, qualification SecNumCloud et doctrine « Cloud au centre », cyber.gouv.fr
- CNIL, entretien sur le cloud souverain, Le Journal des Entreprises, mai 2026
- Observatoire SecNumCloud, CyberTaskForce, décembre 2025
- OVHcloud, historique et résultats de l’exercice 2025
- CLOUD Act (États-Unis, 2018) ; loi SREN, article 31
- Deloitte Insights, cloud computing perspectives