Kubernetes cloud-agnostique : choisir et vérifier une plateforme portable, de l'API au test de sortie

« Cloud-agnostique » revient dans beaucoup de cadrages de plateforme, souvent sur un seul argument : les applications tournent sur Kubernetes, donc elles pourront tourner ailleurs. L'argument tient pour les objets de base de l'API. Il cède dès qu'on regarde autour des manifests : une annotation qui crée un répartiteur interne chez un seul fournisseur, une classe de stockage nommée d'après un pilote, une identité de charge adossée à la gestion des identités et des accès (IAM) du cloud, une base managée, des sauvegardes par instantané de disque. Le jour où changer de fournisseur devient une vraie question, l'équipe découvre ces dépendances une par une.

Ce que « cloud-agnostique » garantit réellement

La portabilité n'est pas binaire : c'est une frontière entre ce qui voyage avec les manifests, ce qui doit être rejoué par une procédure et ce qui reste ancré chez le fournisseur. Le seul socle commun garanti par un tiers est l'API Kubernetes, dans les limites du programme de conformité.

Ce que couvre la conformité CNCF

Le programme Certified Kubernetes de la CNCF vise à ce que chaque distribution prenne en charge les API requises, pour permettre l'interopérabilité d'une installation à l'autre. L'éditeur exécute la suite de conformité, publie ses résultats par pull request dans le dépôt cncf/k8s-conformance (e2e.log, junit_01.xml, PRODUCT.yaml et un README.md de reproduction), des contrôles automatiques s'exécutent, puis la CNCF relit. Seules la version courante et les deux précédentes peuvent être soumises ; une exécution de certification ne peut ignorer aucun test ; une offre reste certifiée tant qu'une version plus récente est certifiée au moins une fois par an.

C'est le périmètre des tests qui renseigne le plus. Un test n'entre dans la suite que s'il porte sur des fonctions GA et non optionnelles, fonctionne chez tous les fournisseurs et se limite aux capacités exposées par l'API, sans accès root ni écriture dans les espaces de noms système. Les règles du projet excluent explicitement les fonctions dépendant du nœud ou de la plateforme (disques multiples, GPU), les fonctions optionnelles comme l'application de politiques, les fonctions propres à un fournisseur cloud et tout ce qui exige un module d'admission non activé par défaut. La conformité garantit donc un comportement commun des Deployment, Service, du contrôle d'accès fondé sur les rôles (RBAC) ou des CustomResourceDefinition (CRD) ; elle ne dit rien de la classe de stockage, du plugin réseau, du répartiteur de charge, de l'identité des charges ni des performances.

La certification se lit par offre et par version. Au 28 septembre 2026, le répertoire v1.35 du dépôt contient des résultats pour les cinq offres étudiées (répertoires eks, gke, aks, scaleway et ovh) ; les répertoires des versions suivantes n'en contiennent qu'une partie. Une offre conforme sur une version ne l'est pas d'office sur la suivante : la vérification se refait à la date du choix.

La FAQ du programme renvoie aussi à l'exécution des tests par l'utilisateur sur son propre cluster, avec les outils cités dans les instructions officielles :

# Hydrophone (kubernetes-sigs) : exécution de la suite de conformité
go install sigs.k8s.io/hydrophone@latest
hydrophone --conformance

# Sonobuoy : mode utilisé pour les soumissions de certification
sonobuoy run --mode=certified-conformance
sonobuoy status
outfile=$(sonobuoy retrieve)

Exécutée sur la cible d'une sortie, la suite peut révéler un cluster mal configuré, une version inattendue ou un contrôle d'admission ajouté par l'équipe qui refuse ce que l'API accepte ailleurs.

Voyage, rejoué, ancré

Le schéma suivant range les éléments d'une plateforme selon ce qu'ils deviennent quand le cluster change de fournisseur.

Multi-cloud n'est pas cloud-agnostique

