“Si vous voulez être Cloud-Native, vous devez migrer sur AWS.”

J’ai entendu cette phrase une dizaine de fois ces 3 dernières années. De la bouche de commerciaux cloud, de consultants, et même de certains architectes.

C’est faux.

Cloud-Native ≠ Cloud Public. Ce sont deux concepts différents, même s’ils sont souvent confondus dans le marketing des fournisseurs cloud.

Chez plusieurs clients, j’ai déployé une plateforme Cloud-Native complète — 100% on-premise. Kubernetes, microservices, GitOps, observabilité distribuée. Tout y est. Sans un seul serveur AWS, Azure ou GCP.

Dans cet article, je vais clarifier la différence entre Cloud-Native et Cloud Public, expliquer pourquoi on peut être moderne sans aller dans le cloud, et partager le retour d’expérience complet du déploiement Kubernetes on-premise.

1. La confusion marketing : Cloud-Native = Cloud Public ?

Le terme “Cloud-Native” a été popularisé par la CNCF (Cloud Native Computing Foundation). Voici leur définition officielle :

Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds.

Notez bien : “public, private, and hybrid clouds”.

Nulle part il n’est écrit “must run on AWS/Azure/GCP”. Le Cloud-Native, ce sont des pratiques architecturales, pas une obligation d’infrastructure.

Pourtant, le marketing des fournisseurs cloud a réussi à créer cette confusion :

• “Cloud-Native” sonne comme “Cloud” → donc “Cloud Public”
• Les success stories mises en avant sont souvent sur AWS EKS, Azure AKS, GCP GKE
• Les outils Cloud-Native (Kubernetes, Docker, etc.) sont présentés comme “faits pour le cloud”

Résultat : beaucoup de CTOs et DSI pensent qu’adopter Kubernetes = migrer dans le cloud.

C’est une erreur stratégique qui peut coûter cher (en argent, en souveraineté, en performance).

2. Qu’est-ce que le Cloud-Native, vraiment ?

Cloud-Native, c’est une philosophie de conception et de déploiement d’applications, basée sur 6 piliers :

Les 6 piliers Cloud-Native (indépendants de l’infrastructure)

1. Conteneurisation

Applications packagées en containers Docker (ou OCI-compliant). Ce Dockerfile fonctionne identiquement on-premise ou dans le cloud :

FROM node:18-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
EXPOSE 8080
CMD ["node", "server.js"]

2. Orchestration

Kubernetes pour gérer le cycle de vie des containers. Ce manifest YAML est le même on-premise que sur AWS EKS :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
  namespace: production
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: app
        image: my-app:1.2.5
        ports:
        - containerPort: 8080
        resources:
          requests:
            cpu: 500m
            memory: 512Mi
          limits:
            cpu: 1000m
            memory: 1Gi

3. Microservices

Architecture découplée : chaque service a sa responsabilité, son déploiement indépendant, sa scalabilité propre. Communication via APIs (REST, gRPC).

4. Infrastructure as Code (IaC)

Infrastructure déclarative : Terraform, Ansible, Kubespray. Pas de configuration manuelle “à la souris”.

5. CI/CD & GitOps

Déploiements automatisés via pipelines. GitOps (ArgoCD, Flux) : Git = source de vérité, rollback = git revert.

6. Observabilité

Monitoring (Prometheus, Grafana), logging (Loki, ELK), tracing (Jaeger, Tempo). Identique on-premise ou cloud.

Ce que Cloud-Native N’EST PAS :

• ❌ Obligation d’utiliser AWS/Azure/GCP
• ❌ Nécessite obligatoirement le cloud public
• ❌ Incompatible avec on-premise

Ce que Cloud-Native EST :

• ✅ Ensemble de pratiques architecturales
• ✅ Philosophie de design d’applications modernes
• ✅ Patterns de déploiement et d’exploitation
• ✅ Compatible on-premise, cloud public, hybrid

3. Cloud Public vs Cloud-Native : tableau comparatif

Clarifions une bonne fois pour toutes :

Conclusion : On peut être Cloud-Native on-premise.

4. Pourquoi choisir Cloud-Native on-premise ?

On ne choisit pas l’on-premise par nostalgie des datacenters. On le choisit pour des raisons stratégiques, économiques et techniques.

Raison 1 : Souveraineté et conformité

Use cases critiques :

• Données sensibles : Santé (HIPAA), finance, défense
• RGPD : Data residency en Europe obligatoire
• Secteurs régulés : Énergie, industrie critique, recherche

Exemple clients :

• Secteur deep tech (stratégique pour l’Europe)
• Données industrielles hautement sensibles (process de fabrication, R&D)
• Obligation réglementaire : infrastructure en France/Europe
• Cloud public = complexité data residency, risque juridique
• Solution : Kubernetes on-premise

