Externaliser l'exploitation cloud et Kubernetes : que confier, à qui et avec quel contrat

Une plateforme cloud et Kubernetes en production demande un travail continu : surveiller, corriger, monter de version, restaurer, répondre aux incidents. Quand personne n'est dédié à la fiabilité, ou quand une seule personne connaît vraiment la plateforme, la direction technique hésite entre recruter, confier l'exploitation à un tiers ou garder la main avec un appui extérieur. Chaque option peut convenir ; aucune ne se juge sur un prix tant que le périmètre, les niveaux de service et la sortie ne sont pas écrits.

Ce guide se place du côté de l'acheteur d'une externalisation cloud : partage des responsabilités, mesure du run actuel, niveaux de service, clauses du contrat, dépendance, grilles de comparaison.

Ce qui se confie, ce qui reste chez vous

Le build construit ou transforme la plateforme : conception, migration, nouveau cluster. Le run la fait fonctionner au quotidien : surveillance, correctifs, montées de version, sauvegardes, incidents, petites évolutions. Le build a un livrable et une fin, le run un périmètre et une durée ; un contrat qui ne les distingue pas finance des projets sur le budget du run, ou laisse le run sans moyens pendant un projet.

La règle de partage tient en une phrase : on délègue l'exécution, pas la responsabilité. Le modèle de responsabilité partagée d'Amazon Web Services (AWS) la pose déjà entre fournisseur cloud et client : AWS répond de l'infrastructure qui fait tourner les services de son cloud, le client de ce qui dépend des services qu'il choisit : pour une instance Amazon Elastic Compute Cloud (EC2), il gère le système d'exploitation invité, mises à jour et correctifs de sécurité compris. Confier l'exploitation à un tiers redécoupe la part du client sans la transférer. DORA l'écrit pour les entités financières : celles qui recourent à des services TIC (technologies de l'information et de la communication) fournis par des tiers restent à tout moment pleinement responsables du respect de leurs obligations (article 28, paragraphe 1, point a).

Mesurer le run avant de le confier

Une décision de recruter, de confier une partie ou de confier l'ensemble se prend sur le run réel, pas sur une liste de tâches théorique. Relevez sur une période représentative chaque activité récurrente, son volume, la personne qui la tient aujourd'hui et la compétence qu'elle demande. Le coût interne complet inclut le temps passé, les interruptions hors heures ouvrées et les outils. Les cellules restent « à renseigner » tant que la mesure n'est pas faite : une estimation de mémoire risque d'oublier les tâches que personne ne voit.

Les frontières à écrire

• Surveillance. Elle se délègue si l'outil, les règles d'alerte et l'historique restent dans vos comptes.
• Incidents. L'intervention se délègue sur un périmètre et des périodes définis ; la décision métier reste chez vous : prévenir vos clients, accepter un mode dégradé, préserver des traces.
• Correctifs. Nœuds, images de base et composants de la plateforme vont au fournisseur, les dépendances applicatives à l'équipe interne. À écrire : qui reconstruit une image applicative quand son image de base est vulnérable.
• Montées de version. Une activité récurrente, pas un projet. Le projet Kubernetes maintient les branches de ses trois dernières versions mineures et chaque version reçoit environ un an de correctifs : au 7 octobre 2026, ce sont les versions 1.37, 1.36 et 1.35, sorties entre décembre 2025 et août 2026, et le calendrier officiel fixe au 27 octobre 2026 la fin de vie de la 1.34. Sur Amazon EKS, une version mineure reçoit 14 mois de support standard puis 12 mois de support étendu, facturé en supplément. À la fin du support étendu, le plan de contrôle du cluster est mis à niveau automatiquement ; les nœuds autogérés et les groupes de nœuds managés restent sur l'ancienne version. Le calendrier et le coût de cette période sont détaillés dans « Support étendu EKS et RDS : calendrier de fin 2026, tarifs et calcul de l'exposition ».
• Coûts. Étiquetage et redimensionnement se délèguent ; un engagement d'achat (réservation, Savings Plan) engage votre trésorerie et se décide chez vous.
• Architecture et accès. Le fournisseur propose et documente chaque choix structurant, vous tranchez. L'organisation cloud, les comptes racine, le fournisseur d'identité et les accès d'urgence restent à vous ; le fournisseur reçoit des accès nominatifs et révocables.