Une plateforme multi-cloud exploite des clusters, ou des nœuds, chez plusieurs fournisseurs ; une plateforme cloud-agnostique peut être déplacée avec un effort connu à l'avance. La première n'implique pas la seconde. Kubernetes Kosmos, chez Scaleway, rattache par exemple des instances et des serveurs de n'importe quel fournisseur à un plan de contrôle managé hébergé par Scaleway : les charges deviennent multi-cloud, la dépendance au plan de contrôle reste unique.

Même prudence pour l'infrastructure as code. Terraform décrit tous les fournisseurs avec le même langage, pas avec les mêmes ressources : aws_eks_cluster, google_container_cluster, azurerm_kubernetes_cluster, scaleway_k8s_cluster, ovh_cloud_project_kube, chacune avec ses arguments. Une organisation possible décrit chaque cluster avec le fournisseur Terraform de son cloud et applique un même dépôt d'applications à tous les clusters. Le portable est alors le dépôt d'applications ; le code d'infrastructure se réécrit par fournisseur, et ce coût appartient au plan de sortie.

Comparer les offres managées sur le cycle de vie et les contrôles

Une offre conforme présente la même API de base ; ce qui la distingue, c'est le contrat d'exploitation autour, à commencer par le cycle de vie des versions.

En amont, le projet Kubernetes publie environ trois versions mineures par an et maintient des branches pour les trois plus récentes. Chaque branche reçoit des correctifs pendant environ 14 mois : 12 mois de période standard, puis deux mois de maintenance limités aux vulnérabilités dotées d'un identifiant CVE (Common Vulnerabilities and Exposures), aux dépendances et aux problèmes critiques. La politique d'écart de versions impose de monter d'abord kube-apiserver, puis les contrôleurs, puis les nœuds ; un kubelet ne doit jamais être plus récent que l'API server et peut avoir jusqu'à trois versions mineures de retard.

Les offres managées ajoutent leur propre calendrier. Le tableau résume leurs pages officielles au 28 septembre 2026, sans classer les offres.

Trois conséquences pratiques. « Fin de support » ne signifie pas la même chose partout, et les nœuds ne suivent pas toujours le plan de contrôle : chez EKS, la montée automatique laisse les groupes de nœuds managés et autogérés à monter par l'équipe. La prolongation est un choix explicite et souvent facturé. Enfin, les pages d'un même fournisseur peuvent diverger : la politique de fin de vie d'OVHcloud, datée de 2022, renvoie aux trois mineures maintenues par le projet, tandis que sa page technique de versions, mise à jour en avril 2026, ne correspond pas à ce calendrier. L'engagement de niveau de service (SLA) et la version réellement proposée se lisent dans le contrat, l'API ou la console, à la date de l'étude.

Sur plusieurs offres, la version cible est l'intersection des versions disponibles partout, et le rythme est celui de l'offre la plus contraignante : au 28 septembre 2026, EKS ne liste pas encore 1.37, que Scaleway propose depuis le 26 août. Le choix d'une version cible commune se cadre avec l'architecture de la plateforme, décrite sur la page Plateforme Kubernetes : livrer sans perdre le contrôle. Restent à comparer l'accès à l'API (endpoint public ou privé), les fenêtres de maintenance, la gestion des images de nœuds, et le partage des composants système : chez Scaleway, CoreDNS, kube-proxy, CNI et CSI sont pris en charge par le fournisseur, mais la responsabilité d'un composant préinstallé passe à l'utilisateur dès qu'il le modifie.

Grille de portabilité : une couche, un test, une preuve

La grille suit huit couches. Pour chacune, elle sépare ce que le standard fixe de ce que l'offre décide, puis nomme le test minimal et la preuve à conserver.

API et extensions

L'API server expose la métrique apiserver_requested_deprecated_apis et annote l'audit (k8s.io/deprecated, k8s.io/removed-release) à chaque appel d'une version dépréciée ; le guide officiel liste les retraits par version et décrit le greffon kubectl convert. Chaque CustomResourceDefinition doit être classée : contrat de plateforme, rejoué par le bootstrap avec son contrôleur, ou dette de portabilité nommée. Les objets VolumeSnapshot en font partie : ce sont des CRD, hors de l'API de base, disponibles seulement avec un pilote CSI.

