Cloud souverain en 2026 : SecNumCloud, offres qualifiées et Kubernetes, comment choisir

L'exigence arrive par plusieurs canaux : un acheteur public qui exige un « cloud de confiance », un appel d'offres qui cite SecNumCloud, une analyse de risque qui interroge l'exposition au droit extra-européen. Chaque fournisseur répond en affichant sa qualification, et les mots se mélangent : souverain, qualifié, en cours de qualification, visa de sécurité. Pour une équipe plateforme, la question utile est plus étroite : le service Kubernetes managé retenu figure-t-il lui-même dans le périmètre qualifié, et que perd-on en y entrant ?

« Souverain », « de confiance », « qualifié » : ce que dit réellement SecNumCloud

« Cloud souverain » est un terme commercial. Le vocabulaire de l'État est plus précis : la direction interministérielle du numérique (DINUM) appelle « cloud commercial de confiance » les « offres disposant de la qualification ANSSI SecNumCloud et de l'immunité contre toute réglementation extraterritoriale ». Deux conditions, et une seule autorité pour attester la première.

Une offre, une décision, un périmètre

Selon la FAQ de l'ANSSI, SecNumCloud « vient reconnaître une offre de cloud spécifique et non pas un fournisseur de cloud, ni une infrastructure » : un service hébergé sur une infrastructure qualifiée n'hérite pas de la qualification. Celle-ci vaut trois ans au plus, avec des audits de surveillance annuels, et donne droit au visa de sécurité. Le parcours part d'un dossier de demande déposé auprès de l'ANSSI, passe par une évaluation de conformité menée par un organisme d'évaluation inscrit au catalogue de l'ANSSI, et aboutit à une décision de qualification. L'entrée officielle est notifiée par une lettre de l'ANSSI qui fixe le jalon J0, après quoi le prestataire peut communiquer. La liste « en cours » ne montre que les projets rendus publics et ne publie aucun jalon par offre.

Les décisions publiées sont plus instructives que les annonces. Celles consultées ici nomment le fournisseur, le service et son type (infrastructure, plateforme, conteneurs ou logiciel en tant que service, soit IaaS, PaaS, CaaS ou SaaS), visent le référentiel v3.2 et fixent une fin de validité. Elles posent des conditions, qui varient d'une décision à l'autre : accès couvert par navigateur web, avec ou sans API selon la décision, accès par application mobile ou client lourd exclu ; dans plusieurs décisions, infogérance et services managés complémentaires hors périmètre ; administration recommandée depuis des postes dédiés. La décision n° 3389 du 31 juillet 2026, qui annule et remplace la décision n° 918 du 30 mai 2025, énumère par exemple, pour une offre IaaS, les composants couverts : IaaS VMware, IaaS open source, stockage objet S3, HSM-KMS (module matériel de sécurité et service de gestion des clés), bare metal, ainsi que les briques VPC et VMI ajoutées par cette décision, dont les intitulés correspondent aux offres Virtual Private Cloud (réseaux privés) et VM Instances (machines virtuelles à la demande) de Cloud Temple. C'est ce niveau de détail qu'il faut obtenir pour chaque service utilisé par la plateforme.

L'immunité au droit extra-européen, chapitre 19.6

La FAQ résume le chapitre « 19.6. Protection vis-à-vis du droit extra-européen » : la société doit être soumise exclusivement au droit de l'Union européenne (UE), ce qui s'apprécie sur le siège social, établi dans un État membre, sur la capitalisation, où les entités hors UE restent minoritaires, sur le recours à des sociétés tierces hors UE, sur l'autonomie d'exploitation et sur l'indépendance face aux ingérences. Le référentiel chiffre les seuils de détention : 24 % individuellement et 39 % collectivement au plus pour les entités hors UE. Pour l'ANSSI, le référentiel garantit « un haut niveau d'exigence tant du point de vue technique, qu'opérationnel ou juridique ».