Matrice à adapter. R : réalise ; A : arbitre et rend compte (un seul par ligne) ; C : consulté ; I : informé.

Niveaux de service : décrire des mécanismes, pas des promesses

Le vocabulaire vient de l'ingénierie de la fiabilité. Dans le livre Site Reliability Engineering de Google, un indicateur de niveau de service (SLI, Service Level Indicator) mesure quantitativement un aspect du service rendu ; un objectif (SLO, Service Level Objective) fixe une valeur cible, ou une plage de valeurs, pour un niveau de service mesuré par un SLI ; un accord (SLA, Service Level Agreement) est un contrat, explicite ou implicite, qui attache des conséquences au respect ou au non-respect des objectifs qu'il contient. Le test proposé par l'ouvrage : que se passe-t-il si les objectifs ne sont pas atteints ? Sans conséquence explicite, il s'agit presque certainement d'un SLO. Le même ouvrage déconseille de viser 100 % : l'objectif parfait coûte cher et freine les changements.

Un fournisseur de run ne maîtrise ni votre code, ni vos déploiements, ni les services managés du fournisseur cloud. Un engagement de disponibilité de la plateforme ne tient que s'il contrôle l'architecture et le rythme des changements ; sinon, il peut se vider par les exclusions. Ce qui se contractualise sans ambiguïté, ce sont ses propres actions ; la disponibilité peut rester un objectif partagé, suivi ensemble. Les éléments à écrire :

1. Plage de couverture. Heures ouvrées, plage étendue ou périodes d'intervention planifiées sur un périmètre restreint, et ce qui se passe hors plage. Pour toute couverture hors heures ouvrées, demandez qui intervient et qui prend le relais en cas d'indisponibilité.
2. Canal qui déclenche le décompte. Ticket, numéro dédié, alerte routée ; un message dans une messagerie partagée peut ne rien déclencher. Écrivez-le.
3. Délai de prise en charge. Du déclenchement à la prise en main par une personne qualifiée qui commence le diagnostic : l'engagement le plus facile à mesurer. Un délai de prise en charge ne garantit pas un délai de rétablissement.
4. Rétablissement et résolution. Rétablir le service (contournement, retour arrière) n'est pas corriger la cause ; pour la cause, le contrat peut prévoir une analyse post-incident avec actions suivies.
5. Mesure et revue. Horodatage dans l'outil de tickets, rapport périodique, revue avec actions, conséquences éventuelles.
6. Exclusions. Panne du fournisseur cloud, changement applicatif non annoncé : recevables si elles sont listées et bornées.

Aucune valeur n'est proposée : les délais se négocient selon votre criticité et le coût de la plage. Chaque case doit être remplie et mesurable ; la priorité, qualifiée par le fournisseur, reste requalifiable par vous.

Les clauses d'un contrat de run : périmètre, changements, accès, réversibilité

Un contrat de run se juge à ses annexes. Le guide de l'ANSSI sur l'externalisation (2010), toujours proposé sur son portail, fournit des clauses types et s'appuie sur un plan d'assurance sécurité qui formalise les engagements du fournisseur. Chaque clause ci-dessous appelle une preuve que vous pouvez demander avant de signer, puis à chaque revue.

Deux clauses se négocient mal après coup. Le processus de changement protège votre production : un changement hors de vos dépôts n'existe pas pour votre équipe, un changement urgent non régularisé devient une dérive. La clause de réversibilité se fixe à la signature : un plan qui renvoie à un devis futur ne protège de rien. Elle décrit ce qui est remis (inventaire, code, documentation, accès, journaux), comment le relais est assuré (fonctionnement en parallèle, transfert de connaissance), pendant combien de temps et à quel coût, et ce qui la déclenche. La portabilité technique de la plateforme elle-même se vérifie à part : voir « Kubernetes cloud-agnostique : choisir et vérifier une plateforme portable, de l'API au test de sortie ».

Si le fournisseur traite des données personnelles pour votre compte, l'article 28 du RGPD s'applique : pas d'autre sous-traitant sans votre autorisation écrite préalable, spécifique ou générale, avec dans le second cas une information sur les ajouts ou remplacements envisagés pour vous permettre d'objecter (paragraphe 2) ; suppression ou restitution des données personnelles, à votre choix, au terme de la prestation (paragraphe 3, point g) ; mise à disposition des informations nécessaires pour démontrer le respect de ces obligations et possibilité d'audits, y compris des inspections (paragraphe 3, point h).

