Platform Engineering 2.0 : construis ta paved road ou crève dans la boue
Golden paths, self-service portals, gouvernance encodée — comment sortir du portail magnifique que personne n'utilise.
Putain de temps perdu.
J’ai passé six mois à construire un portail interne magnifique. Backstage, plugins à gogo, catalogue de services complet, documentation interactive. Le genre de truc qui fait bander un architecte when he presents it en demo. “Regardez, on a un single pane of glass pour tout !”
Et tu sais ce qui s’est passé ? Personne ne l’a utilisé. Les développeurs continuaient à copier-coller des snippets tribaux, à ouvrir des tickets pour un Kafka topic, et à reverse-engineerer les bonnes pratiques à partir de vieux repos.
Le problème n’était pas l’outil. Le problème était que j’avais construit une brochure au lieu d’un outil. Un portail sans automatisation derrière, c’est juste un wiki avec de la couleur.
Bienvenue dans Platform Engineering 2.0. Ou comment arrêter de se palucher.
Lexique
C’est là mes définitions et si elles vous déplaisent, cassez-vous je suis pas là pour discuter lexique.
- IDP (Internal Developer Platform): couche self-service qui intègre infra, CI/CD, observabilité, sécurité — construite et maintenue par une équipe plateforme pour les développeurs.
- Golden Path: chemin opinionné, maintenu et documenté vers la production. Pas une contrainte — le meilleur chemin que les devs choisissent volontairement.
- Paved Road: terme de Netflix pour golden path. La route est pavée, plus rapide que les chemins de terre. Tu peux prendre la terre, mais ça va boueux.
- Backstage: portail open-source créé par Spotify, CNCF incubating project. 3000+ adopteurs. Framework, pas un produit.
- Self-Service: capacité à provisionner de l’infrastructure sans ticket, sans attendre, sans demander la permission.
- Policy-as-Code: politiques de sécurité et compliance encodées dans les pipelines et templates, pas dans des PDF qui dorment dans Confluence.
- DORA Metrics: 4 métriques qui mesurent la performance de delivery logicielle — Lead Time, Deployment Frequency, Change Failure Rate, MTTR.
- Agent Experience (AX): concept Gartner 2026 — préparer les systèmes backend pour servir des agents IA en plus des humains.
- Team Topologies: livre de Skelton & Pais qui définit les topologies d’équipe, dont la “Platform team” en mode X-as-a-Service.
Le constat qui fait mal
Gartner prédit que d’ici 2026, 80% des grandes orgs d’ingénierie auront des équipes de Platform Engineering. Contre 45% en 2022.
Le CNCF Q1 2026 Technology Radar le confirme :
- Helm, Backstage, kro en position “Adopt”
- 41% des organisations avec un modèle multi-équipes
- 35% en mode hybride pour les workloads IA
Bref, tout le monde saute dans le train. Mais la plupart des passagers ne savent même pas où le train va.
IDP 1.0 : le portail qui fait joli
La première génération avait un problème fondamental : elle confondait le portail avec la plateforme.
On a construit :
- Des catalogues de services riches
- Des portails de documentation interactifs
- Des dashboards de visibilité
Et ce qui manquait :
- Des golden paths qui exécutent réellement l’infrastructure
- De l’automatisation qui remplace les tickets
- De la gouvernance qui se vérifie elle-même
Résultat ? Les développeurs devaient encore reverse-engineerer les bonnes pratiques. Le portail est devenu une brochure. Un wiki avec du bling.
Tu connais ce moment où tu montres le portail en demo et tout le monde aplaudit, puis trois semaines plus tard tu regardes les logs et tu vois que 12 personnes sur 200 l’ont ouvert une fois ?
C’est ça, l’IDP 1.0.
La vraie différence : Portal IDP vs Execution IDP
Voilà la distinction que personne ne fait et qui change tout :
| Dimension | Portal IDP | Execution IDP |
|---|---|---|
| Verbes | Register, track, generate | Provision, deploy, scale, remediate |
| Rôle | Coordination | Exécution |
| Sécurité | Liens vers outils | Credentials + audit trail intégrés |
| Quand ça merde | Affiche le problème | Applique le fix, vérifie, rollback |
Un portal IDP te montre la porte. Un execution IDP traverse la porte et fait le travail.
Le piège : acheter un portail et croire que le moteur est inclus. C’est comme acheter un GPS sans voiture. Ça te dit où aller, mais ça te déplace pas.
Platform Engineering 2.0 : les cinq piliers
Le CNCF définit l’évolution vers PE 2.0 autour de cinq piliers :
1. Multi-Persona Experience
Au-delà des développeurs. La plateforme sert maintenant :
- Data scientists / ML engineers — GPU self-service, model registries
- Leaders business — Dashboards FinOps, métriques DORA
- Équipes sécurité — Policy-as-code enforcement
- Agents IA — Accès, scope, gouvernance propres
Oui, tu as bien lu. Les agents IA sont maintenant des consommateurs de ta plateforme. Bienvenue dans le futur.
2. Composable by Design
Capacités modulaires, API-first. Tu peux échanger Crossplane contre Terraform, ArgoCD contre Flux, sans tout casser. Le platform engineering, c’est pas du LEGO figé — c’est du LEGO où tu peux changer les pièces.
3. Governance as Code
Les politiques vivent dans l’infrastructure, pas dans des docs. OPA, Kyverno — tu codifies tes règles et la plateforme les enforce automatiquement.
Pas de “est-ce que quelqu’un a vérifié le network policy ?”. La plateforme vérifie. Toujours.
4. AI-Native Substrate
L’infrastructure doit être prête pour les workloads IA. GPU provisioning, routing de modèles, gouvernance des agents. C’est pas un nice-to-have en 2026 — c’est un must-have.
5. Cost Intelligence
FinOps pour l’IA agentic. Les agents génèrent des coûts imprévisibles — branching, retries, tool calls, multi-agent loops. Tu intégres les contrôles de coût avant que les agents passent en prod, pas après le premier bill shock.
Les Golden Paths : le concept qui tue
C’est le concept le plus important du Platform Engineering.
Ce qu’un golden path n’est PAS
- Une contrainte obligatoire
- Une checklist de compliance
- Un formulaire de ticket
- Un document Confluence
Ce qu’un golden path EST
Le chemin le plus rapide et le plus sûr de “j’ai une idée” à “c’est en production avec CI/CD, monitoring et infra”.
Spotify le dit bien : “If you are an adventurer you can of course leave the Golden Path and do your own thing, but then you will not have the same support.”
C’est un choix, pas une obligation. La différence est cruciale.
Ce qu’un golden path inclut
Un bon golden path, c’est un one-click-to-production :
- Service scaffold generator — CLI ou UI qui génère le repo complet : Dockerfile, CI/CD, observabilité, security
- Deployment configuration — Manifestes K8s, Helm charts, ou modules Terraform pré-configurés
- Observability setup — Dashboards Grafana, logs, tracing auto-configurés
- Security defaults — Network policies, RBAC, secrets management
- Runbook template — Point de départ pour la doc opérationnelle
Le temps gagné
AVANT (sans golden path) :
Créer un nouveau service = 1-3 jours de copy-paste et de tribal knowledge
APRÈS (avec golden path) :
Créer un nouveau service = 5 champs à remplir = 12 minutes
C’est pas une blague. Netflix fait ça. Spotify fait ça. Et toi tu fais encore du copy-paste de Dockerfile ?
L’architecture concrète
┌─────────────────────────────────────────────────────────────┐
│ Developer Portal (UI) │
│ Backstage / Port / Cortex / custom │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────┐ ┌──────────────┐ ┌─────────────────┐ │
│ │ Golden │ │ Service │ │ Self-Service │ │
│ │ Paths │ │ Catalog │ │ APIs │ │
│ │ (templates) │ │ (ownership) │ │ (automation) │ │
│ └─────────────┘ └──────────────┘ └─────────────────┘ │
│ │
├─────────────────────────────────────────────────────────────┤
│ Orchestration Layer │
│ Terraform / Crossplane / ArgoCD / Backstage │
├─────────────────────────────────────────────────────────────┤
│ Infrastructure Layer │
│ Kubernetes / Cloud APIs / Databases / Kafka │
└─────────────────────────────────────────────────────────────┘
Le portail
Le portail est la porte d’entrée, pas le produit entier.
Backstage est de facto le standard. 3000+ adopteurs, CNCF, communauté massive. Mais c’est un framework, pas un produit. Sans équipe plateforme qui maintient les templates, enforce la discipline du catalogue, et gère les escape hatches, Backstage dégénère en wiki que personne ne fait confiance.
Les Self-Service APIs
Chaque action d’infrastructure doit être accessible en self-service.
AVANT :
Dev → JIRA Ticket → Ops (busy) → Wait 2-5 days → Done
APRÈS :
Dev → Backstage UI or CLI → Automation (Terraform/Crossplane) → 5 min
C’est la différence entre “je demande la permission” et “je fais”. Le self-service, c’est pas un bouton — c’est une capacité.
L’observabilité intégrée
Chaque service créé via la plateforme a l’observabilité par défaut :
- Métriques — Prometheus (JVM, HTTP, Kafka, DB)
- Logs — Loki (JSON structuré, correlation ID)
- Traces — OpenTelemetry (auto-instrumentation)
- Dashboards — Grafana (auto-générés, RED metrics, SLO)
Si ton golden path intègre pas l’observabilité automatiquement, c’est pas un golden path. C’est un template à moitié fini.
La gouvernance qui se code
Le principe
Les politiques de sécurité et compliance sont codifiées dans les templates et pipelines. Chaque service créé via la plateforme adhère aux critères — non pas parce que quelqu’un a vérifié, mais parce que la plateforme l’a enforcé structurellement.
Ce que ça donne concrètement
Un service créé via le golden path a automatiquement :
- Security scanning (dependencies, SAST, DAST)
- Network policies
- RBAC configuré
- Secrets management intégré
- Audit trail complet
- Compliance gates dans le pipeline
C’est pas “est-ce que tu as pensé à mettre un network policy ?”. Le network policy est là. Point.
Policy-as-Code
OPA ou Kyverno pour encoder les règles :
- Approbation requise pour les infrastructures critiques
- Blast-radius policy (limiter les changements dangereux)
- Cost guardrails (prévenir les dépassements)
- Compliance rules (GDPR, SOC2, HIPAA)
La gouvernance ne scale pas avec des humains. Elle scale avec du code.
L’équipe plateforme
La topologie
Selon Team Topologies (Skelton & Pais), l’équipe plateforme est une équipe de plateforme qui interagit avec les équipes stream-aligned en mode X-as-a-Service.
C’est pas une équipe DevOps rebrandée. C’est une équipe avec un Product Manager, un roadmap, des métriques d’adoption, et un NPS score.
La composition
- Platform Engineers — Infra, K8s, Terraform, CI/CD
- Developer Experience Engineers — Logiciel, tooling, CLI, Backstage
- Product Manager — Roadmap, feedback, adoption
- Technical Writer — Documentation des golden paths
Les responsabilités
- Propriétaire de l’IDP, des golden paths, du portail
- Fournisseur de self-service
- Mainteneur basé sur les retours développeurs
- Mesure l’adoption et l’expérience
L’équipe plateforme n’est pas une équipe support. Elle ne prend pas de tickets. Elle construit des capacités. C’est la différence fondamentale.
Comment mesurer que ça marche
DORA Metrics
| Métrique | Cible |
|---|---|
| Lead Time for Changes | < 1 jour |
| Deployment Frequency | Quotidien |
| Change Failure Rate | < 5% |
| MTTR | < 1 heure |
Métriques plateforme
| Métrique | Cible |
|---|---|
| Golden Path Adoption Rate | > 70% |
| Self-Service Ratio | > 80% |
| Time to First Deploy | < 4 heures |
| Onboarding Time | < 5 jours |
| Platform NPS | > 40 |
Si ces chiffres bougent pas, ta plateforme sert à rien. Point.
Les erreurs qui tuent
Erreur n°1 : Overengineering dès le départ
Construire une plateforme à 5 couches avant de valider que les devs l’utiliseront.
La solution : Un seul golden path. Une seule équipe. Ship it. Iterate.
Erreur n°2 : Enforcer avant d’être prêt
Mandater l’adoption de golden paths immatures. C’est le meilleur moyen de générer de la résistance et de l’infrastructure en shadow.
La solution : Le path doit être mature et démontrable meilleur avant de devenir obligatoire. L’adoption par l’ergonomie dure. L’adoption par le mandat, ça fait du resentment.
Erreur n°3 : Golden paths sans escape hatches
Des paths si opinionnés qu’ils sont inutilisables pour les cas non standards.
La solution : La déviation est explicite mais possible. Le CNCF exige que les plateformes soient “optional and composable”.
Spotify le dit : “If you are an adventurer you can of course leave the Golden Path”. Laisse les gens être des aventuriers.
Erreur n°4 : Ignorer la documentation
Le meilleur outil du monde sans docs = un outil inutilisé.
Docs minimales :
- Getting Started (5 min)
- Golden Paths — un guide par template
- FAQ — les 20 questions fréquentes
- Troubleshooting — les 10 erreurs courantes
- ADR — pourquoi ces choix
Erreur n°5 : Confondre portail et plateforme
Investir dans un portail magnifique sans automatisation derrière.
La solution : Le portail est un shell fin. Backstage n’est efficace que câblé à de vraies capacités. Un portail sans execution IDP, c’est un GPS sans voiture.
La stack technique recommandée
Portal
| Outil | Modèle | Forces |
|---|---|---|
| Backstage | OSS (CNCF) | Gratuit, plugins, communauté |
| Port | SaaS | Démarrage rapide |
| Cortex | SaaS | Service Scorecards |
Mon choix : Backstage. CNCF, communauté massive, 3000+ adopteurs. Netflix, Spotify, American Airlines, LEGO l’utilisent.
Infrastructure
| Composant | Choix |
|---|---|
| IaC | Terraform / OpenTofu |
| K8s Provisioning | Crossplane |
| GitOps | ArgoCD |
| CI/CD | GitLab CI / GitHub Actions |
| Policy Engine | OPA / Kyverno |
Observabilité
| Composant | Choix |
|---|---|
| Métriques | Prometheus |
| Logs | Loki |
| Traces | Tempo |
| Dashboards | Grafana |
C’est la stack CNCF standard. Pas de réinvention de la roue.
Roadmap en 4 phases
Phase 1 (Mois 1-2) : Audit & Quick Wins
- Survey des devs sur les douleurs
- Mesurer le volume de tickets
- Identifier les 3 workflows les plus douloureux
- Installer Backstage avec SSO
- Premier golden path : “Hello World to Production”
- 3 early adopters
Phase 2 (Mois 3-6) : Premier Golden Path
- Template : nouveau service
- Intégration CI/CD
- Self-service Kafka, databases
- 10 services migrés
Phase 3 (Mois 6-12) : Self-Service V1
- Self-service pour les 3 ressources les plus demandées
- Scorecards
- OPA policies intégrées
- Crossplane Claims pour les bases de données
Phase 4 (Mois 12+) : Expand
- Deuxième golden path
- Observabilité par défaut
- Security scanning
- Cost management
- SLOs plateforme
L’IA change la donne
Agent Experience (AX)
Gartner 2026 introduit l’Agent Experience : préparer les systèmes backend pour servir des agents IA.
Les golden paths doivent servir humains ET agents. Les APIs doivent être machine-readable. La gouvernance doit gérer des acteurs non-humains.
C’est pas demain. C’est maintenant.
FinOps pour l’IA Agentic
Les workloads IA génèrent des coûts imprévisibles. Branching, retries, tool calls, multi-agent loops. Tu intègres les contrôles de coût dans la plateforme avant que les agents passent en prod.
Pas après le premier bill de 50K$ qui te fait un arrêt cardiaque.
Le seuil de viabilité
Petit aparté honnête : si tu as 10 développeurs, construire une IDP c’est du Gartner cosplay. La réponse honnête à cette taille, c’est un monorepo, un Makefile, et un README.
Le seuil où une équipe plateforme dédiée devient rentable, c’est autour de 50-80 ingénieurs. En dessous, des templates CI/CD standardisés et quelques scripts self-service suffisent.
Ne construis pas une autoroute pour une route de campagne.
Mot de la fin
Platform Engineering 2.0, c’est pas un outil. C’est pas Backstage. C’est pas un portail.
C’est une manière de penser où :
- Les golden paths sont des workflows exécutables, pas des docs
- Le self-service est une capacité réelle, pas un bouton qui ouvre un ticket
- La gouvernance est encodée dans l’infrastructure, pas dans des PDF
- La plateforme est un produit avec des utilisateurs, un roadmap, et des métriques
Commence par un seul golden path. Celui qui résout le problème le plus douloureux. Mesure l’adoption. Et surtout : traite tes développeurs comme des clients, pas comme des consommateurs de tickets.
L’essayer c’est l’adopter. Et si ça marche pas, au moins tu auras appris quelque chose. C’est toujours mieux que de construire un portail magnifique que personne utilise.
See ya space-cowboy!