Réseau et exposition

Une NetworkPolicy n'a aucun effet sans plugin qui l'applique ; le test consiste donc à vérifier dans chaque cible qu'une politique de refus par défaut bloque effectivement le trafic. Sur EKS, l'application s'active par la valeur enableNetworkPolicy du module Amazon VPC CNI ; elle est toujours active avec GKE Dataplane V2 (eBPF, Cilium) ; AKS propose Cilium, Calico ou Azure Network Policy Manager, qui ne sera plus pris en charge sur les nœuds Linux à partir du 30 septembre 2028 ; Kapsule propose Cilium ou Calico, OVHcloud MKS Canal (offre Free) ou Cilium (offre Standard). Les politiques propres à un CNI ne voyagent qu'avec lui.

La documentation Kubernetes indique que l'API Ingress est figée, sans retrait prévu, et recommande Gateway API ; les contrôleurs Ingress se configurent souvent par des annotations qui leur sont propres. Le projet Kubernetes a retiré Ingress NGINX le 24 mars 2026 : plus aucune version n'est publiée depuis, correctifs de sécurité compris, et il n'existe pas de remplaçant compatible tel quel. Gateway API rend la portabilité lisible : fonctions Core portables, Extended portables mais pas prises en charge partout, Implementation-specific non portables.

Le Service de type LoadBalancer repose sur le cloud-controller-manager ; la documentation laisse au fournisseur le comportement des contrôles de santé et déprécie loadBalancerIP depuis 1.24 au profit d'annotations propres au fournisseur. Un même répartiteur interne s'écrit de cinq façons :

Chez EKS, l'annotation est lue par l'AWS Load Balancer Controller ou EKS Auto Mode.

Ces annotations vivent dans une surcharge par environnement (Kustomize, valeurs Helm), jamais dans le manifeste de base.

Stockage et données

Un PersistentVolumeClaim (PVC) sans storageClassName reçoit la classe marquée par défaut ; un PVC qui nomme une classe suppose qu'elle existe dans la cible. Le mode WaitForFirstConsumer retarde le provisionnement jusqu'à la création d'un pod qui utilise le PVC et évite de figer la topologie d'un volume. Le contenu d'un instantané reste dans le stockage du fournisseur : il sert à revenir en arrière sur place, pas à transporter des octets. Les bases de données appellent une procédure applicative (export et import, ou réplication propre au moteur).

Identité des charges

La base commune existe : Kubernetes projette des jetons de compte de service et, en version stable depuis 1.21, publie la configuration de son émetteur OpenID Connect (OIDC) à /.well-known/openid-configuration et ses clés à /openid/v1/jwks. Chaque fournisseur construit son mécanisme au-dessus :

• EKS : les rôles IAM pour comptes de service (IRSA) exigent un fournisseur OIDC IAM et l'annotation eks.amazonaws.com/role-arn ; EKS Pod Identity exige un agent en DaemonSet et n'existe que sur EKS, ni sur EKS Anywhere ni sur un Kubernetes autogéré sur EC2.
• GKE : Workload Identity Federation for GKE déploie un serveur de métadonnées sur chaque nœud, qui échange le jeton Kubernetes contre un jeton fédéré ; elle est toujours active en Autopilot.
• AKS : Microsoft Entra Workload ID repose sur l'émetteur OIDC du cluster, l'annotation azure.workload.identity/client-id et l'étiquette azure.workload.identity/use: "true".
• Toute autre offre : l'existence d'un mécanisme natif de fédération vers l'IAM du fournisseur se vérifie dans sa documentation à la date du choix ; sans lui, l'accès aux API du cloud devient une dépendance à reconstruire dans la cible.