Conséquence : une offre fondée sur une technologie américaine peut être qualifiée si l'entité qui l'exploite remplit ces conditions. S3NS indique être contrôlée majoritairement par Thales, Google n'ayant qu'une participation très minoritaire, et opérer son offre par ses seuls salariés, en France. À l'inverse, des données localisées en France chez un fournisseur soumis à un droit extra-européen ne satisfont pas l'exigence d'immunité. La page d'Amazon Web Services (AWS) consacrée à la souveraineté numérique en Europe, qui présente l'AWS European Sovereign Cloud, ne mentionne pas SecNumCloud, et aucune offre d'AWS, de Microsoft ou de Google ne figure sous leur nom dans la liste des projets en cours consultée.

EUCS : pas d'équivalent européen adopté

Le décret d'application de la loi SREN admet une certification européenne équivalente. Au 7 octobre 2026, la FAQ de l'ANSSI indique, à propos du schéma européen de certification des services cloud, que « le schéma EUCS n'est pas finalisé à ce jour », et la Commission européenne écrit que l'agence de l'Union européenne pour la cybersécurité (ENISA) y travaille ; la Commission a adopté en juin 2026 une proposition de Cloud and AI Development Act. Pour un choix à faire aujourd'hui, la preuve disponible reste la décision de l'ANSSI.

Qui est obligé, qui est seulement incité

Une organisation qui envisage un cloud qualifié n'y est pas forcément obligée. Le périmètre légal est étroit ; le périmètre contractuel l'est beaucoup moins.

L'État : doctrine « cloud au centre », puis loi SREN

La doctrine « cloud au centre », posée par la circulaire du 5 juillet 2021 et actualisée le 31 mai 2023, fixe dans sa règle 9 deux niveaux. Pour les données personnelles, le règlement général sur la protection des données (RGPD) s'applique et les données, même localisées dans l'UE, doivent être immunisées contre les demandes d'autorités d'États tiers hors accord international. Pour les données « d'une sensibilité particulière », dont la violation peut porter atteinte à l'ordre public, à la sécurité publique, à la santé et à la vie des personnes ou à la propriété intellectuelle, l'offre doit « impérativement » être qualifiée SecNumCloud, ou disposer d'une qualification européenne au moins équivalente, et être immunisée.

La loi n° 2024-449 du 21 mai 2024, dite SREN, a inscrit cette exigence dans son article 31 ; le décret n° 2026-272 du 14 avril 2026, publié au Journal officiel du 16 avril 2026, l'applique, et un arrêté du 12 août 2026 approuve comme référentiel de ce décret la version 3.2 de SecNumCloud. Selon ces textes :

• sont visés les administrations de l'État, ses opérateurs, six groupements d'intérêt public listés par le décret et, par la loi elle-même, le groupement de la Plateforme des données de santé ;
• les données sensibles recouvrent les données protégées par des secrets légaux, notamment ceux des articles L. 311-5 et L. 311-6 du code des relations entre le public et l'administration, et celles nécessaires aux missions essentielles de l'État ;
• la conformité au référentiel s'atteste par une qualification de l'ANSSI ou par une certification de l'Union européenne ou d'un État de l'Espace économique européen reconnue équivalente par l'ANSSI, selon des critères qui portent aussi sur la détention du capital ;
• un projet engagé avant la publication du décret peut obtenir une dérogation, au plus 18 mois après la disponibilité d'une offre acceptable en France.

Les recommandations de l'ANSSI de juillet 2024 pour l'hébergement des systèmes d'information sensibles vont dans le même sens : les systèmes sensibles relevant de la doctrine de l'État ne peuvent être hébergés que dans des offres qualifiées SecNumCloud.

Les entreprises : une exigence qui arrive par le contrat

Les textes cités ne créent pas d'obligation générale pour les entreprises privées. L'exigence les atteint autrement. Un éditeur SaaS qui sert une entité visée, sur des données sensibles, doit fournir un service dont la conformité est attestée par une qualification, ou par une certification européenne reconnue équivalente : les offres SaaS sont éligibles, et un SaaS bâti sur une offre déjà qualifiée passe par une évaluation adaptée, dans laquelle l'ANSSI « détoure » l'offre sous-jacente ; l'hébergement sur une offre qualifiée ne vaut pas qualification. Un acheteur peut aussi inscrire la qualification dans son cahier des charges sans y être tenu.

