Les huit critères SOV : réflexions sur la souveraineté cloud
« Souveraineté cloud » est employé depuis longtemps de manière vague. Le Cloud Sovereignty Framework (EU CSF) de la Commission européenne donne au terme une structure : huit objectifs de souveraineté, désignés SOV-1 à SOV-8. L'Office fédéral allemand de la sécurité de l'information (BSI) en a depuis transformé six en un catalogue de critères vérifiables — les Criteria enabling Cloud Computing Autonomy (C3A) — qui présuppose la conformité C5 et laisse les deux domaines restants à d'autres référentiels.
Ce qui suit n'est pas un résumé de ce catalogue. C'est un parcours à travers les huit critères eux-mêmes — ce que chacun exige réellement — avec une réflexion sur la façon dont chacun se lit pour une plateforme comme openEduSuite : une infrastructure open source auto-hébergée, exploitée par l'établissement qui l'utilise. Poser les critères à un fournisseur, c'est de l'achat public ; se les poser à soi-même, c'est plus intéressant.
| # | Domaine | Question centrale |
|---|---|---|
| SOV-1 | Souveraineté stratégique | Qui contrôle les décisions stratégiques du fournisseur ? |
| SOV-2 | Souveraineté juridique et juridictionnelle | Sous quel droit le service opère-t-il effectivement ? |
| SOV-3 | Souveraineté des données et de l'IA | Qui détient les clés, et où résident réellement les données ? |
| SOV-4 | Souveraineté opérationnelle | Le service peut-il fonctionner sans ses artères non européennes ? |
| SOV-5 | Souveraineté de la chaîne d'approvisionnement | Savons-nous de quoi le service est fait ? |
| SOV-6 | Souveraineté technologique | Pouvons-nous construire, corriger et modifier le système nous-mêmes ? |
| SOV-7 | Souveraineté sécurité et conformité | Atteint-il la base de sécurité reconnue ? |
| SOV-8 | Durabilité environnementale | Peut-il fonctionner ainsi pendant des décennies ? |
SOV-1 — Souveraineté stratégique
Le premier critère demande si le fournisseur est établi dans l'UE et effectivement contrôlé depuis celle-ci : structure actionnariale, gouvernance et décisions stratégiques doivent se situer là où les clients européens peuvent, en dernier ressort, les influencer. Les C3A opérationnalisent cela par des exigences sur le siège social, le contrôle et l'annonce préalable des changements de propriétaire.
Réflexion. Pour une plateforme auto-hébergée, SOV-1 s'inverse : l'établissement est le fournisseur. Le critère ne disparaît pas — il devient une question de gouvernance. Qui décide de la feuille de route de la plateforme ? Quelles priorités la pilotent ? Un projet open source avec un dépôt public et une communauté de contributeurs rend ce contrôle lisible d'une façon qu'une hiérarchie d'entreprise ne peut pas ; mais cela signifie aussi que l'établissement doit réellement exercer le contrôle qu'il détient. La souveraineté qu'on n'use pas n'est pas une souveraineté.
SOV-2 — Souveraineté juridique et juridictionnelle
Le deuxième critère demande sous quel droit le service opère effectivement. Le test pratique est l'exposition extraterritoriale : un fournisseur soumis à un régime juridique non européen peut être contraint de remettre des données, quel que soit l'emplacement des serveurs. Les C3A exigent une évaluation annuelle et structurée de cette exposition, ainsi que des droits d'audit pour les autorités nationales — et, pour le cas de défense constitutionnel, la capacité de remettre l'exploitation aux autorités fédérales, matériel et personnel compris.
Réflexion. C'est le domaine où l'auto-hébergement est le plus fort : une infrastructure exploitée par une université allemande sous droit allemand et européen n'a pas de société mère étrangère par laquelle des obligations pourraient arriver. Mais la réflexion ne doit pas s'arrêter à la satisfaction. Les données elles-mêmes sont indifférentes à la juridiction — ce qui compte, c'est chaque chemin qui y mène. Fédération d'identité (DFN-AAI), contrats de support, services de supervision, même un sous-traitant oublié dans une politique de confidentialité : chacun est une petite ouverture. La souveraineté juridictionnelle est moins un état qu'une discipline de maintenir ces chemins courts.
SOV-3 — Souveraineté des données et de l'IA
Le troisième critère demande si les clients conservent un contrôle technique sur leurs données : lieux de stockage et de traitement traçables, clés de chiffrement détenues hors de l'environnement du fournisseur, intégration de fournisseurs d'identité externes via des standards ouverts, et chiffrement côté client lorsque nécessaire. Le « IA » du nom du domaine n'est pas décoratif — l'entraînement et l'inférence sur des données institutionnelles posent la même question : qui décide de ce qui en est fait ?
Réflexion. openEduSuite y répond structurellement. Les données ne quittent jamais le stockage de l'établissement ; les clés résident dans sa propre gestion de secrets ; le fournisseur d'identité (Keycloak, fédéré via DFN-AAI) appartient à l'établissement. Il n'y a aucune négociation sur l'export ou le sous-traitement parce qu'il n'y a pas de contrepartie. La réserve honnête : la traçabilité est un travail. Savoir où chaque service dépose son état — volumes MariaDB, compartiments de stockage objet, sauvegardes — est un exercice de cartographie continu, et le critère exige silencieusement que la carte reste à jour.
SOV-4 — Souveraineté opérationnelle
Le quatrième critère est celui que les C3A rendent le plus concret : le service doit être exploitable au sein de l'UE — par du personnel résidant dans l'UE, avec un SOC et une connectivité dans l'UE — et, selon le critère SOV-4-09-C, il doit survivre à une déconnexion des infrastructures non européennes sans perte de disponibilité, d'intégrité, d'authenticité ou de confidentialité, testée au moins une fois par an.
Réflexion. Une plateforme auto-hébergée ne dépend pas d'un cloud d'exploitation étranger, donc le test de déconnexion littéral est trivial. La traduction significative du critère est l'amont : la pile continue de tirer des images de conteneurs, des correctifs de sécurité et des versions amont d'un écosystème mondial. La déconnexion, pour l'open source, signifie pouvoir fonctionner — de manière sûre — sur ce qui est déjà sur disque, pendant une durée prolongée. C'est un test plus difficile que n'importe quel audit de fournisseur, et c'est là que les pratiques comptent plus que les déclarations : images miroirs, dépendances vendues, procédure de gel et d'exploitation documentée. La réponse honnête est qu'openEduSuite pourrait réussir aujourd'hui une version bornée de ce test, et ne devrait pas revendiquer la version illimitée.
SOV-5 — Souveraineté de la chaîne d'approvisionnement
Le cinquième critère demande si l'exploitant sait de quoi le service est fait : composants logiciels et matériels, pays d'origine, idéalement documentés sous forme de nomenclature logicielle (SBOM), avec des stratégies d'atténuation pour les dépendances critiques.
Réflexion. Ici, le modèle open source n'est pas automatiquement supérieur — il est simplement auditable. La chaîne d'approvisionnement d'une plateforme propriétaire est une question de contrat ; celle d'une plateforme ouverte est un fichier qu'on peut lire. Le build Nix d'openEduSuite rend le graphe de dépendances déterministe et inspectable par construction — l'essentiel du chemin vers une SBOM. La réflexion qui reste porte sur la concentration : une grande partie du monde open source converge vers un petit nombre de projets amont et de registries. La transparence sur les dépendances n'est pas encore l'indépendance vis-à-vis d'elles — mais c'en est la condition préalable.
SOV-6 — Souveraineté technologique
Le sixième critère demande si l'exploitant peut construire, corriger et faire évoluer le système de manière indépendante : les C3A exigent des sauvegardes du code source et de la documentation hébergées dans l'UE, maintenues à jour à 24 heures, avec une capacité de correctifs indépendante en cas d'urgence.
Réflexion. C'est le domaine où l'open source cesse d'être un argument pour devenir un fait. Le code source n'est pas seulement disponible ; le système de build qui le transforme en plateforme en fonctionnement fait partie du dépôt. Un correctif de sécurité n'exige pas le cycle de publication d'un fournisseur — il exige un mainteneur et un pipeline, et les deux existent. L'exigence de sauvegarde à 24 heures du critère se lit presque ironiquement de ce côté-ci : la partie difficile n'est pas de conserver le code, mais de conserver le savoir — les runbooks, les décisions d'architecture, les raisons derrière les choix de configuration. La souveraineté technologique s'érode en silence lorsque la personne qui comprenait le système s'en va.
SOV-7 — Souveraineté sécurité et conformité
Le septième critère demande si le service répond aux exigences de sécurité européennes reconnues — cadres de certification tels que NIS2, DORA et l'émergent EUCS. Les C3A ne couvrent délibérément pas ce domaine : il est déjà servi par les instruments établis du BSI, au premier rang desquels C5:2026 et IT-Grundschutz.
Réflexion. L'exclusion est un rappel utile : souveraineté et sécurité sont des axes différents. Un service souverain mais non sécurisé est un risque avec une meilleure rhétorique ; un service sécurisé sous juridiction étrangère est un service qu'on peut un jour perdre. openEduSuite traite ce domaine par son alignement ZKI IT-Grundschutz — la lecture universitaire de la base BSI, imposée en tant que code de politiques. La réflexion à retenir : l'EU CSF place SOV-7 dans une liste de critères de souveraineté, mais c'est en vérité le ticket d'entrée. Tout ce qui est au-dessus le présuppose.
SOV-8 — Durabilité environnementale
Le huitième critère porte sur le long terme : infrastructures économes en énergie, pratiques d'économie circulaire pour le matériel, et mesure transparente des émissions et de la consommation de ressources. C'est le domaine que les C3A excluent explicitement — non parce qu'il n'aurait pas d'importance, mais parce qu'il sort du champ d'une autorité de cybersécurité.
Réflexion. Son exclusion du catalogue dit quelque chose de la façon dont la souveraineté est habituellement encadrée : comme une propriété de relations juridiques et techniques, non de ressources physiques. Or la vue de long terme est la même vue. Une plateforme qui ne peut être soutenue énergétiquement ou matériellement pendant des décennies n'est pas souveraine, quoi qu'en dise son contrat — la dépendance arrive alors comme coût et rareté matérielle plutôt que comme courrier d'un tribunal étranger. Consolider les services d'un campus sur un cluster Kubernetes modeste et bien utilisé est, entre autres, une réponse à ce critère qu'aucun document d'achat ne répertorie.
Ce que révèle la lecture des critères appliqués à soi-même
Trois observations survivent au parcours des huit :
- Les critères forment une échelle, et la plupart des offres « souveraines » s'arrêtent au premier barreau. La résidence des données répond en partie à SOV-3 et à rien d'autre. Les domaines s'appuient l'un sur l'autre — la protection juridique (SOV-2) vaut peu sans l'indépendance opérationnelle (SOV-4), et l'indépendance opérationnelle est fragile sans la souveraineté de la chaîne d'approvisionnement et technologique (SOV-5, SOV-6).
- Pour une plateforme auto-hébergée, les critères ne sont pas un filtre mais un miroir. Posés à un fournisseur, ce sont des questions d'achat avec des réponses d'audit. Posés à nous-mêmes, ils deviennent inconfortables et utiles : pourrions-nous réellement fonctionner déconnectés de l'amont (SOV-4) ? Connaissons-nous notre chaîne d'approvisionnement (SOV-5) ? Le savoir survivra-t-il à ses mainteneurs (SOV-6) ? Les réponses honnêtes sont le plus souvent « de plus en plus oui, prouvablement non » — une meilleure position qu'un badge de conformité pour un service que nous ne contrôlons pas.
- Les deux domaines exclus sont les plus intéressants. SOV-7 montre que la souveraineté sans sécurité est une posture ; SOV-8 montre que la souveraineté sans durabilité est temporaire. Les frontières du catalogue valent autant que son contenu.
Les huit critères SOV compteront sans doute le plus là où ils entreront dans les appels d'offres et les lois — mais leur valeur la plus discrète est le vocabulaire. Ils permettent à un établissement de dire précisément ce qu'il entend par souveraineté, puis de mesurer si sa plateforme — achetée ou construite — le fait réellement.
Contribuer
Si votre établissement a mené des audits C5, des évaluations EU CSF, ou ses propres pratiques de déconnexion et de SBOM, la communauté openEduSuite tirerait profit de votre point de vue — surtout des constats inconfortables.
Visitez openedu.graphwiz.ai pour la documentation d'architecture et les guides de déploiement
La souveraineté posée à un fournisseur est de l'achat public. Posée à soi-même, c'est un miroir — les huit critères SOV sont simplement le cadre qui le maintient droit.
Notes et sources
- Référentiels discutés : EU Cloud Sovereignty Framework (Commission européenne) — source de la structure SOV-1 à SOV-8 et de la pondération d'achat ; BSI C3A — Criteria enabling Cloud Computing Autonomy (catalogue PDF ; annonce) — source des critères concrets (SOV-4-09-C, SOV-4-01-C1/C2, etc.) et de l'exclusion délibérée de SOV-7 et SOV-8.
- Interprétation : Les réflexions sur openEduSuite sont des auto-évaluations de l'équipe projet, pas des conclusions d'audit. Les affirmations sur ce qu'exige le catalogue C3A suivent les critères publiés ; lorsque la couverture médiatique (heise online, Computer Weekly, avril 2026) a éclairé la lecture, elle est créditée ici.
- Aucune affiliation : openEduSuite n'est affilié ni au BSI, ni à la Commission européenne, ni à un quelconque fournisseur cloud. Cet article ne constitue pas un avis juridique.
- Avertissement marques : Tous les noms de produits et de normes mentionnés (C5, C3A, IT-Grundschutz, NIS2, DORA, EUCS, Kubernetes, Keycloak, DFN-AAI, Nix, MariaDB) sont utilisés uniquement à des fins d'identification et d'information.