Raison 2 : Coûts maîtrisés sur le long terme

Contrairement à l’idée reçue, on-premise peut être plus économique.

Calcul réaliste (workload moyen)

Contexte : 100 VMs, 400 vCPU, 1 TB RAM, 50 TB storage

Cloud public (AWS EC2 reserved instances) :

• Coût mensuel : ~15 000 - 20 000 €
• Coût annuel : ~180 000 - 240 000 €
• Sur 3 ans : ~540 000 - 720 000 €

On-premise (serveurs Dell/HP) :

• CapEx initial : ~200 000 - 300 000 € (serveurs, réseau, storage)
• OpEx annuel : ~50 000 € (électricité, refroidissement, maintenance)
• Sur 3 ans : ~350 000 - 450 000 €

Économie : ~200 000 - 300 000 € sur 3 ans (soit -35% à -40%)

Quand l’on-premise est plus économique :

• ✅ Workloads stables (pas de pics imprévisibles)
• ✅ Vision long terme (3+ ans)
• ✅ Utilisation élevée (pas de ressources idle)
• ✅ Pas besoin de scalabilité élastique infinie

Note FinOps : Les egress fees (coûts de sortie de données) du cloud public peuvent exploser la facture si vous transférez beaucoup de données (Big Data, ML, analytics).

Raison 3 : Latence et performance

Pour certains workloads, la latence est critique.

Use cases :

• Industrie 4.0 : IoT, capteurs temps réel, contrôle-commande
• Edge computing : Usines, sites distants, retail
• Big Data : Traitement local de données massives

Exemple client :

• Data platform : Apache Kafka (ingestion), Apache Spark (processing)
• Données capteurs en temps réel
• Latence critique : < 100ms
• Cloud public = latence réseau WAN inacceptable (150-300ms)
• Solution : Kubernetes on-premise (co-localisé avec l’usine)

Raison 4 : Indépendance fournisseur (no vendor lock-in)

Le cloud public crée du lock-in via :

• Services managés propriétaires : RDS, Lambda, DynamoDB, etc.
• APIs spécifiques : difficile de migrer vers un autre cloud
• Intégrations profondes : IAM, VPC, CloudWatch, etc.

Cloud-Native on-premise :

• Stack 100% open source : Kubernetes, Prometheus, Kafka, MinIO
• Portabilité totale : changement de fournisseur hardware facile
• Pas de dépendance : vous gardez le contrôle technique et stratégique

Raison 5 : Valoriser les compétences internes existantes

Beaucoup d’entreprises ont déjà :

• Équipes infra/ops compétentes
• Datacenters existants (coûts déjà amortis)
• Culture on-premise forte

Migrer vers le cloud = réapprendre tout (AWS certifications, nouveaux outils, nouveaux process).

Cloud-Native on-premise :

• Valorise les compétences existantes
• Modernise l’infra sans tout jeter
• Montée en compétences progressive (Kubernetes, GitOps)

5. Kubernetes on-premise : REX mission

Passons au concret. Voici le retour d’expérience complet du déploiement Kubernetes on-premise.

Contexte mission

Client :

• Startup deep-tech
• Nouvelles usines en construction
• Besoin : plateforme data moderne pour R&D et production

Objectifs :

• Data platform : ingestion, processing, stockage, analytics
• Kubernetes on-premise (souveraineté données industrielles)
• Multi-tenancy : isoler équipes data, ML, analytics
• Haute disponibilité (99.9%)
• GitOps : déploiements automatisés, rollback facile

Stack technique déployée

Infrastructure

• Bare metal servers (Dell PowerEdge)
• Storage distribué : MinIO (object S3-compatible)
• Networking : 10 Gbps, VLANs dédiés

Kubernetes

• Version : Kubernetes 1.28
• CNI : Calico (networking + network policies)
• Load balancer : MetalLB (bare metal, BGP mode)
• Ingress : NGINX Ingress Controller (TLS termination)

Pourquoi Kubespray ?

• Production-ready out-of-the-box
• Haute disponibilité native (etcd cluster, multi-master)
• Communauté active, documentation complète
• Pas de vendor lock-in (100% open source)

Data stack

• Apache Kafka : Ingestion événements temps réel
• Apache Spark : Processing distribué (PySpark)
• MinIO : Object storage S3-compatible (alternative AWS S3)
• PostgreSQL : Metadata, catalogues

Multi-tenancy

Besoin : isoler équipes (data engineering, data science, analytics) sans multiplier les clusters.

Solution : VCluster (Kubernetes dans Kubernetes)

# VCluster pour l'équipe Data Science
apiVersion: v1
kind: Namespace
metadata:
  name: team-datascience

---
apiVersion: storage.loft.sh/v1
kind: VirtualCluster
metadata:
  name: vcluster-datascience
  namespace: team-datascience