SecNumCloud ne remplace pas la législation sur les données de santé : la règle 9 précise que, pour les systèmes qui en contiennent, l'hébergeur doit en plus y être conforme. Selon la DINUM, le groupement de la Plateforme des données de santé a retenu Scaleway le 21 mai 2026, par le marché « Nuage public ».

Décider : faut-il un cloud qualifié SecNumCloud ?

État des offres au 7 octobre 2026 : qualification et Kubernetes

Lire le tableau sans le surinterpréter

« En cours de qualification » n'est pas un niveau intermédiaire : c'est l'absence de décision. Les jalons cités, comme les J0 et J1 annoncés par NumSpot pour ses services PaaS, viennent des fournisseurs. Les deux publications de l'ANSSI ne sont pas toujours alignées : au 7 octobre 2026, la liste des projets en cours mentionne encore NumSpot et la SNC Cloud Platform d'OVHcloud, alors que le catalogue inscrit leur IaaS comme qualifiée par des décisions du 31 juillet 2026 ; un fournisseur peut aussi annoncer sa qualification plus tard, comme NumSpot en septembre 2026. Seule la décision tranche, avec son périmètre et sa date de fin de validité, puisqu'une qualification se renouvelle : au catalogue du 15 septembre 2026, celle de l'IaaS d'Outscale prend fin le 30 novembre 2026 et celle de l'offre VMware d'OVHcloud le 29 décembre 2026. Enfin, chez un même fournisseur, les services Kubernetes grand public (MKS chez OVHcloud, Kapsule chez Scaleway) sont distincts des offres qualifiées ou en cours.

Ce qu'il faut demander avant de signer

• Le numéro, la date et le PDF de la décision, avec sa fin de validité.
• Le nom exact du service qualifié et la liste des composants couverts.
• Les conditions : modes d'accès couverts, exclusions, recommandations d'administration.
• La région, les zones et le comportement en cas de perte d'une zone.
• Pour chaque service utilisé par la plateforme (Kubernetes, registre, clés, sauvegarde, journaux, bases de données), sa présence dans le périmètre ou son statut publié.

Héberger Kubernetes dans un périmètre qualifié : ce qui change pour l'équipe plateforme

Dans un périmètre qualifié, héberger Kubernetes impose un montage et un écart de fonctions. La grille qui suit est établie à partir des décisions de l'ANSSI et de la documentation publique des fournisseurs citées en fin d'article.

Trois montages

1. Kubernetes managé inclus dans le périmètre. C'est le cas, selon S3NS, de GKE dans son offre qualifiée, dont la décision couvre le type CaaS, et de la plateforme Red Hat OpenShift de Cloud Temple, qualifiée en PaaS par la décision n° 919 du 30 mai 2025 : l'équipe vérifie la décision, puis l'écart de fonctions avec le même service hors périmètre qualifié.
2. Kubernetes managé hébergé sur une IaaS qualifiée. Outscale présente OKS comme « hébergé sur » son cloud qualifié, dont la décision ne vise que l'IaaS ; NumSpot annonce ses services Kubernetes en cours. Tant que la décision ne cite pas le service, la règle de l'ANSSI s'applique : héberger sur une infrastructure qualifiée ne vaut pas qualification.
3. Kubernetes autogéré sur l'IaaS qualifiée. Machines ou serveurs dédiés d'une offre qualifiée, distribution installée par l'équipe : plan de contrôle, etcd et ses sauvegardes, montées de version, pilote de stockage et répartiteur de charge deviennent sa charge ou celle de son exploitant. Plusieurs décisions consultées excluent expressément l'infogérance du périmètre : l'exploitation par un tiers ne bénéficie pas de la qualification de l'offre et se contractualise à part.

Les services managés hors périmètre restent utilisables pour les systèmes qui n'exigent pas de qualification. Leurs calendriers de versions se lisent offre par offre, et les pages d'un même fournisseur peuvent diverger : chez OVHcloud, la politique de fin de vie de MKS, datée du 30 mai 2022, suit les trois mineures maintenues par le projet, tandis que la page technique des versions, mise à jour le 10 avril 2026, liste 1.31 à 1.35. Même prudence pour OKS, dont la documentation liste 1.32 à 1.36 alors que le projet Kubernetes maintient 1.35 à 1.37, et 1.34 jusqu'au 27 octobre 2026. La version proposée se lit dans l'API ou la console, le jour du choix.