Le test prouve dans la cible que chaque application obtient ses accès cloud sans clé statique. Une clé longue durée en secret fonctionne partout, mais c'est une dette de sécurité, pas de la portabilité.

Services managés, observabilité, sauvegardes

Pour un service managé, le portable est le protocole consommé par le code (PostgreSQL, API S3, AMQP), jamais l'implémentation ; les ancrages sont l'authentification par l'IAM, les extensions et les intégrations d'événements. Le test se fait tôt, contre une implémentation alternative. Pour l'observabilité, l'instrumentation OpenTelemetry voyage (le protocole OTLP est stable pour les traces, les métriques et les journaux) ; agents, backends et tableaux de bord gérés ne voyagent pas.

Pour les sauvegardes, Velero ne migre pas nativement les instantanés de volumes entre fournisseurs et renvoie à la sauvegarde au niveau fichier, ou au déplacement des données d'instantané CSI vers un stockage de sauvegarde (--snapshot-move-data). La première ne couvre que les volumes montés par un pod, hors hostPath, et lit un système de fichiers vivant, moins cohérent qu'un instantané. Velero ne restaure pas non plus vers une version Kubernetes inférieure.

L'inventaire se fait sur le dépôt et sur le cluster vivant :

# Dépôt : annotations et champs liés à une offre
grep -rnE 'service\.beta\.kubernetes\.io/|networking\.gke\.io/|loadbalancer\.openstack\.org/|nginx\.ingress\.kubernetes\.io/|eks\.amazonaws\.com/|iam\.gke\.io/|azure\.workload\.identity/|storageClassName:|node\.kubernetes\.io/instance-type' ./deploy

# Cluster : Services LoadBalancer, classe et annotations
kubectl get svc -A -o json | jq -r '.items[] | select(.spec.type == "LoadBalancer")
  | "\(.metadata.namespace)/\(.metadata.name) classe=\(.spec.loadBalancerClass // "défaut") annotations=\((.metadata.annotations // {}) | keys | join(","))"'

# Classes de stockage et PVC par classe
kubectl get storageclass -o custom-columns=NOM:.metadata.name,PILOTE:.provisioner,LIAISON:.volumeBindingMode
kubectl get pvc -A -o custom-columns=NS:.metadata.namespace,NOM:.metadata.name,CLASSE:.spec.storageClassName

# CRD installées, triées par groupe d'API
kubectl get crd -o custom-columns=GROUPE:.spec.group,NOM:.metadata.name --sort-by=.spec.group