spec:
  helmRelease:
    chart:
      version: 0.15.2
    values:
      isolation:
        enabled: true
        networkPolicy:
          enabled: true

Avantages VCluster :

• Isolation forte (namespaces, RBAC, network policies)
• Overhead minimal (pas de duplication control plane physique)
• Autonomie équipes (chaque équipe = admin de son VCluster)

GitOps

ArgoCD pour déploiements automatisés :

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: kafka-cluster
  namespace: argocd
spec:
  project: data-platform
  source:
    repoURL: https://monfournisseurgit.com/monRepo
    targetRevision: main
    path: kafka/production
  destination:
    server: https://kubernetes.default.svc
    namespace: kafka
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

Workflow :

1. Développeur commit dans Git (manifest Kubernetes ou Helm)
2. ArgoCD détecte changement
3. ArgoCD applique changement automatiquement
4. Rollback = git revert + ArgoCD sync

Résultat : Zéro déploiement manuel, audibilité complète (Git log).

Observabilité

Stack LGTM (Loki, Grafana, Tempo, Mimir) :

• Tempo : Métriques (CPU, RAM, latences, throughput Kafka/Spark)
• Grafana : Dashboards (overview cluster, applications, infra)
• Loki : Logs centralisés (alternative ELK, plus léger)
• Mimir : Tracing centralisés (alternative ELK, plus léger)

Exemple alerting :

groups:
  - name: kafka
    interval: 30s
    rules:
      - alert: KafkaHighLatency
        expr: kafka_producer_request_latency_avg > 500
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Kafka producer latency élevée (> 500ms)"
          description: "Topic {{ $labels.topic }} latence {{ $value }}ms"

Défis rencontrés (et solutions)

Défi 1 : Networking bare metal

Problème : Pas de cloud load balancer (ELB AWS, Azure LB). Comment exposer services ?

Solution : MetalLB (L2 ou BGP mode)

apiVersion: v1
kind: ConfigMap
metadata:
  namespace: metallb-system
  name: config
data:
  config: |
    address-pools:
    - name: production
      protocol: bgp
      addresses:
      - 10.0.10.0/24
    bgp-advertisements:
    - aggregation-length: 32
      localpref: 100

MetalLB attribue IPs publiques aux services type: LoadBalancer, et annonce routes via BGP aux routeurs réseau.

Défi 2 : Storage distribué

Problème : Pas de EBS (AWS) ou Azure Disks. Besoin de storage haute dispo, performant.

Solution :

• Ceph RBD (block storage, PersistentVolumes Kubernetes)
• MinIO (object storage, S3-compatible)

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: spark-data
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: ceph-rbd
  resources:
    requests:
      storage: 500Gi

Performance tuning : ajustement CRUSH map Ceph, réplication 3x, SSD NVMe.

Défi 3 : Multi-tenancy sans multiplier clusters

Problème : 10 équipes = 10 clusters Kubernetes ? Complexité opérationnelle énorme.

Solution : VCluster (clusters virtuels)

Overhead minimal (~200 MB RAM par VCluster), isolation forte (namespaces + RBAC + network policies).

Défi 4 : Backup & Disaster Recovery

Problème : Pas de snapshots cloud automatiques. Comment backup cluster Kubernetes ?

Solution : Velero (backup Kubernetes)

# Backup quotidien automatique
velero schedule create daily-backup \
  --schedule="0 2 * * *" \
  --include-namespaces=* \
  --snapshot-volumes=true \
  --ttl=720h

Velero backup :

• Manifests Kubernetes (Deployments, Services, ConfigMaps, etc.)
• PersistentVolumes (via snapshots Ceph)

Réplication cross-datacenter pour DR (disaster recovery).

Résultats (métriques réelles)

Performance

• Latence ingestion Kafka : < 50ms (p99)
• Throughput Spark : millions d’événements/sec
• Disponibilité cluster : 99.95% (sur 12 mois)
• Time to recovery (incident) : < 15 min (grâce à GitOps)

Coûts (comparaison cloud vs on-premise)

On-premise :

• CapEx initial : ~300 000 € (20 serveurs Dell + networking + storage)
• OpEx annuel : ~80 000 € (électricité, refroidissement, maintenance, 2 FTE ops)
• Total 3 ans : ~540 000 €

Équivalent cloud AWS (estimation) :

• EKS cluster (3 masters managés) : ~220 €/mois
• 20 workers (m5.4xlarge reserved) : ~10 000 €/mois
• EBS storage (50 TB) : ~5 000 €/mois
• S3 storage (100 TB) : ~2 500 €/mois
• Data transfer out (20 TB/mois) : ~1 500 €/mois
• Total mensuel : ~19 000 €/mois
• Total annuel : ~230 000 €
• Total 3 ans : ~690 000 €

