Ce que « souverain » veut dire

Pourquoi

La métropole qui veut déployer Signalements dans ses quarante communes envoie à Lyneko un cahier des charges. Une ligne, au milieu des exigences fonctionnelles, dit simplement : « L'hébergement devra être souverain. » Rien de plus.

Que faut-il répondre ? Les données de Signalements sont à Paris, chez Scaleway, une entreprise française. Est-ce suffisant ? Le code source est sur GitHub, les images de conteneur ont été publiées sur le registre de GitHub, l'équipe de Lyneko se connecte à Argo CD avec ses comptes Google. Est-ce un problème ? Et si la métropole voulait dire, en réalité, « qualifié SecNumCloud », ce que Scaleway n'est pas à la date de cette leçon ?

Le mot « souverain » est devenu un argument commercial que chaque fournisseur définit à sa manière : un hyperscaleur américain vend du « cloud souverain » hébergé en Europe, un fournisseur français vend du « cloud souverain » parce qu'il est français, une coentreprise vend du « cloud de confiance » sur une technologie américaine opérée par une société française. Tous ont en partie raison, parce qu'ils ne parlent pas de la même chose.

Sans définition partagée, trois choses arrivent :

• On répond à côté. L'équipe technique répond « les données sont en France », le client entendait « aucune entreprise soumise au droit américain ne doit pouvoir y accéder », et le malentendu éclate au moment de l'audit.
• On surprotège ou on sous-protège. Un projet sans enjeu paie le prix d'une offre qualifiée qu'il n'utilise pas ; un projet sensible part sur une offre qui ne couvre pas sa vraie menace.
• On ne peut pas justifier. Une décision prise sur un slogan ne résiste pas à la question d'un élu, d'un auditeur ou d'un journaliste.

Cette leçon remplace le slogan par une grille de questions vérifiables. Les leçons suivantes approfondissent chaque dimension : le droit (leçon 2), la qualification SecNumCloud (leçon 3), les textes qui l'imposent (leçon 4), les techniques qui réduisent la dépendance (leçon 5) et la décision elle-même (leçon 6).

Les concepts

Un mot, trois usages

Le mot circule dans trois registres qu'il faut savoir distinguer.

• Le registre politique : la souveraineté numérique désigne la capacité d'un État ou de l'Union européenne à décider de ses choix technologiques sans dépendre de puissances étrangères. C'est l'objet de stratégies nationales et européennes, de financements, de discours. Le registre est légitime, mais il ne dit rien d'un contrat précis.
• Le registre commercial : « cloud souverain » est une étiquette que n'importe quel fournisseur peut apposer sur une offre. Elle n'est pas protégée et ne garantit rien par elle-même.
• Le registre juridique et normatif : certains textes définissent des critères précis et vérifiables. En France, c'est le cas du référentiel SecNumCloud de l'ANSSI (leçon 3), que plusieurs textes rendent obligatoire pour certaines données (leçon 4). Au niveau européen, la Commission a publié un cadre d'évaluation pour ses propres achats (voir plus bas).

Quand un client écrit « souverain », la première question à lui poser est donc : dans quel registre ? Une exigence politique se discute, une exigence commerciale se négocie, une exigence normative se vérifie.

Quatre dimensions

Pour un service cloud, on peut décomposer la souveraineté en quatre dimensions. Chacune répond à une menace différente, et une offre peut être forte sur l'une et faible sur l'autre.

La Commission européenne a formalisé une grille plus fine pour ses propres achats. Son Cloud Sovereignty Framework, présenté en octobre 2025 dans un appel d'offres du système d'acquisition dynamique Cloud III, puis publié avec un guide de mise en œuvre une fois l'appel d'offres conclu, évalue les fournisseurs selon huit objectifs de souveraineté : stratégique, juridique et juridictionnel, données et IA, opérationnel, chaîne d'approvisionnement, technologique, sécurité et conformité, durabilité environnementale. Pour chaque objectif, il définit cinq niveaux, de SEAL-0 (« pas de souveraineté » : service sous contrôle exclusif de tiers non européens) à SEAL-4 (« souveraineté numérique complète » : contrôle entièrement européen, sans dépendance critique hors de l'Union). Le guide lui-même reconnaît que le niveau SEAL-4 n'est aujourd'hui pas atteignable en pratique, faute de chaîne d'approvisionnement européenne pour les puces et le matériel. Retenez l'idée plus que les noms : la souveraineté n'est pas binaire, elle se mesure par dimension et par niveau.

