Principes cloud native : immutabilité, déclaratif, observabilité

Une application cloud native n’est pas simplement une application déployée dans le cloud. C’est une application conçue pour tirer parti des environnements distribués : elle se déploie en conteneurs, communique via des API, se met à jour sans interruption et se répare toute seule. Ce guide détaille les grands principes qui distinguent le cloud native de l’approche traditionnelle, en restant aligné avec le vocabulaire de la CNCF et de la certification KCNA.

Ce que vous allez apprendre

Les grands principes d’une architecture cloud native (conteneurisation, automatisation, déclaratif, faible couplage, immutabilité, observabilité)
La différence entre monolithe, monolithe modulaire et microservices
Ce qu’est l’infrastructure immuable et pourquoi c’est important
Les 12-factor apps : une base solide pour la portabilité
Le rôle des API déclaratives dans Kubernetes et GitOps
Les standards ouverts (OCI, CRI, CNI, CSI) et l’interopérabilité

Les grands principes d’une architecture cloud native

On retrouve très souvent ces grands principes et technologies dans les architectures cloud native modernes :

Principe	Idée clé
Conteneurisation	Empaqueter l’application avec ses dépendances dans une unité portable et standard
Automatisation	Déployer, mettre à jour et opérer sans action manuelle (CI/CD, GitOps, IaC)
Déclaratif	Décrire l’état souhaité plutôt que les étapes pour y arriver
Faible couplage	Faire évoluer les composants indépendamment grâce à des interfaces claires
Immutabilité	Remplacer plutôt que modifier en place — chaque changement produit une nouvelle version
Observabilité	Comprendre le système en temps réel par les logs, les métriques et les traces distribuées

Le résultat visé est un système aux propriétés suivantes :

Résilient : les pannes sont attendues et gérées automatiquement (self-healing)
Scalable : chaque composant peut être ajusté indépendamment selon la charge
Gérable : les opérations sont automatisées et reproductibles
Observable : métriques, logs et traces permettent de diagnostiquer les problèmes rapidement
Sécurisé : les communications sont chiffrées, les identités vérifiées, les politiques appliquées

Au-delà des principes : patterns et capacités avancées

Ces principes de base se déclinent ensuite en patterns architecturaux et capacités plus spécifiques :

Pattern / Capacité	Rôle	Quand l’envisager
Microservices	Style architectural qui découpe l’application en services indépendants	Quand plusieurs équipes travaillent sur des domaines métier distincts
Service mesh	Couche réseau dédiée qui gère la communication, la sécurité (mTLS) et l’observabilité entre services	Quand le nombre de services et la complexité réseau le justifient
Serverless	Modèle d’exécution où le code s’exécute à la demande, sans gérer l’infrastructure	Pour les traitements événementiels, les fonctions ponctuelles

Ces patterns ne sont pas des prérequis pour faire du cloud native. Ce sont des options à adopter quand le contexte le justifie.

Du monolithe aux microservices

L’architecture monolithique

Un monolithe, c’est une application où tout le code vit dans un seul bloc déployable. Imaginez un restaurant où un seul cuisinier prépare l’entrée, le plat et le dessert : si le cuisinier est malade, le restaurant ferme.

Avantages du monolithe :

Simple à développer et à déployer au démarrage
Pas de latence réseau entre les composants
Transactions plus faciles (une seule base de données)
Moins de complexité opérationnelle

Le monolithe modulaire : le compromis réaliste

Entre le monolithe classique et les microservices, il existe une marche intermédiaire souvent sous-estimée : le monolithe modulaire. L’application reste un seul déployable, mais le code est organisé en modules bien séparés, avec des frontières claires entre domaines métier.

C’est souvent le meilleur point de départ pour un projet neuf ou une petite équipe. Vous bénéficiez de la simplicité opérationnelle du monolithe (un seul déploiement, une seule base, pas de réseau inter-services) tout en préparant le terrain pour une extraction future de services si le besoin se confirme.

L’architecture microservices

Les microservices découpent l’application en services indépendants. Dans une architecture microservices mature, chaque service tend à maîtriser ses propres données et à limiter le partage direct de schéma avec les autres services. Ce n’est pas toujours « une base par service » au sens strict, mais une recherche d’autonomie de données et de frontières de responsabilité claires.