Grille de vérification d'un Kubernetes managé qualifié

S3NS publie pour chaque produit une page des différences avec Google Cloud. Celle de GKE, mise à jour le 6 octobre 2026, sert d'exemple documenté ; les mêmes questions se posent à toute offre.

L'absence d'annuaire du fournisseur fait passer les accès humains par une fédération depuis le fournisseur d'identité de l'organisation (Keycloak, par exemple), ce qui sert la portabilité. La région unique ne supprime pas l'exigence de reprise d'activité : elle la reporte sur un second site, qualifié ou non selon les données répliquées.

Inventorier ce qui ne passera pas

Avant tout essai, un inventaire du dépôt et du cluster source révèle les dépendances absentes de la cible. L'exemple vise un départ de GKE public vers GKE chez S3NS, dont la documentation indique que googleapis.com devient s3nsapis.fr, que le registre utilise s3nsregistry.fr au lieu de pkg.dev et que les identifiants de projet prennent le préfixe s3ns:.

# Domaines Google Cloud à réécrire : API, registre, identité des charges
grep -rnE 'googleapis\.com|pkg\.dev|svc\.id\.goog' ./deploy ./infra

# CRD de fonctions GKE ou Google Cloud, à confronter à la page des différences
kubectl get crd -o custom-columns=GROUPE:.spec.group,NOM:.metadata.name \
  | grep -E 'gke\.io|cloud\.google\.com'

# Charges épinglées sur une famille de machines, une VM Spot ou un accélérateur
kubectl get deploy,sts,ds,job -A -o json | jq -r '.items[]
  | select(.spec.template.spec.nodeSelector != null)
  | select(.spec.template.spec.nodeSelector | keys
      | any(test("cloud.google.com/(machine-family|gke-spot|gke-accelerator)")))
  | "\(.kind) \(.metadata.namespace)/\(.metadata.name)"'

Chaque occurrence est réécrite dans une surcharge d'environnement, remplacée par un composant opéré par l'équipe ou inscrite comme blocage. Le même inventaire, adapté aux domaines et annotations de la technologie d'origine, vaut pour toute offre qualifiée fondée sur un autre cloud public.

Entrer sans s'enfermer : garder la plateforme portable

Une offre qualifiée reste une offre : annotations, stockage, identité et services managés s'y testent comme ailleurs, dans les deux sens. Le risque propre à ce choix est de compenser chaque fonction absente par un composant ancré dans la cible, et de fabriquer une seconde dépendance.

Cinq décisions qui préservent la sortie

• API GA, spécificités en surcharge. Les manifests s'en tiennent aux API en disponibilité générale (GA) ; annotations de répartiteur, classes de stockage et liaisons d'identité vivent dans une surcharge par environnement. La grille « une couche, un test, une preuve » de « Kubernetes cloud-agnostique : choisir et vérifier une plateforme portable, de l'API au test de sortie » s'applique telle quelle.
• Identité fédérée depuis l'organisation, vers chaque offre ; les identités de charges propres au fournisseur restent en surcharge.
• Images par digest, construites et analysées dans la CI, poussées vers le registre de la cible ; la liste des digests déployés sert de preuve et de plan de reconstruction.
• Observabilité au format ouvert : l'instrumentation OpenTelemetry voyage ; le backend se place selon la sensibilité des journaux.
• Sauvegardes restaurables ailleurs, au niveau fichier ou par déplacement des données d'instantané vers un stockage objet du périmètre, avec au moins une restauration réelle dans une autre offre.

Découper plutôt que tout déplacer

L'obligation porte sur des données et des systèmes, pas sur une entreprise entière. Exemple fictif : un éditeur SaaS qui vend à des ministères isole dans une offre qualifiée le service qui traite des pièces protégées par un secret légal, et garde son site public et ses environnements de développement sur son offre actuelle ; les flux entre les deux passent par une API revue et journalisée. Le découpage réduit l'écart de fonctions à absorber, mais chaque donnée qui franchit la frontière doit être classée.

