La souveraineté d’une plateforme cloud native ne se définit pas uniquement par le lieu d’exécution de la charge ou de stockage de ses données. Selon une analyse publiée par la CNCF le 18 août 2026 et rédigée par Chamod Perera, ambassadeur de la CNCF, et Suvin Kodituwakku, ingénieur logiciel senior chez WSO2, la démonstration de la souveraineté dépend également de l’emplacement de l’état de contrôle, des chemins empruntés par les journaux et les métadonnées, des entités capables d’accéder aux clés et aux identifiants, ainsi que de la capacité de l’équipe à poursuivre les opérations si un service du fournisseur disparaît.
L’analyse propose de considérer la souveraineté comme une propriété de la topologie de la plateforme, et non comme un simple choix de région dans une liste de paramètres. Elle utilise OpenChoreo, une plateforme interne open source destinée aux développeurs et un projet en phase Sandbox de la CNCF, comme exemple vérifiable de cette approche, tout en soulignant que les principes architecturaux ne lui sont pas propres.
Quatre questions qui dépassent l’emplacement des serveurs
L’article estime que, dans le contexte de cadres tels que l’EU Data Act, NIS-2, DORA et le UK Data Use and Access Act, les équipes chargées des plateformes doivent répondre à des questions pratiques qui vont au-delà de la détermination de la région géographique. La première est la suivante : sous quelle juridiction chaque composant susceptible d’accéder aux données du locataire fonctionne-t-il, y compris le niveau de contrôle et les journaux ? La deuxième : l’équipe peut-elle exécuter, reconstruire et déplacer les charges si le service hébergé du fournisseur cesse de fonctionner ?
Les deux autres questions concernent la possibilité pour des parties situées hors des frontières d’accéder aux clés, à l’état des clusters ou aux identifiants d’administration, ainsi que le fait de savoir si un changement de fournisseur, de matériel ou de pays nécessite de réécrire la charge. L’analyse conclut que ces questions portent principalement sur le lieu où se trouvent le contrôle et l’état, et sur les personnes qui peuvent y accéder.
Comment fonctionne l’architecture multiniveau ?
OpenChoreo divise la plateforme en clusters indépendants, chacun disposant de son propre cycle de vie, de ses propres limites de sécurité et de son propre comportement de mise à l’échelle :
- Niveau de contrôle : il conserve l’état souhaité au moyen d’API déclaratives et exécute les contrôleurs de rapprochement, mais n’exécute pas les charges des locataires.
- Niveaux de données : des clusters Kubernetes compatibles exécutent effectivement les charges, chacun disposant de son propre serveur d’API et de son propre état.
- Niveaux de supervision : ils collectent et servent les journaux, les métriques et les traces.
- Niveaux de flux de travail : ils exécutent les processus CI et GitOps.
- Niveau d’expérience : il fournit le portail développeur, une interface CLI, des API et MCP.
L’élément le plus important est le modèle de communication. Les niveaux de données, de supervision et de flux de travail ouvrent des connexions sortantes mutuellement authentifiées par mTLS vers une passerelle du niveau de contrôle, tandis que le niveau de contrôle n’initie pas de connexions vers eux. Ainsi, les serveurs d’API des clusters hébergeant des charges réglementées ne sont pas exposés à Internet. En outre, le niveau de contrôle conserve l’état souhaité, et non l’intégralité de l’état d’exécution du locataire ; le niveau de données peut donc continuer à traiter les requêtes même en cas de perte de connexion avec le niveau de contrôle.
Qu’est-ce qui change concrètement pour les équipes chargées des plateformes ?
Chaque niveau de données peut être associé à une juridiction précise, ce qui rend le modèle « une juridiction, un niveau de données » vérifiable et auditable. Chaque niveau de données envoie également ses données opérationnelles à un niveau de supervision régional, au lieu de faire transiter les journaux et les traces par le niveau de contrôle. Les charges des locataires et leurs mesures restent ainsi à l’intérieur des frontières régionales définies.
La capacité à fonctionner indépendamment du fournisseur repose sur le fait que chaque niveau de données est un cluster Kubernetes complet et compatible, et non un point de terminaison géré et fermé. L’analyse mentionne l’utilisation de composants open source de l’écosystème CNCF et du cloud natif, tels qu’Argo Workflows, Cloud Native Buildpacks, OpenSearch, Prometheus, OpenTelemetry, Flux, cert-manager et Cilium. L’architecture modulaire permet de remplacer un composant ou de connecter un système de supervision existant en conservant la même interface de requête.
La protection des secrets et des clés est confiée à un magasin compatible avec External Secrets Operator ou à un coffre choisi par l’opérateur, plutôt que d’imposer une propriété par défaut des clés. Des autorisations précises peuvent également être appliquées au niveau des espaces, des projets et des composants, avec l’association des groupes à tout fournisseur d’identité OAuth2/OIDC, que le demandeur soit un développeur, un outil CLI ou un agent d’intelligence artificielle.
Intégration des clusters virtuels aux niveaux de la plateforme
Ce modèle n’élimine pas le modèle du cluster de locataire ; il le complète. Le cluster virtuel accorde à chaque locataire un niveau de contrôle virtuel, un serveur d’API et un magasin qui lui sont propres au sein d’un cluster hôte partagé. Il isole ainsi l’état de contrôle entre les locataires à un coût inférieur à celui d’un cluster dédié pour chacun d’eux. Il ne détermine toutefois pas à lui seul la juridiction dans laquelle le locataire doit être hébergé, le lieu d’envoi des journaux ni l’entité autorisée à promouvoir la charge entre deux environnements ou deux régions.
La couche de la plateforme ajoute ici les contrôles de distribution et d’exploitation. Une ressource DataPlane peut porter une étiquette de juridiction, tandis qu’une ressource observabilityPlaneRef peut être associée à un niveau de supervision régional ; les chemins de promotion déterminent quant à eux les environnements entre lesquels la charge peut se déplacer. Le portail développeur fournit également des parcours prêts à l’emploi qui réduisent la nécessité d’accorder aux utilisateurs un accès direct aux clusters sensibles.
Cette combinaison présente toutefois une limite claire : les locataires présents sur le même hôte partagent le nœud et le noyau du système d’exploitation. Si le modèle de menace exige une isolation matérielle pour chaque locataire, le cluster virtuel ne suffira pas et un niveau de données physique indépendant sera nécessaire.
La souveraineté comme configuration déclarative et auditable
L’analyse propose de représenter la topologie au moyen de ressources Kubernetes déclaratives conservées dans Git : quelle région utilise quel niveau de données, quelle destination reçoit les données de supervision et quels chemins de promotion sont autorisés. La création d’une nouvelle juridiction devient ainsi une demande de fusion (pull request) révisable, et la réponse à la question de savoir pourquoi les données d’un locataire se trouvent dans une région donnée repose sur un journal des modifications, et non sur une capture d’écran d’un tableau de bord.
L’architecture multiniveau ne modifie toutefois pas la juridiction de l’entité qui exploite l’infrastructure et ne supprime pas son exposition aux systèmes juridiques auxquels elle est soumise. Elle trace également les frontières sans imposer à elle seule les politiques appliquées à l’intérieur de celles-ci ; l’attestation de la chaîne d’approvisionnement, le SBOM, l’enregistrement des audits et l’identité des charges au moyen d’outils tels que SPIFFE/SPIRE restent des contrôles distincts qui doivent être intégrés.
Le coût opérationnel constitue une dernière contrainte : chaque cluster supplémentaire nécessite une supervision, des mises à niveau et des sauvegardes. L’architecture est donc justifiée lorsque les frontières définies ont un poids juridique ou de sécurité réel, et peut devenir excessive dans les environnements qui n’en ont pas besoin. En conclusion, la combinaison de clusters de locataires pour isoler les ressources, d’une architecture multiniveau pour déterminer ce qui peut franchir les frontières et de configurations déclaratives gérables par version transforme la souveraineté d’une promesse contractuelle en une propriété exploitable et révisable.