Reprenons l’analogie du restaurant : c’est un restaurant avec un chef pâtissier, un chef saucier et un chef rôtisseur. Si le pâtissier est absent, le restaurant fonctionne toujours (sans dessert).

Avantages des microservices :

Scalabilité indépendante : on scale uniquement le service qui en a besoin
Déploiement indépendant : une mise à jour du service de paiement n’affecte pas le catalogue
Équipes autonomes : chaque équipe gère son service de bout en bout
Liberté technologique : le service de recommandation peut être en Python, le service commande en Go

Quand choisir quoi ?

Critère	Monolithe	Monolithe modulaire	Microservices
Taille de l’équipe	< 5 développeurs	5-15 développeurs	> 15 développeurs, plusieurs équipes
Complexité du domaine	Un seul domaine simple	Plusieurs domaines identifiés	Domaines matures avec frontières claires
Fréquence de déploiement	Mensuelle	Hebdomadaire	Plusieurs fois par jour
Besoin de scalabilité	Uniforme	Principalement uniforme	Différencié par service
Budget ops	Limité	Limité	Équipe plateforme dédiée
Recommandation	Prototype, MVP	Défaut pour la plupart des projets	Organisations matures avec des besoins prouvés

Communication entre services : synchrone vs asynchrone

Dans une architecture microservices, les services communiquent de deux manières :

Synchrone (REST, gRPC) : le service A appelle B et attend la réponse. Simple, mais risque d’effet cascade si un service est lent.
Asynchrone (files de messages, event streaming) : le service A publie un message et continue sans attendre. Les services sont découplés dans le temps — si B tombe, les messages s’accumulent et seront traités à son retour.

Le choix entre synchrone et asynchrone dépend du niveau de couplage acceptable et des garanties de latence requises. En général, on utilise le synchrone pour les requêtes qui nécessitent une réponse immédiate (affichage d’une page), et l’asynchrone pour les traitements en arrière-plan (envoi d’e-mails, génération de rapports).

Infrastructure immuable

Le problème de la mutabilité

Traditionnellement, on gère les serveurs comme des animaux de compagnie (pets) : on leur donne un nom, on les met à jour manuellement, on les répare quand ils tombent malades. Le problème ? Après des mois de mises à jour et correctifs, chaque serveur est unique — impossible de reproduire exactement le même environnement.

C’est le configuration drift : l’état réel du serveur diverge de ce qui est documenté. Et un jour, un serveur qui semblait identique aux autres se comporte différemment en production.

L’approche immuable

En infrastructure immuable, les serveurs sont du bétail (cattle) : anonymes, interchangeables, remplaçables. Au lieu de modifier un serveur existant, vous :

Construisez une nouvelle image avec les changements souhaités (conteneur Docker, AMI, image VM)
Déployez la nouvelle version à côté de l’ancienne
Basculez le trafic vers la nouvelle version
Détruisez l’ancienne une fois la bascule validée

Avantages concrets

Aspect	Mutable (traditionnel)	Immuable (cloud native)
Mise à jour	SSH + apt upgrade + espérer	Nouvelle image → déploiement → rollback si erreur
Reproductibilité	« Ça marchait avant le patch de mardi »	L’image v2.3.1 est identique partout
Rollback	Complexe, parfois impossible	Redéployer l’image précédente
Audit	Qui a changé quoi, quand ?	Chaque version est tracée dans Git
Scalabilité	Cloner et prier	Lancer N instances de la même image

Infrastructure as Code (IaC)

L’infrastructure immuable va de pair avec l’Infrastructure as Code : votre infrastructure est définie dans des fichiers versionnés (Terraform, Pulumi, Crossplane). Chaque changement passe par Git → revue de code → CI/CD → déploiement. Pas de SSH, pas de modification manuelle.

Les 12-Factor Apps

Les 12-Factor Apps sont un ensemble de 12 règles formulées par Heroku en 2011 et ouvertes en open source en 2024. Elles décrivent comment construire des applications portables, scalables et exploitables en tant que service. Elles restent une excellente base pour concevoir une application cloud-ready.

Les 12 facteurs expliqués