Sortir, un jour, de la cible aussi

À la date du 7 octobre 2026, le Data Act, règlement (UE) 2023/2854, s'applique depuis le 12 septembre 2025 ; selon la Commission européenne, les coûts de changement de fournisseur et de sortie des données restent facturables, limités aux coûts supportés, jusqu'au 12 janvier 2027, puis disparaissent. La règle réduit le coût du transfert, pas celui de la réécriture.

Une migration vers une offre qualifiée suit l'ordre de toute migration : inventaire, classement des données, choix du montage, cluster cible créé par le code d'infrastructure, bootstrap GitOps depuis le même dépôt, tests de la grille, restauration, bascule partielle, retour arrière répété. La démarche par pilote puis par vagues, avec des chemins de retour testés avant chaque exposition, est décrite sur la page Migration Kubernetes : avancer par vagues.

Sources officielles et limites de lecture

Les faits réglementaires proviennent de l'ANSSI, de la DINUM, des textes publiés sur Légifrance et de la Commission européenne ; les faits techniques, de la documentation publique des fournisseurs et du projet Kubernetes, consultées le 7 octobre 2026. Deux limites : dans le tableau des offres, chaque statut « qualifié » renvoie à une décision de l'ANSSI ; ce que les fournisseurs annoncent au-delà (produits couverts, jalons) reste leur déclaration ; la loi SREN et le décret n° 2026-272 sont décrits d'après leur texte publié sur Légifrance.

Les pages des fournisseurs peuvent changer à tout moment : celles de S3NS citées datent des 5, 6 et 7 octobre 2026. Le tableau est une photographie datée, à recontrôler décision de l'ANSSI en main. Ce texte ne classe aucune offre, ne cite ni prix ni engagement de service, et ne se prononce sur aucune qualification au-delà de ce que publient l'ANSSI et les fournisseurs. Les fournisseurs sont nommés pour des faits publiés, jamais comme recommandation, et leur mention ne signale aucun partenariat ; CTN Solutions ne revendique aucune qualification SecNumCloud.

Sources

