Cloud Native Platform - 2026
Rendre le cloud invisible aux développeurs.
CNP est une plateforme de développement interne (IDP) que j'ai conçue et implémentée en tant que lead technique, avec une équipe de 6 personnes sur 5 mois (février-juillet 2026, EPITA SIGL). J'ai porté la quasi-totalité de l'infrastructure : les 4 plans fonctionnels, le cluster Kubernetes et son GitOps, ainsi que le HomeLab OpenStack privé.
Résultat concret : un développeur, junior ou expert, déploie une application complète (dépôt Git, CI/CD, base de données, secrets, SSO, DNS) en 3 minutes en autonomie, sans jamais recevoir d'accès direct au cluster.

Contexte & Contraintes
Pourquoi construire une plateforme cloud native ?
4 réalités ont guidé nos choix d'architecture :
- Productivité & Time-to-Market : déploiement en autonomie en 3 minutes au lieu de plusieurs jours, avec un onboarding accéléré (moins d'une heure, assisté par IA).
- Atténuation des risques : la sécurité est appliquée par défaut à tous les projets, avec un RBAC strict (owner / admin / guest).
- Maîtrise des coûts (FinOps) : chaque équipe voit ce que lui coûte réellement son application et peut fixer un budget.
- Gouvernance & auditabilité : toute action de déploiement est tracée (qui, quoi, quand) pour faciliter les audits sans ralentir les équipes.
Donner à nos développeurs l'autonomie, à l'entreprise la sécurité, et aux équipes finance la maîtrise des coûts, dans une seule plateforme.
Architecture technique
Un orchestrateur d'orchestrateurs, Git comme source de vérité
La CMP ne parle jamais directement à l'API Kubernetes pour déployer une app. Elle orchestre 4 plans fonctionnels bien séparés :
- Control Plane (Next.js + FastAPI) : capte l'intention du développeur et orchestre les tâches via un pattern Saga.
- Provisioning Plane (Terraform) : isole le contexte, génère un jeton GitHub éphémère, configure Keycloak, Vault et DNS.
- Delivery Plane (ArgoCD + Helm) : synchronise en continu le cluster K3s depuis les dépôts Git applicatifs.
- Security & Network Plane (Cilium, Envoy Gateway, Vault) : impose l'isolation réseau et l'authentification à chaque requête.
Chaque plan écrit son état dans Git, qui reste l'unique source de vérité de la plateforme : un simple commit suffit pour un déploiement reproductible, sans accès cluster ni ticket d'infrastructure.


Sécurité & isolation multi-tenant
Isolation Zero-Trust au niveau réseau, identité et secrets
4 niveaux de sécurité indépendants, chacun avec ses propres frontières :
- Réseau : Cilium en default-deny, seul le trafic intra-projet et la Gateway peuvent passer.
- Edge : Envoy Gateway vérifie les groupes du token JWT avant même de router la requête.
- Identité : SSO Keycloak avec MFA obligatoire dès la première connexion.
- Secrets : policy Vault scopée par projet, liée au rôle Kubernetes Auth du namespace.
Une tentative d'un tenant d'atteindre un autre est bloquée par Cilium au niveau réseau, avant même d'atteindre l'application visée.
Isolation logique
Un groupe Keycloak, une frontière partout
Le groupe Keycloak d'un projet se propage jusqu'à la policy Vault, l'AppProject ArgoCD et l'organisation Grafana : un seul point de vérité pour toute la chaîne d'isolation.
100% des modifications sont auditables et tracées : même un accès légitime à un projet n'ouvre aucune porte vers un autre.


Self-service
Un parcours pour chaque niveau, sans jamais perdre personne
Chaque équipe est un projet isolé (Keycloak, Vault, ArgoCD) avec des rôles clairs :
- Chef de projet (Owner) : crée le projet, gère les membres, suit les coûts de déploiement de son équipe.
- Développeur (Admin) : SSO + MFA, déploie via le catalogue ou en Git direct, assistance IA via MCP.
- Invité (Viewer) : lecture seule sur les ressources dont il a besoin.
Templates applicatifs, identité & SSO, base managée, secrets zero-plaintext, sauvegardes S3 continues et auto-sleep FinOps sont prêts dès le Day-0 : rien ne s'improvise en prod.
Infrastructure
Le HomeLab : un vrai cluster OpenStack, chez moi
Le cluster Kubernetes de CNP ne tourne pas sur un cloud public : il tourne sur un cluster OpenStack privé que j'héberge et j'administre personnellement, chez moi, facture d'électricité et abonnement compris, environ 200$/an tout compris.
OpenStack permet la migration à chaud d'une VM d'un nœud à un autre sans interrompre le service : c'est ce qui a permis d'ajouter de la RAM ou de faire de la maintenance matérielle sans jamais couper la plateforme.
Le Provisioning Plane reste agnostique du provider (pattern Strategy) : le même modèle Terraform sait cibler ce K3s auto-hébergé aussi bien que des VMs AWS ou OpenStack legacy. Chantier en cours pour le prochain semestre : étendre cette indépendance à AWS et GCP, pour ne plus dépendre d'un site unique.


Initiative personnelle
Offhours-Guard
Un opérateur Kubernetes que j'ai développé de ma propre initiative pour arrêter automatiquement les environnements hors-production la nuit et le week-end, avec un réveil manuel en un clic. Déployé sur la majorité des applications non-critiques de la plateforme.
Fiabilité
2 incidents réels, et un plan pour quand ça casse
Une canicule a provoqué une surcharge du cluster : infrastructure down ≤1h, corrigée par ajout de RAM et nettoyage des flux de refroidissement.
Une migration à chaud OpenStack a ensuite été menée sans coupure de service.
Dépendance assumée aujourd'hui : un site unique chez moi, avec Bouygues Telecom et EDF comme points de défaillance uniques. C'est précisément l'enjeu du chantier multi-cloud.

Chiffres clés
Voir tous
99,7%
de disponibilité cible (SLA interne assumé).

≤1h
de temps de reprise engagé par incident, grâce à la reconstruction GitOps depuis Git.

100%
des modifications sont auditables et tracées, chaque déploiement passant par un commit.

Choix techniques assumés
Ce qu'on aurait pu faire autrement, et pourquoi on ne l'a pas fait
- GitOps intégral plutôt qu'un contrôleur Kubernetes direct : plus lent à écrire, mais la traçabilité complète et la capacité à tout reconstruire depuis Git seul l'ont emporté.
- Isolation Project > Application plutôt qu'un simple namespace : un namespace par app aurait suffi techniquement, mais ne collait pas à l'organisation réelle des équipes.
- Stratégie multi-provider (pattern Strategy) plutôt qu'un provider unique : coder en dur pour K3s aurait été plus simple à court terme, mais empêchait de migrer une VM legacy sans rien casser côté développeur.
Bilan
Plus qu'un outil technique : un standard d'entreprise
- Vitesse & autonomie : de plusieurs jours d'attente à 3 minutes, sur tout le cycle de vie (Day-0 et Day-2).
- Sécurité & gouvernance : 100% des modifications auditables et tracées, dans un cadre Zero-Trust standardisé.
- Maîtrise financière : jusqu'à -70% de coûts sur les environnements hors-production.
On a construit bien plus qu'un outil technique : un véritable standard d'entreprise, prêt à passer à l'échelle et à intégrer les innovations de demain (IA/MCP).