#	Facteur	Règle	Exemple concret
1	Codebase	Un repo Git = une application	Pas de monorepo mélangeant 3 apps différentes
2	Dependencies	Déclarer explicitement les dépendances	`requirements.txt`, `package.json`, `go.mod`
3	Config	Configuration dans l’environnement	Variables d’environnement, ConfigMaps Kubernetes
4	Backing services	Traiter les services tiers comme des ressources attachables	La base de données est une URL, changeable sans code
5	Build, release, run	Séparer build, release et exécution	CI build → image Docker → déploiement Kubernetes
6	Processes	L’app s’exécute en processus stateless	Pas de données en mémoire entre les requêtes
7	Port binding	L’app exporte ses services via un port	Le conteneur écoute sur un port, le Service Kubernetes route
8	Concurrency	Scaler en multipliant les processus	HPA Kubernetes augmente le nombre de pods
9	Disposability	Démarrage rapide, arrêt propre	Le conteneur démarre en secondes, gère SIGTERM
10	Dev/prod parity	Environnements identiques	Même image Docker en dev, staging et prod
11	Logs	Traiter les logs comme des flux d’événements	Écrire sur stdout, collecter avec Fluentd
12	Admin processes	Exécuter les tâches admin comme des processus one-off	Migrations via un Job Kubernetes, pas un SSH

Limites des 12-factor

Les 12-factor apps restent une excellente base pour penser portabilité, configuration et exploitation. Mais elles ne couvrent pas à elles seules toute l’architecture cloud native moderne :

Orchestration : la gestion du cycle de vie des conteneurs (scheduling, scaling, self-healing) n’est pas abordée
Sécurité : les politiques d’accès, le chiffrement des communications, la gestion des secrets vont au-delà du Factor 3
Workloads stateful : les bases de données, les systèmes de fichiers distribués et les caches ont des contraintes que le Factor 6 (stateless) ne résout pas seul
Observabilité : métriques, traces distribuées et alerting ne sont pas couverts par le Factor 11 (logs)

Ce sont des compléments à chercher dans l’écosystème cloud native (Kubernetes, Prometheus, OPA, service mesh) plutôt que des lacunes des 12-factor elles-mêmes.

API déclaratives

Impératif vs déclaratif

C’est l’une des différences les plus importantes du cloud native.

Impératif : vous donnez les étapes pour arriver au résultat. « Crée un conteneur nginx, expose le port 80, lance 3 réplicas. »
Déclaratif : vous décrivez l’état souhaité et le système s’en occupe. « Je veux 3 réplicas de nginx sur le port 80. Débrouille-toi. »

Kubernetes fonctionne de manière déclarative : vous écrivez un manifeste YAML qui décrit l’état désiré, et les contrôleurs Kubernetes s’assurent en permanence que l’état réel correspond.

# Exemple déclaratif : je déclare ce que je veux
apiVersion: apps/v1
kind: Deployment
metadata:
  name: mon-app
spec:
  replicas: 3          # Je veux 3 réplicas
  selector:
    matchLabels:
      app: mon-app
  template:
    metadata:
      labels:
        app: mon-app
    spec:
      containers:
        - name: app
          image: mon-app:v2.1  # Je veux cette version
          ports:
            - containerPort: 8080

La boucle de réconciliation

Kubernetes utilise une boucle de réconciliation permanente :

Observer l’état actuel du cluster (combien de pods tournent ?)
Comparer avec l’état souhaité (le manifeste dit 3 réplicas)
Agir si nécessaire (créer ou supprimer des pods pour atteindre 3)
Recommencer en boucle (toutes les quelques secondes)

Si un pod crashe, Kubernetes en relance un automatiquement — sans intervention humaine. C’est le fondement de la self-healing (auto-réparation).

Observabilité : comprendre son système en temps réel

L’observabilité (observability) est la capacité à comprendre l’état interne d’un système en examinant ses sorties. Dans un environnement distribué avec des dizaines de services, on ne peut plus se contenter de « regarder les logs d’un seul serveur ».

Les trois piliers de l’observabilité

Pilier	Ce que c’est	Outil CNCF de référence
Métriques	Valeurs numériques mesurées dans le temps (CPU, latence, taux d’erreur)	Prometheus (Graduated)
Logs	Événements textuels horodatés émis par les applications	Fluentd / Fluent Bit (Graduated)
Traces distribuées	Suivi d’une requête à travers plusieurs services	OpenTelemetry (Graduated), Jaeger (Graduated)