ISO 27001 et systèmes sensibles : des preuves qui restent chez vous

Si votre organisation est certifiée ISO/IEC 27001 ou prépare la certification, le fournisseur de run relève des mesures de l'annexe A (numérotation d'ISO/IEC 27002:2022) sur les relations avec les fournisseurs (5.19), les accords conclus avec eux (5.20), la surveillance et les changements de leurs services (5.22) et les services en nuage (5.23). Ses runbooks, ses accès et ses changements alimentent les mesures 5.37 (procédures d'exploitation documentées), 8.2 (droits d'accès privilégiés) et 8.32 (gestion des changements) : ce sont des preuves que vos propres revues devront retrouver. Exigez qu'elles vivent chez vous (journaux dans vos comptes, demandes de fusion dans vos dépôts, comptes rendus d'intervention dans votre outil) et non dans son seul outillage. Si le fournisseur avance son propre certificat, lisez-en le périmètre : un certificat ne couvre que le périmètre qu'il déclare et ne remplace pas vos propres contrôles.

Pour un système d'information sensible, l'ANSSI a ouvert une qualification des prestataires d'administration et de maintenance sécurisées (PAMS), dont le référentiel d'exigences est publié.

Entités financières : ce que DORA impose au contrat

Pour une entité financière soumise à DORA, une partie de cette liste devient un contenu obligatoire du contrat. Les droits et obligations sont écrits, et le contrat complet, accords de niveau de service compris, tient dans un document écrit unique (article 30, paragraphe 1). Pour tout service TIC, il prévoit notamment : une description claire et complète des fonctions et des services, en indiquant si la sous-traitance d'un service qui soutient une fonction critique ou importante, ou de parties significatives de celle-ci, est autorisée et, le cas échéant, à quelles conditions ; les lieux de fourniture et de traitement des données, avec information préalable en cas de changement envisagé ; l'accès, la récupération et la restitution des données dans un format facilement accessible en cas d'insolvabilité ou de cessation d'activité du fournisseur, ou de fin du contrat ; la description des niveaux de service ; l'assistance en cas d'incident TIC lié au service, sans coût supplémentaire ou à un coût fixé à l'avance ; les droits de résiliation et les préavis minimaux (paragraphe 2). Pour un service qui soutient une fonction critique ou importante s'ajoutent des niveaux de service complets avec des objectifs de performance quantitatifs et qualitatifs précis, la mise en œuvre et le test de plans d'urgence par le fournisseur, des droits illimités d'accès, d'inspection et d'audit, et des stratégies de sortie avec une période de transition adéquate obligatoire (paragraphe 3). La description qualitative du chapitre précédent ne suffit alors plus : les valeurs s'écrivent au contrat.

Le règlement délégué (UE) 2024/1773 précise la politique de l'entité financière pour ces services : un plan de sortie documenté, régulièrement réexaminé et testé, réaliste, fondé sur des scénarios plausibles et assorti d'un calendrier compatible avec les conditions de sortie et de résiliation du contrat (article 10). Le règlement délégué (UE) 2025/532 encadre la sous-traitance de ces services : capacité du fournisseur à identifier tous les sous-traitants qui les fournissent, information de l'entité financière en temps utile sur tout changement significatif de cette sous-traitance, avec un délai de préavis pour l'approuver ou s'y opposer, et faculté de prévoir au contrat la résiliation si le fournisseur passe outre (articles 3 à 6). Qualifier une fonction de critique ou importante relève de l'entité financière et de son conseil.

Ne dépendre ni d'une personne ni d'un fournisseur

Le « bus factor » d'une plateforme est le nombre de personnes dont l'absence simultanée la rendrait impossible à opérer. Quand il vaut un, confier l'exploitation à un tiers peut simplement déplacer la personne clé de votre équipe vers celle du fournisseur. Réduire la dépendance exige que la connaissance et les moyens d'agir restent chez vous, quel que soit l'exploitant.

Le test : si la personne qui connaît la plateforme, ou le fournisseur entier, devenait indisponible demain, votre équipe pourrait-elle se connecter, redéployer à l'identique, restaurer une base et monter de version ? Chaque « non » appelle une mesure.