# Comptes de service liés à une identité cloud
kubectl get sa -A -o json | jq -r '.items[]
  | select((.metadata.annotations // {}) | keys | any(test("eks\\.amazonaws\\.com|iam\\.gke\\.io|azure\\.workload\\.identity")))
  | "\(.metadata.namespace)/\(.metadata.name)"'

# Charges épinglées par nodeSelector
kubectl get deploy,sts,ds -A -o json | jq -r '.items[] | select(.spec.template.spec.nodeSelector != null)
  | "\(.kind) \(.metadata.namespace)/\(.metadata.name) \(.spec.template.spec.nodeSelector | tojson)"'

# Ingress NGINX encore présent (commande publiée par le projet Kubernetes)
kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx

Chaque occurrence est retirée, déplacée dans une surcharge d'environnement ou inscrite comme dépendance rejouée, avec un propriétaire. L'étiquette node.kubernetes.io/instance-type est standard, mais sa valeur est le type d'instance défini par le fournisseur : un nodeSelector qui la cite ne voyage pas.

Responsabilités, souveraineté et Data Act

Dans les cinq offres étudiées, le fournisseur opère le plan de contrôle et le magasin d'état du cluster (etcd, ou chez GKE un magasin qui sert l'API etcd), comme le précise la documentation de chacune. La sauvegarde d'etcd n'est donc pas un outil de sortie à la main du client : la sortie repose sur les manifests, les sauvegardes d'objets et les données.

Souveraineté : vérifier l'offre, pas le fournisseur

Pour un lecteur français, la portabilité se discute souvent avec la souveraineté. Des offres qualifiées SecNumCloud existent, et l'Agence nationale de la sécurité des systèmes d'information (ANSSI) publie la liste des prestataires qualifiés et de ceux en cours de qualification (pour ces derniers, seuls les projets que les prestataires ont accepté de rendre publics). La FAQ de l'ANSSI précise que SecNumCloud reconnaît une offre de cloud spécifique, et non un fournisseur ni une infrastructure : un service Kubernetes managé n'est couvert que s'il figure lui-même dans la liste, avec son périmètre, à la date du choix. Pour la grille, une offre qualifiée reste une offre : annotations, CSI et identité se testent de la même manière, dans les deux sens. Ce texte ne se prononce sur la qualification d'aucune offre citée.

Data Act : ce que la règle change pour une sortie

À la date du 28 septembre 2026, le règlement (UE) 2023/2854, dit Data Act, s'applique depuis le 12 septembre 2025. Selon la Commission européenne, il autorise jusqu'au 12 janvier 2027 des frais de changement de fournisseur réduits, limités aux coûts supportés, puis les supprime, frais de sortie de données compris ; il demande aussi aux fournisseurs d'infrastructure as a service (IaaS) de faciliter, vers un service du même type, des résultats sensiblement comparables pour les fonctions communes. Une proposition de la Commission du 19 novembre 2025, dite omnibus numérique (COM(2025) 837), prévoit d'alléger certaines de ces règles pour des services sur mesure et pour certains services fournis par des PME et des petites entreprises à moyenne capitalisation, sur des contrats conclus avant le 12 septembre 2025 : l'état du texte se vérifie à la date d'une décision. La règle réduit le coût du transfert ; elle ne réécrit ni les annotations, ni les identités, ni les services managés.

Plan de test de sortie : reconstruire, restaurer, basculer, revenir

Une stratégie de sortie se juge à une question : la plateforme a-t-elle déjà été reconstruite ailleurs, avec ses données, et le retour a-t-il été répété ? L'ordre est fixe : reconstruire, puis basculer, jamais l'inverse. L'exercice se fait hors production, sur un environnement représentatif, avec une cible réelle dans une autre offre.

Dans la cible, l'emplacement de sauvegarde de la source se déclare en lecture seule, comme le recommande la documentation Velero pour une migration, afin qu'une restauration ne modifie pas les sauvegardes par erreur :

# Source : objets et volumes sauvegardés au niveau fichier vers un stockage objet
velero backup create test-sortie --include-namespaces <NAMESPACE> --default-volumes-to-fs-backup

# Cible : même stockage objet, en lecture seule, puis restauration
velero backup-location create source --provider <PLUGIN> --bucket <BUCKET> --config <CONFIG> --access-mode=ReadOnly
velero restore create --from-backup test-sortie

Le stockage objet de sauvegarde se choisit lui aussi pour la sortie : s'il appartient au fournisseur quitté, son accès pendant la transition fait partie du plan. L'exercice se répète à une fréquence fixée par l'équipe et, au minimum, après tout changement de CNI, de pilote de stockage, de contrôleur d'exposition ou de mécanisme d'identité. Une migration réelle se conduit ensuite service par service, et non en une seule bascule ; le déroulé d'un déplacement de plateforme est présenté sur la page Migration Kubernetes : avancer par vagues.

Sources officielles et limites de lecture

Les faits cités proviennent de la documentation du projet Kubernetes, du programme de conformité de la CNCF, des pages officielles des cinq offres, de Velero, d'OpenTelemetry, de l'ANSSI et de la Commission européenne, consultées le 28 septembre 2026. Le tableau comparatif est une photographie datée, à recontrôler dans la console ou l'API de chaque offre au moment d'une décision. Deux pages OVHcloud consultées sont anciennes ou non concordantes : le texte ne s'appuie sur aucune liste de versions d'OVHcloud.

La conformité CNCF porte sur une version et sur le périmètre de sa suite de tests ; elle ne garantit ni les versions futures, ni les extensions, ni les engagements commerciaux. Aucune métrique, aucun prix, aucun SLA ni aucun résultat de migration n'est cité : chaque environnement produit ses propres preuves. Ce texte ne qualifie aucune offre au regard de SecNumCloud ni du Data Act.

Sources

1. Releases, Kubernetes, https://kubernetes.io/releases/ (calendrier lu dans le fichier data/releases/schedule.yaml du dépôt kubernetes/website), consulté le 28/09/2026.
2. Kubernetes Release Cycle, Kubernetes, https://kubernetes.io/releases/release/, consulté le 28/09/2026.
3. Patch Releases, Kubernetes, https://kubernetes.io/releases/patch-releases/, consulté le 28/09/2026.
4. Version Skew Policy, Kubernetes, https://kubernetes.io/releases/version-skew-policy/, consulté le 28/09/2026.
5. Certified Kubernetes Software Conformance, CNCF, https://www.cncf.io/training/certification/software-conformance/, consulté le 28/09/2026.
6. Instructions de soumission (instructions.md), dépôt cncf/k8s-conformance, CNCF, https://github.com/cncf/k8s-conformance/blob/master/instructions.md, consulté le 28/09/2026.
7. FAQ du programme (faq.md), dépôt cncf/k8s-conformance, CNCF, https://github.com/cncf/k8s-conformance/blob/master/faq.md, consulté le 28/09/2026.
8. Résultats de conformité Kubernetes v1.35 (répertoires eks, gke, aks, scaleway et ovh), dépôt cncf/k8s-conformance, CNCF, https://github.com/cncf/k8s-conformance/tree/master/v1.35, consulté le 28/09/2026.
9. Conformance Testing in Kubernetes (conformance-tests.md), projet Kubernetes, SIG Architecture, https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/conformance-tests.md, consulté le 28/09/2026.
10. Hydrophone, README, kubernetes-sigs, https://github.com/kubernetes-sigs/hydrophone/blob/main/README.md, consulté le 28/09/2026.
11. Understand the Kubernetes version lifecycle on EKS, AWS, https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html, consulté le 28/09/2026.
12. Learn how EKS Pod Identity grants pods access to AWS services, AWS, https://docs.aws.amazon.com/eks/latest/userguide/pod-identities.html, consulté le 28/09/2026.
13. IAM roles for service accounts, et Assign IAM roles to Kubernetes service accounts, AWS, https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html et https://docs.aws.amazon.com/eks/latest/userguide/associate-service-account-role.html, consultés le 28/09/2026.
14. Limit Pod traffic with Kubernetes network policies, et page de configuration associée, AWS, https://docs.aws.amazon.com/eks/latest/userguide/cni-network-policy.html et https://docs.aws.amazon.com/eks/latest/userguide/cni-network-policy-configure.html, consultés le 28/09/2026.
15. Amazon EKS architecture, AWS, https://docs.aws.amazon.com/eks/latest/userguide/eks-architecture.html, consulté le 28/09/2026.
16. GKE versioning and support, Google Cloud, https://docs.cloud.google.com/kubernetes-engine/versioning, consulté le 28/09/2026.
17. Maintenance windows and exclusions, Google Cloud, https://docs.cloud.google.com/kubernetes-engine/docs/concepts/maintenance-windows-and-exclusions, consulté le 28/09/2026.
18. About Workload Identity Federation for GKE, et Authenticate to Google Cloud APIs from GKE workloads, Google Cloud, https://docs.cloud.google.com/kubernetes-engine/docs/concepts/workload-identity et https://docs.cloud.google.com/kubernetes-engine/docs/how-to/workload-identity, consultés le 28/09/2026.
19. GKE Dataplane V2, Google Cloud, https://docs.cloud.google.com/kubernetes-engine/docs/concepts/dataplane-v2, consulté le 28/09/2026.
20. GKE cluster architecture, Google Cloud, https://docs.cloud.google.com/kubernetes-engine/docs/concepts/cluster-architecture, consulté le 28/09/2026.
21. Supported Kubernetes versions in AKS, Microsoft, https://learn.microsoft.com/en-us/azure/aks/supported-kubernetes-versions, consulté le 28/09/2026.
22. Long-term support for AKS, Microsoft, https://learn.microsoft.com/en-us/azure/aks/long-term-support, consulté le 28/09/2026.
23. Use Microsoft Entra Workload ID with AKS, Microsoft, https://learn.microsoft.com/en-us/azure/aks/workload-identity-overview, consulté le 28/09/2026.
24. Secure traffic between pods by using network policies in AKS, Microsoft, https://learn.microsoft.com/en-us/azure/aks/use-network-policies, consulté le 28/09/2026.
25. Core concepts for Azure Kubernetes Service (AKS), Microsoft, https://learn.microsoft.com/en-us/azure/aks/core-aks-concepts, consulté le 28/09/2026.
26. Kubernetes version support policy, Scaleway, https://www.scaleway.com/en/docs/kubernetes/reference-content/version-support-policy/ (texte lu dans la source publique de la documentation, https://github.com/scaleway/docs-content), consulté le 28/09/2026.
27. Managed Kubernetes service definition, Scaleway, https://www.scaleway.com/en/docs/kubernetes/reference-content/managed-kubernetes-service-definition/ (même source publique), consulté le 28/09/2026.
28. Kubernetes, Concepts (Kubernetes Kosmos), Scaleway, https://www.scaleway.com/en/docs/kubernetes/concepts/ (même source publique), consulté le 28/09/2026.
29. Load balancer annotations, scaleway-cloud-controller-manager, Scaleway, https://github.com/scaleway/scaleway-cloud-controller-manager/blob/master/docs/loadbalancer-annotations.md, consulté le 28/09/2026.
30. Managed Kubernetes End-of-Sale, End-of-Service and End-of-Life policies, OVHcloud, https://docs.ovhcloud.com/en/guides/public-cloud/containers-orchestration/managed-kubernetes/eos-eol-policies (texte lu dans la source publique de la documentation, https://github.com/ovh/docs, page mise à jour le 30/05/2022), consulté le 28/09/2026.
31. Kubernetes Plugins (CNI, CRI, CSI...) & softwares versions and reserved resources, OVHcloud, https://docs.ovhcloud.com/en/guides/public-cloud/containers-orchestration/managed-kubernetes/plugins-software-versions-reserved-resources (même source publique, page mise à jour le 10/04/2026), consulté le 28/09/2026.
32. Understanding OVHcloud Managed Kubernetes architecture, et Choosing the right OVHcloud Managed Kubernetes Plan: Free or Standard, OVHcloud, https://docs.ovhcloud.com/en/guides/public-cloud/containers-orchestration/managed-kubernetes/understanding-mks-architecture et https://docs.ovhcloud.com/en/guides/public-cloud/containers-orchestration/managed-kubernetes/mks-plans (même source publique), consultés le 28/09/2026.
33. Expose your applications using OVHcloud Public Cloud Load Balancer, OVHcloud, https://docs.ovhcloud.com/en/guides/public-cloud/containers-orchestration/managed-kubernetes/expose-applications-using-load-balancer (même source publique), consulté le 28/09/2026.
34. Ingress, Kubernetes, https://kubernetes.io/docs/concepts/services-networking/ingress/, consulté le 28/09/2026.
35. Ingress NGINX: Statement from the Kubernetes Steering and Security Response Committees, Kubernetes, https://kubernetes.io/blog/2026/01/29/ingress-nginx-statement/, 29/01/2026, consulté le 28/09/2026.
36. Conformance, Gateway API, Kubernetes SIG Network, https://gateway-api.sigs.k8s.io/concepts/conformance/, consulté le 28/09/2026.
37. Service, Kubernetes, https://kubernetes.io/docs/concepts/services-networking/service/, consulté le 28/09/2026.
38. Network Policies, Kubernetes, https://kubernetes.io/docs/concepts/services-networking/network-policies/, consulté le 28/09/2026.
39. Storage Classes, Kubernetes, https://kubernetes.io/docs/concepts/storage/storage-classes/, consulté le 28/09/2026.
40. Volume Snapshots, Kubernetes, https://kubernetes.io/docs/concepts/storage/volume-snapshots/, consulté le 28/09/2026.
41. Well-Known Labels, Annotations and Taints, Kubernetes, https://kubernetes.io/docs/reference/labels-annotations-taints/, consulté le 28/09/2026.
42. Configure Service Accounts for Pods (Service account issuer discovery), Kubernetes, https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/, consulté le 28/09/2026.
43. Deprecated API Migration Guide, Kubernetes, https://kubernetes.io/docs/reference/using-api/deprecation-guide/, consulté le 28/09/2026.
44. Warning: Helpful Warnings Ahead, et Audit Annotations, Kubernetes, https://kubernetes.io/blog/2020/09/03/warnings/ et https://kubernetes.io/docs/reference/labels-annotations-taints/audit-annotations/, consultés le 28/09/2026.
45. Cluster migration, Velero (documentation, branche main), https://velero.io/docs/main/migration-case/, consulté le 28/09/2026.
46. File System Backup, Velero (documentation, branche main), https://velero.io/docs/main/file-system-backup/, consulté le 28/09/2026.
47. CSI Snapshot Data Movement, Velero (documentation, branche main), https://velero.io/docs/main/csi-snapshot-data-movement/, consulté le 28/09/2026.
48. OpenTelemetry Protocol, tableau de maturité, dépôt open-telemetry/opentelemetry-proto, https://github.com/open-telemetry/opentelemetry-proto, consulté le 28/09/2026.
49. FAQ avant de se lancer dans la qualification SecNumCloud, ANSSI, https://cyber.gouv.fr/enjeux-technologiques/cloud/faq-qualification-secnumcloud/, consulté le 28/09/2026.
50. Prestataires de services d'informatique en nuage (SecNumCloud), 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 28/09/2026.
51. Data Act explained, Commission européenne, https://digital-strategy.ec.europa.eu/en/factpages/data-act-explained, consulté le 28/09/2026.
52. Règlement (UE) 2023/2854 du Parlement européen et du Conseil du 13 décembre 2023 (règlement sur les données), EUR-Lex, https://eur-lex.europa.eu/legal-content/FR/TXT/?uri=CELEX:32023R2854, consulté le 28/09/2026.
53. Proposition de règlement omnibus numérique, COM(2025) 837 du 19 novembre 2025, EUR-Lex, https://eur-lex.europa.eu/legal-content/FR/TXT/?uri=CELEX:52025PC0837, consulté le 28/09/2026.
54. Documentation des ressources Terraform aws_eks_cluster, google_container_cluster, azurerm_kubernetes_cluster (HashiCorp), scaleway_k8s_cluster (Scaleway) et ovh_cloud_project_kube (OVHcloud), sources publiques des fournisseurs Terraform : https://github.com/hashicorp/terraform-provider-aws, https://github.com/hashicorp/terraform-provider-google, https://github.com/hashicorp/terraform-provider-azurerm, https://github.com/scaleway/terraform-provider-scaleway, https://github.com/ovh/terraform-provider-ovh, consultés le 28/09/2026.
55. Route TCP and UDP traffic with Network Load Balancers, et Use Service Annotations to configure Network Load Balancers (EKS Auto Mode), AWS, https://docs.aws.amazon.com/eks/latest/userguide/network-load-balancing.html et https://docs.aws.amazon.com/eks/latest/userguide/auto-configure-nlb.html, consultés le 28/09/2026.
56. Ingress NGINX Retirement: What You Need to Know, Kubernetes, https://kubernetes.io/blog/2025/11/11/ingress-nginx-retirement/, consulté le 28/09/2026.