OpenTelemetry (OTel) est le projet CNCF qui unifie la collecte de ces trois signaux dans un framework unique. Il remplace les anciens projets OpenTracing et OpenCensus.

Pourquoi c’est un principe, pas un outil

L’observabilité n’est pas « installer Prometheus ». C’est une propriété du système qui se construit dès la conception :

Les applications écrivent leurs logs sur stdout (Factor 11)
Les services exposent des métriques sur un endpoint dédié (/metrics)
Les requêtes sont instrumentées avec des traces (headers de corrélation)

Sans observabilité, le débogage en production distribué relève du hasard.

Standards ouverts et interopérabilité

Le cloud native n’est pas seulement une architecture technique. C’est aussi un écosystème ouvert, standardisé et interopérable, porté par des fondations et des projets open source. La CNCF et la certification KCNA insistent sur la compréhension de cet écosystème au-delà des seuls outils.

Les interfaces standardisées de Kubernetes

Kubernetes est conçu pour être extensible grâce à des interfaces standardisées. Chaque interface permet de remplacer un composant sans modifier le reste :

Interface	Rôle	Exemples d’implémentations
OCI (Open Container Initiative)	Format d’images conteneur, runtime, distribution	Docker, containerd, Podman
CRI (Container Runtime Interface)	Communication kubelet ↔ runtime conteneur	containerd, CRI-O
CNI (Container Network Interface)	Réseau des pods (communication, politiques réseau)	Flannel, Calico, Cilium
CSI (Container Storage Interface)	Stockage persistant pour les pods	Longhorn, Ceph, AWS EBS

Pourquoi c’est important

Ces standards garantissent que :

Vous n’êtes pas verrouillé (vendor lock-in) avec un fournisseur unique
Vous pouvez remplacer containerd par CRI-O, Flannel par Cilium, sans refaire votre cluster
L’innovation progresse en parallèle sur chaque couche sans tout casser
Les certifications (CKA, CKAD, CKS) testent la compréhension de ces interfaces, pas d’un outil spécifique

C’est le loose coupling appliqué à l’infrastructure elle-même.

Loose coupling : le fil conducteur

Le loose coupling (couplage faible) est le principe transversal qui relie tous les autres. Dans un système faiblement couplé, chaque composant :

Expose une interface claire (API REST, gRPC, événements) sans révéler ses détails internes
Peut être remplacé par une alternative compatible (changer de base de données, de runtime)
Évolue à son rythme : on déploie le service A sans toucher au service B
Tombe en panne isolément : une erreur dans le service de stockage n’affecte pas le service de paiement

Ce principe se retrouve à tous les niveaux :

Code : des services faiblement couplés communiquent via des API
Infrastructure : les standards OCI, CRI, CNI, CSI permettent de remplacer n’importe quel composant
Organisation : les équipes autonomes travaillent indépendamment grâce à des contrats d’interface clairs

À retenir

Le cloud native repose sur des grands principes (conteneurisation, automatisation, déclaratif, faible couplage, immutabilité, observabilité) — pas sur une liste figée de technologies
Les microservices, le service mesh et le serverless sont des patterns à adopter quand le contexte le justifie, pas des prérequis
Le monolithe modulaire est souvent le meilleur point de départ pour un nouveau projet
L’infrastructure immuable élimine le configuration drift : on remplace au lieu de modifier
Les 12-factor apps sont une excellente base pour la portabilité, mais ne couvrent pas à elles seules l’orchestration, la sécurité ou l’observabilité
Les API déclaratives et la boucle de réconciliation Kubernetes permettent la self-healing et l’automatisation
Les standards ouverts (OCI, CRI, CNI, CSI) garantissent l’interopérabilité et évitent le vendor lock-in
Ce guide couvre les principes ; le guide Écosystème CNCF détaille les projets majeurs

Prochaines étapes

Écosystème CNCF Comprendre la fondation, la gouvernance et naviguer le CNCF Landscape

Guide de préparation KCNA Stratégie et parcours pour réussir la certification KCNA

Introduction à Kubernetes Découvrir l'orchestrateur qui implémente ces principes

Concepts Docker Comprendre conteneurs et images, la brique de base du cloud native