1. Le code d'infrastructure vit dans vos dépôts. Code Terraform ou OpenTofu, valeurs Helm, définitions GitOps et pipelines sont dans une organisation Git dont vous êtes propriétaire, l'état Terraform dans votre compte cloud. Aucun changement manuel sans régularisation dans le code ; une détection de dérive régulière le vérifie. Pour poser ce socle sans surdimensionner la plateforme, voir « Platform engineering pour une scale-up : par où commencer sans sur-ingénierie ».
2. Les accès d'urgence vous appartiennent. Le cadre AWS Well-Architected (bonne pratique SEC03-BP03) décrit la démarche : définir les défaillances qui justifient l'accès d'urgence, conserver les identifiants dans un coffre d'entreprise, avec plusieurs dispositifs d'authentification multifacteur (MFA) physiques lorsque l'accès passe par l'utilisateur racine d'un compte dédié, journaliser chaque tentative et alerter sur tout usage hors d'une urgence déclarée, tester périodiquement, renouveler les identifiants au retour à la normale. Anti-modèle cité : un accès d'urgence qui dépend des mêmes systèmes que l'accès normal. Pour AWS IAM Identity Center, la documentation recommande de déployer cette configuration avant toute interruption, car elle ne peut plus être créée si l'accès nécessaire à la création des rôles IAM est lui aussi interrompu. Côté contrat, ajoutez aux situations prévues celle d'un fournisseur de run injoignable.
3. Les runbooks sont exécutables par un tiers. Un runbook (procédure d'exploitation écrite) décrit symptôme, diagnostic, action, retour arrière et vérification ; seul test probant, quelqu'un d'autre que l'auteur l'exécute sans aide. Priorité à la restauration, à la rotation de secrets, à la montée de version et à la reconstruction d'un cluster.
4. L'escalade est écrite, les abonnements sont à votre nom. Qui appeler et dans quel ordre, plan de support du fournisseur cloud à votre nom, outillage (observabilité, registre d'images, DNS, certificats, nom de domaine) facturé à vous. Un abonnement au nom du fournisseur de run est une dépendance cachée.
5. Les restaurations sont jouées par votre équipe. Jouée à partir des runbooks, une restauration prouve à la fois la sauvegarde et la transmission de la connaissance.
6. Le transfert de connaissance est planifié. Binômage sur les opérations sensibles, ateliers de passation enregistrés, décisions d'architecture écrites, et un exercice de sortie à blanc où votre équipe opère seule pendant que le fournisseur observe.

À rejouer à chaque revue de service :

Comparer les options et les offres, repérer les signaux d'alerte

Trois options se comparent sur le périmètre mesuré au premier chapitre : garder l'exploitation en interne, avec ou sans recrutement, en confier une partie en gardant la main, ou la confier entièrement. La grille sépare coût initial, coût récurrent et charge qui reste chez vous, et affiche les inconnues au lieu de les combler.

Côté offres externes, chaque modèle de prix a son angle mort :

• Forfait par périmètre : prévisible si l'inventaire et la liste du hors forfait sont annexés.
• Prix par ressource (compte, cluster, nœud) : au nœud, la facture suit la charge de vos applications, pas le travail de run.
• Régie : souple pour une transition, sans engagement de délai ni de résultat.
• Indexation sur la facture cloud : le fournisseur gagne moins quand vos coûts baissent, ce qui devient incohérent si l'optimisation fait partie du périmètre.
• Socle et unités d'œuvre : forfait pour le récurrent, unités pour les demandes ; comparable si les unités sont définies.

Trois postes méritent une ligne à part dans toute comparaison : montées de version (incluses ou sur devis), interventions hors plage, réversibilité. Pour une entité financière, le contrat doit prévoir l'assistance en cas d'incident TIC lié au service, sans coût supplémentaire ou à un coût fixé à l'avance (DORA, article 30, paragraphe 2, point f). La grille suivante se remplit avec les réponses écrites de chaque fournisseur consulté.

Signaux d'alerte :

• comptes partagés, ou identités qui vivent chez le fournisseur plutôt que dans votre fournisseur d'identité ;
• code d'infrastructure dans les dépôts du fournisseur, ou « outillage maison » jamais remis ;
• disponibilité de plateforme garantie sans maîtrise de l'architecture, compensée par une longue liste d'exclusions ;
• couverture hors heures ouvrées annoncée sans plage, sans canal et sans relais nommé ;
• rapport mensuel qui compte des tickets sans mesurer de délais ni suivre d'actions ;
• réversibilité renvoyée à un devis ultérieur.