Économie : ~150 000 € sur 3 ans (soit -22%)

ROI on-premise : 18 mois

Équipe

• 2 SRE (gestion cluster, monitoring, incidents)
• 10+ équipes data (utilisateurs de la plateforme)
• Autonomie déploiements : GitOps (ArgoCD) = zéro ticket ops pour déployer

Souveraineté

• 100% données en France
• Conformité RGPD totale
• Indépendance cloud public (zéro dépendance AWS/Azure/GCP)

Leçons apprises

✅ Ce qui a bien fonctionné

1. Kubespray : Déploiement K8s rapide (~2h), production-ready, communauté active
2. VCluster : Multi-tenancy simple, overhead minimal
3. GitOps (ArgoCD) : Déploiements sereins, rollback instantané, audibilité
4. Stack open source : Zéro lock-in, portabilité totale

⚠️ Défis à anticiper

1. Expertise Kubernetes nécessaire : Courbe d’apprentissage (3-6 mois)
2. Maintenance infra : Patchs OS, upgrades K8s, gestion hardware (responsabilité interne)
3. Scaling horizontal : Ajouter nodes = commander hardware (délai semaines)
4. Pas de services managés : Tout à gérer (Kafka, Spark, monitoring, etc.)

💡 Recommandations

1. Utiliser Kubespray : N’installez pas K8s manuellement (kubeadm trop complexe)
2. Start small : 3 masters + 5 workers, scalez après
3. Investir monitoring/alerting dès J1 : Prometheus + Grafana + Alertmanager
4. Former équipes : Kubernetes, GitOps, observabilité (formation 3-5 jours)
5. Documenter runbooks : Incident management, disaster recovery

6. Quand choisir Cloud-Native on-premise vs Cloud public ?

Pas de dogme. Le choix dépend de votre contexte.

Matrice de décision

Scénarios recommandés

✅ Choisir Cloud-Native on-premise si :

• Données sensibles (santé, finance, défense, industrie)
• Souveraineté / RGPD strict (data residency France/Europe)
• Workloads stables long terme (3+ ans)
• Latence critique (IoT, edge, temps réel, usines)
• Infrastructure existante (datacenters amortis)
• Équipe ops compétente (SRE, admins système)

Exemples :

• Industries (data platform industrielle)
• Hôpitaux (données patients HIPAA)
• Banques (données financières)
• Usines 4.0 (IoT temps réel)

✅ Choisir Cloud Public si :

• Startup (pas d’infra initiale, besoin go-fast)
• Workloads variables (pics Black Friday, événements)
• Global scale (multi-région worldwide)
• Time-to-market critique (lancement produit rapide)
• Petite équipe (pas d’ops dédiées, préfère managé)
• Services managés valorisés (RDS, Lambda, SageMaker, etc.)

Exemples :

• Startups SaaS (croissance rapide)
• E-commerce (pics saisonniers)
• Applications globales (millions users worldwide)

⚖️ Hybrid Cloud (mix des deux)

Exemple architecture :

• Front-end cloud public (CloudFront + S3, scalabilité web)
• Back-end on-premise (Kubernetes, données sensibles)
• Communication : VPN ou AWS Direct Connect

7. Conclusion : Cloud-Native peut tourner anywhere

Cloud-Native ≠ Cloud Public. C’est un état d’esprit architectural, pas une obligation d’aller sur AWS/Azure/GCP.

Nous avons déployé une plateforme Cloud-Native complète (Kubernetes, microservices, GitOps, observabilité) 100% on-premise. Résultat :

• ✅ Souveraineté données (100% France)
• ✅ Coûts maîtrisés (ROI 18 mois vs cloud)
• ✅ Performance optimale (latence < 50ms)
• ✅ Zéro vendor lock-in (stack open source)

Le vrai choix n’est pas “Cloud vs On-premise”, mais :

1. Quels sont mes besoins ? (souveraineté, latence, coûts, scalabilité)
2. Quelle architecture convient ? (Cloud-Native, oui !)
3. Où héberger ? (Cloud public, on-premise, ou hybrid)

Cloud-Native on-premise a du sens si :

• Données sensibles ou régulées
• Workloads stables long terme
• Latence critique
• Infrastructure existante valorisable

Ne vous laissez pas enfermer dans le discours “cloud-first” omniprésent. Analysez vos besoins, faites les calculs TCO, et choisissez l’environnement adapté.

Cloud-Native peut tourner anywhere. C’est ça, la vraie portabilité.

Vous hésitez entre Cloud Public et on-premise pour votre plateforme Cloud-Native ? Vous avez besoin d’un audit de votre architecture actuelle ?

PeriScop vous aide à faire le bon choix stratégique et vous accompagne dans l’implémentation (Kubernetes on-premise, cloud public, ou hybrid).