Les containers managés (CaaS, Containers as a Service) sont devenus le défaut 2026 pour les nouvelles applications cloud-native. Ils combinent ce que le FaaS apporte de mieux (zéro infrastructure à gérer, scaling automatique) avec ce que le PaaS propriétaire ne sait pas faire (portabilité multi-cloud par le standard OCI). Cette page distingue les deux familles CaaS (sans orchestrateur visible vs Kubernetes managé), explique comment ça fonctionne concrètement, compare avec FaaS et VMs, liste les pièges classiques, et défend une opinion claire sur quand passer de Cloud Run à Kubernetes managé.
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »- La définition CaaS : on apporte une image OCI, le fournisseur orchestre
- Le spectre : CaaS sans orchestrateur (Cloud Run, ECS) vs Kubernetes managé (EKS, AKS, GKE, OKS)
- Les plateformes 2026 comparées par fournisseur
- Les 5 pièges : cold start, scaling à zéro, networking, image bloatée, observabilité
- Quand choisir CaaS sans K8s et quand basculer vers Kubernetes managé
Prérequis : avoir compris les conteneurs et la grille XaaS. Si besoin, lisez d’abord Mutualisation et virtualisation et IaaS, PaaS, SaaS, FaaS, CaaS.
1. Le CaaS, c’est quoi vraiment
Section intitulée « 1. Le CaaS, c’est quoi vraiment »Le CaaS est le modèle qui a explosé entre 2020 et 2026 sous l’impulsion de la maturité OCI et de Kubernetes. Le principe est simple à énoncer mais dense en conséquences : vous apportez un container (image OCI standard, par exemple construite avec Docker, Podman ou Buildah), le fournisseur l’exécute. Tout ce qui est en dessous (OS hôte, container engine, scheduling, scaling, networking de base) est managé.
Trois propriétés en découlent qui définissent le modèle :
La portabilité par le standard OCI. Une image qui tourne sur Cloud Run aujourd’hui tournera sur OKS Outscale demain, sur Kubernetes on-prem, sur ECS Fargate ou sur App Runner sans réécriture. Le format OCI (Open Container Initiative) est un standard ouvert ratifié par tous les acteurs majeurs depuis 2017. C’est l’antithèse du FaaS, dont chaque fournisseur impose son SDK propriétaire.
L’abstraction OS complète. Vous n’avez plus à choisir entre Ubuntu et AlmaLinux pour la VM hôte. Vous n’avez plus à patcher le kernel. Vous n’avez plus à gérer le container engine (Docker, containerd, CRI-O). Toute cette couche est invisible et opérée par le fournisseur, qui assume les CVE, les mises à jour, le hardening.
Le scaling natif intégré. Tous les CaaS modernes scalent automatiquement votre application en fonction de la charge, sans configuration complexe. Sur Cloud Run, le passage de 0 à 1 000 instances se fait en quelques secondes sur la base du trafic HTTP entrant. Sur Kubernetes managé, l’HPA (Horizontal Pod Autoscaler) gère la même mécanique avec une granularité plus fine.
2. Le spectre CaaS : sans orchestrateur visible vs Kubernetes managé
Section intitulée « 2. Le spectre CaaS : sans orchestrateur visible vs Kubernetes managé »Le terme « CaaS » couvre en réalité deux familles techniques distinctes, qui se distinguent par la visibilité de l’orchestrateur.
CaaS sans orchestrateur visible
Section intitulée « CaaS sans orchestrateur visible »Vous donnez une image OCI, le fournisseur la lance avec la mémoire et le CPU demandés. Pas de cluster à provisionner, pas de manifeste YAML à écrire, pas de kubectl à apprendre. La plateforme expose une API simple : créer un service, mettre à jour l’image, scaler.
Cette famille convient aux équipes qui veulent les bénéfices des containers sans la complexité Kubernetes. Elle est typiquement plus chère par container que Kubernetes managé à grande échelle, mais elle élimine le coût opérationnel du cluster.
Plateformes 2026 :
| Plateforme | Fournisseur | Spécificité |
|---|---|---|
| Cloud Run | GCP | Le plus mature, scaling à zéro natif, modèle requête |
| App Runner | AWS | Pour applications web, simple, pas de modèle requête |
| ECS Fargate | AWS | Tasks serverless, plus flexible que App Runner |
| Container Apps | Azure | Basé sur Kubernetes + KEDA en arrière-plan |
| Container Instances | Azure | Le plus simple, mais limité (pas d’autoscaling) |
| Cloud Run Jobs | GCP | Variante batch pour traitements ponctuels |
CaaS avec Kubernetes managé
Section intitulée « CaaS avec Kubernetes managé »Le control plane Kubernetes (etcd, API server, scheduler, controller) est managé par le fournisseur, vous gérez les workloads applicatifs via kubectl et les manifestes YAML. C’est le modèle qui s’impose dès qu’on dépasse une dizaine de services interconnectés.
Plateformes 2026 :
| Plateforme | Fournisseur | Spécificité |
|---|---|---|
| EKS | AWS | Le plus mature côté AWS, intégration IAM fine, prix élevé |
| AKS | Azure | Bonne intégration Entra ID, control plane gratuit |
| GKE | GCP | Le pionnier, options Autopilot (entièrement managé) |
| OKS | Outscale | Souverain SecNumCloud, basé sur Kubernetes upstream |
| OVHcloud Managed Kubernetes | OVHcloud | Tarif compétitif, support en français |
| Scaleway Kapsule | Scaleway | Souverain français, pricing simple |
Résumé du spectre
Section intitulée « Résumé du spectre »| Critère | CaaS sans orchestrateur | Kubernetes managé |
|---|---|---|
| Courbe d’apprentissage | Quelques heures | Plusieurs semaines |
| Granularité | Service | Pod, ReplicaSet, Deployment, Service, Ingress |
| Manifeste | Console ou CLI simple | YAML Kubernetes |
| Networking | Limité, géré par la plateforme | CNI, Service Mesh, NetworkPolicy |
| Scaling | Automatique sur métriques de la plateforme | HPA (Horizontal Pod Autoscaler), VPA, Cluster Autoscaler, ou KEDA pour des métriques custom |
| Portabilité | Très bonne (image OCI) | Excellente (manifeste K8s standard) |
| Coût opérationnel | Très faible | Moyen à élevé |
| Pour qui | Équipes < 3 ops, < 10 services | Équipes DevOps, > 10 services |
3. Comment ça fonctionne en pratique
Section intitulée « 3. Comment ça fonctionne en pratique »Pour rendre le CaaS concret, voici la séquence complète d’un déploiement sur Cloud Run (CaaS sans orchestrateur), puis sur OKS (Kubernetes managé). Le pipeline est étonnamment proche dans les deux cas — c’est l’effet du standard OCI.
Cycle de vie sur Cloud Run
Section intitulée « Cycle de vie sur Cloud Run »Étape 1 — Build de l’image OCI. Localement ou en CI, vous construisez votre image avec un Dockerfile ou Buildpacks. Sortie : une image OCI taguée, par exemple eu.gcr.io/projet/api:v1.4.2.
Étape 2 — Push vers le registry. L’image part vers le registry du fournisseur (Artifact Registry GCP, ECR AWS, ACR Azure, registry Outscale). C’est l’étape qui nécessite l’authentification.
Étape 3 — Déploiement. Une commande gcloud run deploy api --image=eu.gcr.io/projet/api:v1.4.2 --region=europe-west9 suffit. Cloud Run prend l’image, l’enroule dans une couche d’isolation (gVisor sur Cloud Run), expose un endpoint HTTPS public ou interne.
Étape 4 — Routage et scaling. À la première requête HTTP, Cloud Run lance une instance de votre container. Si plusieurs requêtes simultanées arrivent, il en lance plusieurs. Si les requêtes s’arrêtent, il scale à zéro après quelques minutes d’inactivité.
Cycle de vie sur OKS / Kubernetes managé
Section intitulée « Cycle de vie sur OKS / Kubernetes managé »Étape 1 et 2 identiques : build image OCI, push vers registry.
Étape 3 — Manifeste Kubernetes. Vous écrivez un fichier YAML qui décrit le Deployment (combien de replicas, quelle image), le Service (comment le pod est joignable), l’Ingress (comment l’extérieur accède). Plus complexe que Cloud Run, mais bien plus expressif.
Étape 4 — Déploiement. kubectl apply -f manifeste.yaml. Le control plane Kubernetes orchestre le déploiement, le scheduling sur les nodes, la mise à jour rolling, le rollback en cas d’échec.
Étape 5 — Scaling fin. L’HPA gère le scale-out sur des métriques CPU, mémoire, ou des métriques applicatives custom. Beaucoup plus de leviers qu’en CaaS sans orchestrateur, au prix de la complexité de configuration.
4. CaaS vs FaaS vs Kubernetes : la matrice de choix
Section intitulée « 4. CaaS vs FaaS vs Kubernetes : la matrice de choix »Pour naviguer entre les trois modèles modernes, le tableau suivant condense les arbitrages essentiels.
| Critère | FaaS pur (Lambda, Functions) | CaaS sans orchestrateur (Cloud Run, ECS) | Kubernetes managé (EKS, AKS, OKS) |
|---|---|---|---|
| Unité de déploiement | Fonction (code) | Image OCI | Image OCI + manifeste YAML |
| Cold start | 100 ms–10 s | 200 ms–10 s | Aucun (instances tournent) |
| Durée d’exécution | 5–15 min | Illimitée (App Runner) ou 60 min (Cloud Run) | Illimitée |
| Portabilité | Faible (SDK propriétaire) | Très bonne (OCI) | Excellente (K8s standard) |
| Vendor lock-in | Élevé | Faible | Très faible |
| Scaling à zéro | Natif | Cloud Run et App Runner oui, ECS non | Possible avec configuration custom mais peu utilisé |
| Coût à charge nulle | Zéro | Zéro (Cloud Run) ou minimum 1 instance (App Runner) | Coût du control plane et des nodes |
| Coût à très haute charge | Élevé (par requête) | Modéré | Le plus économique |
| Complexité opérationnelle | Très faible | Faible | Moyenne à élevée |
| Cible | Event-driven, automation, pics ponctuels | Apps web, microservices simples, équipes < 3 ops | Architectures cloud-native > 10 services |
5. Les avantages réels du CaaS
Section intitulée « 5. Les avantages réels du CaaS »Au-delà du marketing, le CaaS apporte quatre bénéfices concrets qui justifient sa montée en puissance comme défaut moderne.
La portabilité multi-cloud par le standard OCI. C’est l’avantage stratégique majeur. Une image qui tourne aujourd’hui sur Cloud Run peut tourner demain sur OKS Outscale, sans réécriture, sans changement de SDK, sans nouvelle bibliothèque cliente. Cette portabilité est la principale stratégie de mitigation du vendor lock-in en 2026, plus efficace que le multi-cloud actif.
L’abstraction OS qui élimine la dette opérationnelle. Pas de patching kernel à planifier, pas de mises à jour distribution à orchestrer, pas de fin de support OS à anticiper. Sur une équipe sans DevOps dédié, c’est typiquement 0,2 à 0,3 ETP économisé par rapport à un IaaS classique. Cette économie se transforme directement en temps de développement produit.
Le scaling natif sans tuning complexe. La plupart des CaaS modernes incluent un autoscaler par défaut, configuré sur des métriques pertinentes (requêtes simultanées sur Cloud Run, CPU sur HPA Kubernetes). Pas besoin de paramétrer des Auto Scaling Groups manuels comme en IaaS, pas besoin de redécouper son code en fonctions FaaS, pas de calcul fin de capacité à anticiper.
Le moindre lock-in comparé au FaaS. Une fonction Lambda dépend du SDK AWS, du format d’événement AWS, des intégrations IAM AWS. Une image OCI dépend uniquement du standard OCI et de votre code applicatif. Pour un projet soucieux de souveraineté technologique (cf. Souveraineté technologique de la stack), le CaaS bat largement le FaaS.
6. Les 5 pièges classiques du CaaS
Section intitulée « 6. Les 5 pièges classiques du CaaS »Comme tout outil, le CaaS a ses limites. Voici les pièges que l’on rencontre lors de revues d’architectures.
❄️ Cold start sur scale-from-zero
Le piège : Cloud Run, App Runner et Container Apps scalent à zéro quand l’inactivité dure. La première requête après scale-zero subit un cold start de 200 ms à 10 s.
Cas typique : application B2B à trafic faible, où chaque utilisateur unique réveille la plateforme et perçoit une latence dégradée.
Mitigation : minimum d’instances actives en permanence (1 à 3 selon le service), images optimisées pour démarrage rapide (multi-stage build, distroless), warm-up requests automatiques.
💰 Coûts cachés à scaling permanent à 1
Le piège : pour éviter le cold start, on configure « 1 instance minimum permanente ». Cette instance tourne 24/7 et coûte entre 30 et 120 €/mois selon la mémoire allouée. Pour 5 services, c’est 150 à 600 €/mois rien qu’en idle.
Cas typique : architecture microservices avec 15 services, chacun à 1 instance min — la facture cumulée dépasse souvent l’équivalent en VM unique avec reverse proxy.
Mitigation : audit régulier des minimums permanents, fusion de microservices peu sollicités, scale-to-zero accepté pour les services tolérants au cold start.
🌐 Networking limité hors Kubernetes
Le piège : sur Cloud Run et App Runner, vous n’avez pas de NetworkPolicy fine, pas de service mesh, pas d’isolation réseau granulaire. L’ingress et l’egress sont gérés par la plateforme avec peu de leviers.
Cas typique : exigence de durcissement réseau (mTLS service-to-service, segmentation par environnement) impossible à implémenter sans basculer vers Kubernetes managé.
Mitigation : si le besoin réseau est avancé, choisir directement Kubernetes managé. Ne pas tenter de simuler ce que K8s fait nativement avec des CaaS sans orchestrateur.
📦 Image bloatée = démarrage lent
Le piège : une image basée sur python:3.12 pèse 1 Go, met 8 secondes à démarrer. Multiplié par les cold starts, l’expérience utilisateur s’effondre.
Cas typique : équipe qui ne maîtrise pas les multi-stage builds, embarque toute la chaîne de build dans l’image runtime, traîne des dépendances inutilisées.
Mitigation : multi-stage builds systématiques, images de base distroless ou Alpine, scan régulier de la taille (objectif < 200 Mo pour les apps standard), suppression des node_modules de dev.
🔍 Observabilité par défaut médiocre
Le piège : les CaaS sans orchestrateur fournissent un minimum d’observabilité (logs basiques, métriques agrégées). Pour vraiment comprendre ce qui se passe, il faut instrumenter manuellement.
Cas typique : panne de production où les logs disent juste « Container exited with code 1 » sans plus de contexte. Plusieurs heures perdues à diagnostiquer.
Mitigation : OpenTelemetry instrumenté dès le J1, logs structurés JSON avec corrélation par trace ID, métriques applicatives exposées via /metrics, dashboards Grafana ou Datadog connectés.
7. Quand choisir CaaS sans K8s vs Kubernetes managé
Section intitulée « 7. Quand choisir CaaS sans K8s vs Kubernetes managé »La question revient en boucle : « on prend Cloud Run ou on plante un cluster Kubernetes ? ». Voici la grille de décision que je propose.
Choisir CaaS sans orchestrateur (Cloud Run, App Runner, ECS Fargate) quand
Section intitulée « Choisir CaaS sans orchestrateur (Cloud Run, App Runner, ECS Fargate) quand »- L’équipe a moins de 3 personnes Ops/DevOps ou aucune équipe Ops dédiée.
- L’application a moins de 10 services indépendants.
- Le besoin réseau est simple : un endpoint HTTPS public ou interne, pas de mTLS service-to-service complexe, pas de NetworkPolicy fine.
- Le scaling à zéro est un avantage (charge très variable, idle prolongé).
- La courbe d’apprentissage est un blocage : l’équipe veut livrer vite, pas apprendre Kubernetes pendant 3 mois.
Basculer vers Kubernetes managé (EKS, AKS, GKE, OKS) quand
Section intitulée « Basculer vers Kubernetes managé (EKS, AKS, GKE, OKS) quand »- Plus de 10 services interconnectés avec dépendances complexes.
- Une équipe DevOps existe et maîtrise (ou veut maîtriser) Kubernetes.
- Besoin réseau avancé : service mesh, mTLS, NetworkPolicy, ingress complexe avec WAF.
- Charge de base élevée et stable : à partir d’un certain volume continu, Kubernetes managé devient moins cher que CaaS sans orchestrateur.
- Souveraineté technologique exigée : plusieurs fournisseurs souverains européens proposent une offre Kubernetes managé (par exemple OKS Outscale, OVHcloud Managed Kubernetes, Scaleway Kapsule), ce qui permet de combiner orchestrateur standard et juridiction nationale.
Le piège des deux mondes
Section intitulée « Le piège des deux mondes »Le piège classique est d’alterner entre les deux modèles sans cohérence : Cloud Run pour le service A, Kubernetes pour le service B, ECS Fargate pour le service C, sous prétexte que chaque équipe choisit son outil préféré. Le résultat est une fragmentation opérationnelle qui multiplie la dette : trois mécanismes de déploiement, trois systèmes d’observabilité, trois approches IAM, trois pipelines CI/CD. Sur le terrain, cette fragmentation coûte plus cher que la complexité que Kubernetes apporterait dès le départ.
8. Choisir entre CaaS sans orchestrateur et Kubernetes managé
Section intitulée « 8. Choisir entre CaaS sans orchestrateur et Kubernetes managé »Le choix entre CaaS sans orchestrateur et Kubernetes managé dépend de la taille de l’équipe, de la complexité applicative et du niveau d’expertise opérationnelle disponible. Aucun des deux modèles n’est meilleur dans l’absolu — ils répondent à des profils différents.
Comprendre le coût d’apprentissage. Un cluster Kubernetes managé impose une courbe d’apprentissage non négligeable : manifestes YAML, observabilité dédiée, pipeline CI/CD avec validation. Pour une petite équipe avec peu de services, ce coût est important par rapport à ce qu’un CaaS sans orchestrateur (offres simples des hyperscalers et fournisseurs souverains) apporterait nativement. Pour une équipe DevOps autonome avec un parc de services qui croît, ce coût devient un investissement amorti.
Évaluer la portabilité réelle. L’argument du lock-in pousse parfois à choisir Kubernetes par défaut. Dans les faits, une image OCI déployée sur un CaaS sans orchestrateur reste portable : elle peut être déployée plus tard sur Kubernetes sans réécriture, et inversement. La portabilité tient au standard OCI, pas à l’orchestrateur. Le lock-in d’un CaaS bien choisi reste donc limité, et ne justifie pas à lui seul de partir directement sur Kubernetes.
Définir les critères de bascule. Les profils où Kubernetes managé devient pertinent combinent généralement plusieurs critères : nombre de services au-delà d’une dizaine, équipe DevOps autonome, besoins réseau avancés (service mesh, ingress complexe, NetworkPolicy), charge stable et élevée où la facturation Kubernetes devient compétitive, exigence de souveraineté sur l’orchestrateur lui-même.
Bonnes pratiques pour une organisation cohérente :
- Démarrer simple lorsque l’équipe est petite et le parc applicatif limité, en privilégiant les modèles CaaS sans orchestrateur.
- Documenter les critères de bascule vers Kubernetes managé pour ne pas migrer par mode mais par besoin objectivé.
- Limiter la fragmentation : éviter d’avoir trois mécanismes d’exécution différents (CaaS A, CaaS B, Kubernetes) sans politique explicite, car l’effort opérationnel se cumule.
À retenir
Section intitulée « À retenir »- Le CaaS est le modèle où on apporte une image OCI et le fournisseur orchestre, avec deux familles : sans orchestrateur visible et Kubernetes managé.
- La portabilité OCI est le grand atout : pas de SDK propriétaire, l’image tourne identique sur tout fournisseur compatible.
- CaaS sans orchestrateur convient aux équipes < 3 ops, < 10 services, besoin réseau simple.
- Kubernetes managé s’impose dès qu’on dépasse ces seuils, ou pour les besoins réseau avancés et la souveraineté.
- Cinq pièges classiques : cold start scale-from-zero, coût idle 1 instance, networking limité hors K8s, image bloatée, observabilité médiocre par défaut.
- Le choix entre les deux modèles dépend de la taille d’équipe, de la complexité applicative et de l’expertise DevOps disponible — pas d’un défaut universel.