1. Prestataires de services d'informatique en nuage (SecNumCloud), projets en cours de qualification, ANSSI, https://cyber.gouv.fr/offre-de-service/solutions-certifiees-et-qualifiees/services-de-securite-evalue/solutions-en-cours-de-qualification/prestataires-secnumcloud/, consulté le 07/10/2026.
2. Découvrir les solutions certifiées et qualifiées, ANSSI, https://cyber.gouv.fr/offre-de-service/solutions-certifiees-et-qualifiees/services-de-securite-evalue/decouvrir-les-solutions-certifiees-qualifiees/, consulté le 07/10/2026.
3. Catalogue produits, services, profils de protection, sites certifiés, qualifiés, agréés par l'ANSSI (mis à jour le 15/09/2026), ANSSI, https://messervices.cyber.gouv.fr/visas/catalogue-produits-services-profils-de-protection-sites-certifies-qualifies-agrees-anssi.pdf, consulté le 07/10/2026.
4. FAQ avant de se lancer dans la qualification SecNumCloud, ANSSI, https://cyber.gouv.fr/enjeux-technologiques/cloud/faq-qualification-secnumcloud/, consulté le 07/10/2026.
5. Cloud, ANSSI, https://cyber.gouv.fr/enjeux-technologiques/cloud/, consulté le 07/10/2026.
6. Prestataires de services d'informatique en nuage (SecNumCloud), référentiel d'exigences, version 3.2 du 8 mars 2022, ANSSI, https://cyber.gouv.fr/sites/default/files/document/secnumcloud-referentiel-exigences-v3.2.pdf, chapitre 19.6, consulté le 07/10/2026.
7. Décisions de qualification n° 3389/ANSSI/SDE/NP du 31 juillet 2026 et n° 918/ANSSI/SDE/NP du 30 mai 2025 (annulée et remplacée par la première), service « IAAS - SECURE TEMPLE », ANSSI, https://messervices.cyber.gouv.fr/visas/2026_3389_np.pdf et https://messervices.cyber.gouv.fr/visas/2025_918_np.pdf, consultées le 07/10/2026.
8. Décision de qualification n° 561/ANSSI/SDE/NP du 24 mars 2025, service « WORLDLINE CLOUD SECURED SERVICES », ANSSI, https://messervices.cyber.gouv.fr/visas/2025_561_np.pdf, consulté le 07/10/2026.
9. Décisions de qualification n° 1369/ANSSI/SDE du 2 août 2024 et n° 2822/ANSSI/SDE/NP du 18 mai 2026 (services SaaS), ANSSI, https://messervices.cyber.gouv.fr/visas/2024_1369_np.pdf et https://messervices.cyber.gouv.fr/visas/2026_2822_np.pdf, consultées le 07/10/2026.
10. Recommandations pour l'hébergement dans le cloud des systèmes d'information sensibles, version 1.0, juillet 2024, ANSSI, https://messervices.cyber.gouv.fr/documents-guides/20240814_np_anssi_recommandations_hebergement_cloud_si_a5_v1g_fr.pdf, consulté le 07/10/2026.
11. Doctrine d'utilisation de l'informatique en nuage par l'État (« cloud au centre »), DINUM, https://www.numerique.gouv.fr/services/cloud/doctrine/, consulté le 07/10/2026.
12. Cloud, DINUM, https://www.numerique.gouv.fr/services/cloud/, consulté le 07/10/2026.
13. Décret n° 2026-272 du 14 avril 2026 relatif à la protection des données d'une sensibilité particulière des administrations, opérateurs et groupements d'intérêt public de l'Etat traitées par un service d'informatique en nuage fourni par un prestataire privé (Journal officiel n° 0090 du 16 avril 2026), et arrêté du 12 août 2026 portant approbation du référentiel d'exigences relatif aux prestataires de services d'informatique en nuage (Journal officiel n° 0189 du 14 août 2026), Légifrance, https://www.legifrance.gouv.fr/loda/id/JORFTEXT000053900789 et https://www.legifrance.gouv.fr/jorf/id/JORFTEXT000054678082, consultés le 07/10/2026.
14. Loi n° 2024-449 du 21 mai 2024 visant à sécuriser et à réguler l'espace numérique, Légifrance, https://www.legifrance.gouv.fr/jorf/id/JORFTEXT000049563368, article 31 lu le 07/10/2026.
15. Plateforme des données de santé : comment la DINUM a structuré le choix d'un cloud souverain pour les données de santé (8 juin 2026), DINUM, https://www.numerique.gouv.fr/actualites/plateforme-donnees-sante-choix-cloud-souverain/, consulté le 07/10/2026.
16. Cloud computing, Commission européenne, https://digital-strategy.ec.europa.eu/en/policies/cloud-computing, consulté le 07/10/2026.
17. Data Act explained, Commission européenne, https://digital-strategy.ec.europa.eu/en/factpages/data-act-explained, consulté le 07/10/2026.
18. S3NS announces SecNumCloud qualification for its PREMI3NS trusted cloud offering (17 décembre 2025), S3NS, https://www.s3ns.io/en/news/premi3ns-secnumcloud-qualification, consulté le 07/10/2026.
19. PREMI3NS: how S3NS meets the requirements of SecNumCloud qualification, S3NS, https://www.s3ns.io/en/news/en-PREMI3NS-SecNumCloud, consulté le 07/10/2026.
20. Key differences between Cloud de Confiance and Google Cloud (mise à jour du 07/10/2026), documentation S3NS, https://documentation.s3ns.fr/docs/overview/tpc-key-differences, consulté le 07/10/2026.
21. GKE, différences avec Google Cloud (mise à jour du 06/10/2026), documentation S3NS, https://documentation.s3ns.fr/kubernetes-engine/docs/tpc-differences, consulté le 07/10/2026.
22. Artifact Registry, différences avec Google Cloud (mise à jour du 05/10/2026), documentation S3NS, https://documentation.s3ns.fr/artifact-registry/docs/tpc-differences, consulté le 07/10/2026.
23. Bleu, page d'accueil et « Nos services », Bleu, https://www.bleucloud.fr/ et https://www.bleucloud.fr/nos-services/, consultés le 07/10/2026.
24. SecNumCloud, conformité, OVHcloud, https://www.ovhcloud.com/fr/compliance/secnumcloud/, consulté le 07/10/2026.
25. Les offres qualifiées SecNumCloud, OVHcloud, https://www.ovhcloud.com/fr/secnumcloud/, consulté le 07/10/2026.
26. SNC Cloud Platform, OVHcloud, https://www.ovhcloud.com/fr/solutions/uc-secnumcloud-environment/, consulté le 07/10/2026.
27. SecNumCloud, et Sécurité et conformité, Scaleway, https://www.scaleway.com/fr/security-and-compliance/secnumcloud/ et https://www.scaleway.com/fr/security-and-compliance/, consultés le 07/10/2026.
28. OUTSCALE Kubernetes as a Service, et page d'accueil, 3DS Outscale, https://fr.outscale.com/cloud-experience/outscale-kubernetes-as-a-service/ et https://fr.outscale.com/, consultés le 07/10/2026.
29. About OKS, documentation 3DS Outscale, https://docs.outscale.com/en/userguide/About-OKS.html, consulté le 07/10/2026 (page non datée).
30. Plateforme de services cloud qualifiée SecNumCloud, NumSpot, https://numspot.com/certification/plateforme-services-cloud-qualifiee-secnumcloud/, consulté le 07/10/2026.
31. Europe digital sovereignty, AWS, https://aws.amazon.com/compliance/europe-digital-sovereignty/, consulté le 07/10/2026.
32. Releases, Kubernetes, https://kubernetes.io/releases/, consulté le 07/10/2026.
33. Managed Kubernetes End-of-Sale, End-of-Service and End-of-Life policies (page du 30/05/2022), et Kubernetes Plugins (CNI, CRI, CSI...) & softwares versions and reserved resources (page du 10/04/2026), OVHcloud, https://docs.ovhcloud.com/en/guides/public-cloud/containers-orchestration/managed-kubernetes/eos-eol-policies et https://docs.ovhcloud.com/fr/guides/public-cloud/containers-orchestration/managed-kubernetes/plugins-software-versions-reserved-resources, consultés le 07/10/2026.
34. Décision de qualification n° 2057/ANSSI/SDE/NP du 17 décembre 2025, service « CLOUD DE CONFIANCE S3NS », fournisseur Thales Cloud Sécurisé, ANSSI, https://messervices.cyber.gouv.fr/visas/2025_2057_np.pdf, consulté le 07/10/2026.
35. Décision de qualification n° 2118/ANSSI/SDE du 30 novembre 2023, service « IAAS CLOUD ON DEMAND », fournisseur Outscale SAS, ANSSI, https://messervices.cyber.gouv.fr/visas/2023_2118_np.pdf, consulté le 07/10/2026.
36. Décisions de qualification n° 2279/ANSSI/SDE du 28 décembre 2023, service « Hosted Private Cloud powered by VMware », et n° 3393/ANSSI/SDE/NP du 31 juillet 2026, service « SNC CLOUD PLATFORM », OVH SAS, ANSSI, https://messervices.cyber.gouv.fr/visas/2023_2279_np.pdf et https://messervices.cyber.gouv.fr/visas/2026_3393_np.pdf, consultées le 07/10/2026.
37. Décision de qualification n° 3395/ANSSI/SDE/NP du 31 juillet 2026, service « PLATEFORME DES SERVICES CLOUD NUMSPOT (IAAS) », ANSSI, https://messervices.cyber.gouv.fr/visas/2026_3395_np.pdf, consulté le 07/10/2026.
38. Décision de qualification n° 919/ANSSI/SDE/NP du 30 mai 2025, service « PAAS OPENSHIFT », Cloud Temple, ANSSI, https://messervices.cyber.gouv.fr/visas/2025_919_np.pdf, consulté le 07/10/2026.
39. PaaS OpenShift souverain, VM Instances et Virtual Private Cloud (VPC) souverain, Cloud Temple, https://www.cloud-temple.com/produits/paas-openshift/, https://www.cloud-temple.com/produits/vm-instances/ et https://www.cloud-temple.com/produits/virtual-private-cloud-souverain/, consultés le 07/10/2026.