La page Infogérance cloud & maintien en conditions opérationnelles (MCO) décrit les dimensions que nous convenons avant toute responsabilité d'exploitation : périmètre couvert, fenêtre de couverture, canal d'entrée, chemin d'exception et réversibilité.

Sources officielles et limites de lecture

Les faits datés ont été vérifiés le 7 octobre 2026 aux sources indiquées ci-dessous : documentation d'AWS, calendrier de publication de Kubernetes, livre SRE de Google, textes européens publiés sur EUR-Lex, pages de l'ANSSI, norme ISO/IEC 27002:2022.

Limites. Ce guide n'est pas un avis juridique : qualifier un contrat, une sous-traitance de données personnelles ou une fonction critique ou importante relève de votre conseil. Aucun délai, prix, salaire ni durée n'est proposé : ces valeurs se mesurent chez vous et se négocient contrat par contrat. Les calendriers de support changent à chaque version. Le guide de l'ANSSI date de 2010 : ses références techniques ont pu vieillir. Les autres réglementations sectorielles et la souveraineté ne sont pas traitées.

Sources

1. Shared Responsibility Model, AWS, https://aws.amazon.com/compliance/shared-responsibility-model/, consulté le 07/10/2026.
2. Règlement (UE) 2022/2554 du Parlement européen et du Conseil du 14 décembre 2022 sur la résilience opérationnelle numérique du secteur financier (DORA), articles 28 et 30, EUR-Lex, https://eur-lex.europa.eu/eli/reg/2022/2554/oj/fra, consulté le 07/10/2026.
3. Releases, Kubernetes, https://kubernetes.io/releases/, et calendrier source de la page, kubernetes/website, GitHub, https://github.com/kubernetes/website/blob/main/data/releases/schedule.yaml, consultés le 07/10/2026.
4. Understand the Kubernetes version lifecycle on EKS, Amazon EKS User Guide, https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html, consulté le 07/10/2026.
5. Service Level Objectives, Site Reliability Engineering (chapitre 4), Google, https://sre.google/sre-book/service-level-objectives/, consulté le 07/10/2026.
6. Externalisation et sécurité des systèmes d'information : un guide pour maîtriser les risques, ANSSI, 03/12/2010, https://messervices.cyber.gouv.fr/guides/externalisation-et-securite-des-systemes-dinformation-un-guide-pour-maitriser-les, consulté le 07/10/2026.
7. Règlement (UE) 2016/679 du Parlement européen et du Conseil du 27 avril 2016 (règlement général sur la protection des données), article 28, EUR-Lex, https://eur-lex.europa.eu/eli/reg/2016/679/oj/fra, consulté le 07/10/2026.
8. ISO/IEC 27002:2022, extrait de prévisualisation en français (sommaire des mesures), iTeh Standards, https://cdn.standards.iteh.ai/samples/75652/9b0c626e1b1e4bda804fca1097e129db/ISO-IEC-27002-2022.pdf, consulté le 07/10/2026.
9. Prestataires d'administration et de maintenance sécurisées (PAMS), ANSSI, https://cyber.gouv.fr/offre-de-service/solutions-certifiees-et-qualifiees/services-de-securite-evalue/solutions-en-cours-de-qualification/pams/, consulté le 07/10/2026.
10. Règlement délégué (UE) 2024/1773 de la Commission du 13 mars 2024 (politique relative aux accords contractuels pour l'utilisation de services TIC soutenant des fonctions critiques ou importantes), article 10, EUR-Lex, https://eur-lex.europa.eu/legal-content/FR/TXT/HTML/?uri=OJ:L_202401773, consulté le 07/10/2026.
11. Règlement délégué (UE) 2025/532 de la Commission du 24 mars 2025 (sous-traitance de services TIC soutenant des fonctions critiques ou importantes), articles 3 à 6, EUR-Lex, https://eur-lex.europa.eu/legal-content/FR/TXT/HTML/?uri=OJ:L_202500532, consulté le 07/10/2026.
12. SEC03-BP03 Establish emergency access process, AWS Well-Architected Framework, pilier sécurité, https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_emergency_process.html, consulté le 07/10/2026.
13. Set up emergency access to the AWS Management Console, AWS IAM Identity Center User Guide, https://docs.aws.amazon.com/singlesignon/latest/userguide/emergency-access.html, consulté le 07/10/2026.