Localisation n'est pas souveraineté

La confusion la plus répandue consiste à croire qu'une donnée stockée en France est protégée par le droit français, et seulement par lui. La leçon 3 du cours sur le cloud l'a déjà signalé : une région est une localisation physique, pas une frontière juridique.

Le raisonnement est simple. Une loi s'applique à des personnes (physiques ou morales), pas seulement à des lieux. Si le fournisseur, ou la société qui le contrôle, est soumis au droit d'un pays tiers, une autorité de ce pays peut lui ordonner de produire des données qu'il détient ou contrôle, où qu'elles se trouvent. C'est exactement ce que prévoit, pour les États-Unis, le CLOUD Act de 2018, détaillé à la leçon 2. Le serveur peut être à Paris, à Francfort ou à Amsterdam : la question pertinente est qui le contrôle.

À l'inverse, une localisation hors de France n'est pas forcément un problème : une donnée stockée à Amsterdam chez un fournisseur européen reste dans l'Union, sous le même règlement général sur la protection des données (RGPD). La localisation compte pour d'autres raisons (latence, exigences contractuelles ou réglementaires de stockage en France, accès physique par les autorités du pays d'hébergement), mais elle ne règle pas la question juridique.

« Cloud de confiance » et offres hybrides

Entre le fournisseur européen indépendant et l'hyperscaleur américain, une troisième catégorie est apparue : une société de droit français, contrôlée par des actionnaires européens, qui exploite dans ses propres centres de données une technologie sous licence d'un hyperscaleur américain. L'idée est d'offrir les services d'un grand fournisseur (le catalogue de Google Cloud, Azure et Microsoft 365) tout en coupant le lien juridique et opérationnel avec la maison mère américaine.

Deux offres l'illustrent en France, à la date de cette leçon :

• S3NS est une société de droit français créée par Thales en partenariat avec Google Cloud. Lors de son lancement, en juin 2022, Thales l'a présentée comme une société de droit français contrôlée par le groupe ; Google Cloud y est partenaire technologique et, selon la presse spécialisée, actionnaire minoritaire. Son offre PREMI3NS, qui exploite la technologie de Google Cloud dans des centres de données en France, a obtenu la qualification SecNumCloud 3.2 en décembre 2025, d'après l'annonce de Thales, sur un périmètre qui couvre des services d'infrastructure, de plateforme et de conteneurs.
• Bleu est une coentreprise d'Orange et de Capgemini qui exploite les technologies Azure et Microsoft 365 sous licence. Au 5 octobre 2026, d'après les informations publiques que nous avons pu consulter, Bleu a franchi les premiers jalons du processus de qualification SecNumCloud (le jalon J0 en avril 2025, puis le jalon J1 en septembre 2025), mais nous n'avons pas trouvé trace d'une qualification obtenue. Vérifiez son statut dans le catalogue de l'ANSSI avant de vous y fier.

Ce modèle est discuté, et il faut savoir pourquoi. Ses défenseurs font valoir que la société d'exploitation n'est pas soumise au droit américain, que ses employés et ses accès sont en France, et que la qualification SecNumCloud, quand elle est obtenue, en atteste (leçon 3). Ses critiques soulignent que le logiciel, ses mises à jour et sa feuille de route restent décidés par l'éditeur américain : la dimension juridique est traitée, la dimension technique et stratégique beaucoup moins. Si l'éditeur cesse de fournir les mises à jour (par décision commerciale, ou parce qu'une autorité le lui interdit), l'exploitant peut-il maintenir le service ? La réponse dépend du contrat, et du temps que l'on accepte de tenir sans mises à jour.

Les dépendances stratégiques sont réelles

La dimension stratégique semble abstraite jusqu'au jour où elle ne l'est plus. Deux faits pour en mesurer la portée.

Le marché. Selon Synergy Research Group (étude publiée le 24 juillet 2025), Amazon, Microsoft et Google détiennent ensemble environ 70 % du marché européen du cloud, et la part des fournisseurs européens sur leur propre marché, tombée de 29 % en 2017 à 15 % en 2022, s'y maintient depuis. Les premiers fournisseurs européens, SAP et Deutsche Telekom, en détiennent chacun environ 2 %. Une organisation européenne qui choisit un fournisseur européen ne suit donc pas la pente du marché : elle fait un choix délibéré, qu'il faut pouvoir justifier.

L'interruption imposée. En février 2025, le président des États-Unis a pris des sanctions contre le procureur de la Cour pénale internationale. En mai 2025, l'agence Associated Press a rapporté, d'après des membres du personnel de la Cour, que Microsoft avait supprimé l'adresse électronique du procureur, qui s'était tourné vers un service de messagerie suisse. Microsoft a ensuite déclaré n'avoir ni interrompu ni suspendu ses services à la Cour elle-même, sans détailler les circonstances concernant le procureur. Quelle que soit la lecture que l'on en fait, l'épisode montre le mécanisme : un fournisseur soumis à un droit étranger applique les mesures de ce droit, y compris à des clients européens, et le client n'a pas son mot à dire.

Ces deux faits ne disent pas qu'il faut fuir les hyperscaleurs. Ils disent que la question « que se passe-t-il si le service s'arrête demain pour une raison qui ne dépend ni de nous ni du fournisseur ? » est une question d'architecture légitime, au même titre que la panne d'une zone.

Un modèle de menace, pas un slogan

La seule façon de sortir du débat idéologique est de poser un modèle de menace : qui voudrait accéder à quoi, par quel moyen, et avec quelles conséquences ? Le cours Modélisation des menaces traite la méthode en détail ; pour la souveraineté, quatre familles de menaces suffisent à structurer la réflexion.

Ce tableau fait apparaître deux idées que la suite du cours développe. D'abord, aucune mesure ne couvre toutes les menaces : un fournisseur français couvre la réquisition étrangère mais pas la captivité ; le chiffrement couvre la lecture des données mais pas l'interruption de service. Ensuite, les menaces n'ont pas toutes la même probabilité pour un projet donné : une application de signalement de nids-de-poule n'intéresse aucun service de renseignement, alors que le dossier médical d'un patient ou les plans d'un site sensible peuvent intéresser beaucoup de monde.

La proportionnalité

D'où le principe qui guide tout le cours : la souveraineté se dimensionne. Le RGPD le dit à sa manière, en demandant des mesures « appropriées » au risque (article 32). Les textes français qui imposent SecNumCloud le disent aussi, en ne l'imposant qu'à certaines données (leçon 4).

Pour Signalements, la question n'est pas « faut-il le meilleur niveau de souveraineté ? » mais « quel niveau pour quelles données, chez quel client ? ». Les signalements d'une mairie (« lampadaire en panne rue des Lilas ») n'ont pas la même sensibilité que ceux d'un groupement hospitalier, dont les photos peuvent montrer des patients dans un couloir. Le même logiciel peut donc justifier deux hébergements différents. La leçon 6 en fait une méthode.

Le paysage des fournisseurs européens

Il n'existe pas de classement objectif, et ce cours n'en fait pas. Voici ce que l'on peut vérifier, au 5 octobre 2026, pour les fournisseurs que l'on rencontre le plus souvent dans les appels d'offres français. Pour chacun, la seule source qui fait foi sur la qualification est le catalogue des produits et services qualifiés de l'ANSSI, mis à jour au moins chaque mois : une qualification porte sur une offre précise, pas sur une entreprise.

• OVHcloud, société française cotée, propose une offre de cloud privé et d'autres services qualifiés SecNumCloud, à côté de son cloud public non qualifié.
• 3DS Outscale, filiale de Dassault Systèmes, a fait de la qualification SecNumCloud le cœur de son offre d'infrastructure.
• Cloud Temple affiche des offres d'infrastructure et de plateforme qualifiées.
• Scaleway, filiale du groupe iliad, est entrée dans le processus de qualification SecNumCloud ; au 5 octobre 2026, sa propre page indique que la qualification est en cours et pas encore obtenue. Scaleway est certifiée HDS (hébergement de données de santé) et ISO/IEC 27001. En avril 2026, elle a été retenue par la Plateforme des données de santé pour héberger le système national des données de santé (la Banque des Territoires rapporte que sa « trajectoire » vers SecNumCloud a été jugée crédible), et par la Commission européenne comme l'un des quatre fournisseurs de son marché de cloud souverain de 180 millions d'euros.
• S3NS et Bleu, décrits plus haut.

Cette liste vieillira vite. Elle sert surtout à montrer la méthode : pour chaque fournisseur, on vérifie qui le contrôle, quelles offres sont qualifiées et sur quel périmètre, et quelles certifications il détient, dans les sources primaires.

En pratique

Le travail de cette leçon est une cartographie des dépendances de Signalements. C'est la première chose à produire avant toute discussion de souveraineté : on ne peut pas juger un hébergement sans savoir tout ce dont l'application dépend, et l'hébergeur principal n'est presque jamais la seule dépendance.

Étape 1 : lister ce qui touche aux données ou au service

Prenez l'architecture de Signalements telle qu'elle est à la fin du cours Le cloud : les fondamentaux, et ajoutez tout ce qui gravite autour : la chaîne de livraison, les outils de l'équipe, les services tiers. Pour chaque élément, notez qui le fournit, où il se trouve, et à quoi il a accès. Voici le résultat attendu :

Étape 2 : poser les quatre questions à chaque ligne

Pour chaque élément, posez les quatre questions de la grille, et notez la réponse et sa source. Un exemple pour trois lignes :

Étape 3 : classer et lire le résultat

Classez enfin chaque dépendance selon deux axes : touche-t-elle aux données des clients (les signalements, les photos, les comptes des agents), et son interruption arrête-t-elle le service pour les usagers ?

Le résultat attendu pour Signalements est instructif :

• Les données des clients ne vivent que chez Scaleway. GitHub et Google ne voient ni signalement ni photo. Pour la question juridique qui préoccupe la métropole, c'est le fournisseur d'hébergement qui compte, et lui seul.
• Le service en production ne dépend d'aucun fournisseur américain une fois déployé : si GitHub ou Google étaient inaccessibles, l'application continuerait de tourner. En revanche, l'équipe ne pourrait plus livrer (plus de pipeline) ni se connecter à Argo CD. C'est une dépendance opérationnelle réelle, à documenter et à couvrir par une procédure de secours (un compte d'administration local, un miroir du dépôt).
• Une dépendance passe facilement inaperçue : les images de conteneur publiées sur le registre de GitHub. Si le déploiement tire ses images de là, une interruption empêche de redéployer, voire de redémarrer un nœud. La migration vers le registre de Scaleway, prévue dans le fil rouge, supprime ce point.

Cette cartographie est la pièce maîtresse de la note de décision de la leçon 6. Gardez-la.

Sous le capot

Ce que « contrôle » veut dire pour une entreprise

La dimension juridique se ramène presque toujours à une question de contrôle au sens du droit des sociétés : qui peut imposer ses décisions à l'entreprise qui exploite le service ? Une société de droit français, dont les serveurs sont en France, mais détenue majoritairement par une société américaine, est en pratique sous l'autorité de sa maison mère. Le droit américain raisonne d'ailleurs en termes de données en « possession, garde ou contrôle » du fournisseur (leçon 2), notion qui peut englober les données détenues par une filiale contrôlée.

C'est pourquoi le référentiel SecNumCloud ne se contente pas de demander un siège en Europe : il encadre la détention du capital et des droits de vote par des entités non européennes, et exige que le prestataire ne puisse pas être contraint par un droit extra-européen. La leçon 3 détaille ces critères. Pour lire une offre, l'organigramme capitalistique compte autant que la fiche technique.

Ce que le fournisseur peut techniquement voir

La dimension technique, elle, se ramène à une question de clés. Le cours sur le cloud a montré que le stockage d'un fournisseur est généralement chiffré, mais avec des clés que le fournisseur gère. Ce chiffrement protège contre le vol d'un disque, pas contre le fournisseur lui-même : son logiciel déchiffre les données pour les servir, et un opérateur ou une autorité qui le contraint peut obtenir les données en clair.

Il existe un gradient, que la leçon 5 détaille : clés gérées par le fournisseur, clés fournies par le client mais utilisées par le fournisseur, clés conservées par le client dans un module matériel qu'il contrôle, chiffrement côté client avant tout envoi. Plus on monte, moins le fournisseur peut lire, mais plus on perd de services : une base de données managée doit pouvoir lire ses données pour les indexer et répondre aux requêtes. Il n'existe pas, à ce jour, de moyen pratique de faire tourner une base de données managée ordinaire sur des données qu'elle ne peut jamais déchiffrer.

Pourquoi la qualification change la nature de la question

Sans référentiel, la question « ce fournisseur est-il souverain ? » ne peut recevoir que des déclarations. Avec un référentiel comme SecNumCloud, elle devient une question vérifiable : un organisme d'évaluation indépendant a audité l'offre selon des critères publiés, l'ANSSI a délivré une qualification, elle figure dans un catalogue public avec sa date de validité. C'est ce qui permet à un acheteur public de l'exiger dans un marché, et à un auditeur de le contrôler. La leçon 3 montre aussi les limites de cette vérification.

Pièges courants

Confondre la nationalité du fournisseur et celle de ses sous-traitants. Un fournisseur français peut s'appuyer, pour une partie de son service (support de niveau 2, messagerie de notification, outil de ticket), sur des sous-traitants soumis à un autre droit. La liste des sous-traitants ultérieurs, que le RGPD l'oblige à communiquer (leçon 2), est la première chose à lire.

Oublier la chaîne de livraison. On analyse l'hébergement de la production, et l'on oublie que le code, les secrets de déploiement et les images transitent par une forge et un registre étrangers. L'exercice de cartographie de cette leçon sert précisément à ne rien oublier.

Prendre une annonce pour une qualification. « Engagé dans la qualification », « en cours de qualification », « conforme aux exigences de » : aucune de ces formules n'est une qualification. Seul le catalogue de l'ANSSI fait foi, et il précise le périmètre exact (quels services, quels centres de données).

Lire une qualification hors de son périmètre. Un fournisseur qualifié pour son offre de cloud privé ne l'est pas pour son cloud public, sauf mention contraire. Utiliser un service non qualifié d'un fournisseur qualifié ne donne pas le bénéfice de la qualification.

Dater ses informations. Statuts de qualification, recours devant les juridictions, textes en cours d'adoption : tout bouge. Une note de décision qui ne date pas ses sources ne peut pas être revue.

Croire qu'il faut tout souverainiser. Exiger le niveau maximal pour un projet sans enjeu coûte cher, réduit le choix des services et peut faire échouer le projet. La proportionnalité est aussi une exigence de sécurité : les moyens doivent aller là où sont les risques.

Sécurité

La souveraineté est souvent présentée comme une question politique, mais elle relève d'abord de la sécurité, au sens classique de la confidentialité, de l'intégrité et de la disponibilité :

• Confidentialité : qui peut lire les données, y compris en dehors de toute intrusion, par un moyen légal ? C'est la dimension juridique et technique.
• Disponibilité : le service peut-il être interrompu par une décision extérieure ? C'est la dimension stratégique, qu'aucun SLA ne couvre.
• Intégrité : qui peut modifier le logiciel déployé ? La chaîne d'approvisionnement (forge, registre, pipeline) est une dépendance de sécurité au même titre que l'hébergeur, comme le cours Chaîne d'approvisionnement logicielle le montre.

Deux réflexes de sécurité s'appliquent directement :

• Réduire le rayon d'impact des accès étrangers. Si l'équipe se connecte à ses outils par un fournisseur d'identité étranger, un compte de secours local, protégé et testé, garantit qu'une coupure n'empêche pas d'intervenir sur la production.
• Minimiser les données. La meilleure protection d'une donnée contre toute forme d'accès est de ne pas la collecter, ou de la supprimer quand elle ne sert plus. Pour Signalements, flouter les visages sur les photos à leur réception réduit la sensibilité de tout le bucket, quel que soit l'hébergeur.

En production

• La cartographie se maintient. Chaque nouvel outil (un service d'envoi de courriels, une plateforme d'observabilité, un assistant de code) ajoute une dépendance. Chez Lyneko, l'ajout d'un service tiers qui touche aux données d'un client passe par une revue, et la cartographie est mise à jour dans le même mouvement.
• On répond par écrit, avec des sources. À une exigence « souverain », la réponse attendue n'est pas « oui », mais un document court : l'interprétation retenue, les dimensions couvertes, les preuves (qualification, certification, contrat), les dépendances résiduelles et la façon dont elles sont traitées. La leçon 6 en donne la structure.
• On distingue la production et l'outillage. Pour la plupart des projets, l'exigence porte sur l'hébergement des données des usagers. L'outillage de l'équipe (forge, messagerie, bureautique) relève d'une autre décision, souvent moins contrainte, mais qui doit être consciente.
• On revoit la décision. Un fournisseur obtient une qualification, un autre est racheté, une décision d'adéquation est annulée : une note de décision indique la date de sa prochaine revue.

Exercices

1. Quel registre ? (niveau 200). Pour chacune des formulations suivantes, trouvées dans des cahiers des charges, dites dans quel registre elle se situe (politique, commercial, normatif) et quelle question vous poseriez au client pour la rendre vérifiable. (a) « Le prestataire privilégiera des solutions souveraines. » (b) « L'hébergement sera réalisé sur une offre qualifiée SecNumCloud. » (c) « Les données seront hébergées en France. » (d) « Le prestataire garantit qu'aucune autorité étrangère ne pourra accéder aux données. »

2. Compléter la cartographie (niveau 200). L'équipe de Signalements envisage trois ajouts : un service américain d'envoi de courriels pour notifier les agents, une plateforme d'observabilité SaaS qui recevrait les journaux de l'application, et un assistant de développement fondé sur un modèle de langage hébergé aux États-Unis, qui lirait le code. Ajoutez ces trois éléments à la cartographie, avec les quatre dimensions, et dites lesquels touchent aux données des clients.

3. Lire une offre hybride (niveau 300). Un fournisseur vous présente une offre « cloud de confiance » : société de droit français détenue à 100 % par deux groupes français, technologie d'un éditeur américain sous licence, centres de données en France, personnel d'exploitation en France, qualification SecNumCloud obtenue pour l'infrastructure, en cours pour les services de base de données. Pour la métropole, qui veut héberger Signalements avec sa base de données, quelles dimensions sont couvertes, lesquelles ne le sont pas, et quelles questions posez-vous ?

Récapitulatif

• « Souverain » s'emploie dans trois registres (politique, commercial, normatif) : seul le dernier se vérifie. Demandez toujours dans quel registre se situe une exigence.
• La souveraineté d'un service cloud se décompose en dimensions juridique, opérationnelle, technique et stratégique, chacune couvrant une menace différente ; le Cloud Sovereignty Framework de la Commission en compte huit, notées par niveau.
• La localisation ne règle pas la question juridique : une loi s'applique à des personnes, et ce qui compte est qui contrôle le fournisseur.
• Les offres hybrides (S3NS, Bleu) traitent la dimension juridique et opérationnelle par une société européenne exploitant une technologie américaine sous licence ; la dimension technique et stratégique reste à examiner. Au 5 octobre 2026, PREMI3NS de S3NS est qualifiée SecNumCloud, Bleu est en cours, Scaleway aussi.
• La souveraineté se dimensionne : un modèle de menace (réquisition, renseignement, interruption, captivité) et la sensibilité des données décident du niveau nécessaire.
• La première pièce d'une décision est la cartographie des dépendances, chaîne de livraison et outils de l'équipe compris.
• Une qualification porte sur une offre et un périmètre ; seul le catalogue de l'ANSSI fait foi, et toute information se date.

Pour aller plus loin

• Le guide de mise en œuvre du Cloud Sovereignty Framework de la Commission européenne, qui détaille les critères de chacun des huit objectifs et la manière dont ils ont été notés dans un vrai marché.
• Le catalogue des produits et services qualifiés de l'ANSSI : prenez l'habitude de le consulter vous-même plutôt que de vous fier aux listes publiées par des tiers.
• La leçon suivante, qui examine la dimension juridique en détail : ce que permettent réellement le CLOUD Act et la section 702 du FISA, et ce que le RGPD en dit.