Golden Paths et Developer Experience

Dans le chapitre précédent, on a vu Internal Developer Platform : Backstage et Port. Maintenant on passe à la vitesse supérieure.

Dans une organisation de 50, 100 ou 500 développeurs, chacun finit par inventer sa propre façon de déployer un service. Dockerfile artisanal ici, script bash maison là, ticket Jira de 3 semaines pour obtenir un namespace Kubernetes ailleurs. Le résultat : une jungle de processus incompatibles, une charge cognitive explosive, et des équipes Ops submergées de tickets récurrents.

Les Golden Paths répondent à ce chaos. Ce sont des chemins balisés, optimisés et maintenus par la platform team, qui permettent à n’importe quel développeur de passer du code au déploiement en quelques minutes — sans réinventer la roue à chaque fois. Combinés à une vraie mesure de la Developer Experience, ils transforment l’Internal Developer Platform d’un outil technique en un produit qui accélère réellement les équipes.

Humanitec — L’orchestration par abstraction

Là où Backstage et Port fournissent un portail, Humanitec prend une approche fondamentalement différente : c’est un Platform Orchestrator. Son rôle n’est pas de présenter un catalogue, mais de résoudre dynamiquement les dépendances infrastructure de chaque workload selon l’environnement cible.

Le concept central est Score, un format déclaratif qui décrit ce dont un service a besoin sans spécifier comment le provisionner. Le développeur déclare “j’ai besoin d’une base PostgreSQL et d’un cache Redis”, et Humanitec se charge de mapper ça vers la bonne implémentation.

Voici un fichier Score typique pour un service de paiement :

# score.yaml — Description abstraite du workload
apiVersion: score.dev/v1b1
metadata:
  name: payment-service

containers:
  main:
    image: .
    variables:
      DB_HOST: ${resources.db.host}
      DB_PORT: ${resources.db.port}
      DB_NAME: ${resources.db.name}
      CACHE_URL: ${resources.cache.url}

resources:
  db:
    type: postgres
  cache:
    type: redis
  dns:
    type: dns

service:
  ports:
    www:
      port: 8080
      targetPort: 8080

Le développeur ne mentionne ni Helm, ni Terraform, ni RDS. Il déclare ses besoins. La magie opère côté plateforme grâce aux Resource Definitions — des règles qui mappent chaque type de ressource vers une implémentation concrète selon l’environnement.

En dev, type: postgres déclenche un Helm chart pour un PostgreSQL in-cluster (coût : ~0$). En production, la même déclaration provisionne une instance RDS Multi-AZ via Terraform (coût : ~200$/mois). Même fichier Score, deux réalités infra totalement différentes :

# Resource Definition — PostgreSQL en dev (in-cluster via Terraform)
apiVersion: entity.humanitec.io/v1b1
kind: Definition
metadata:
  id: postgres-dev
criteria:
  - env_type: development
type: postgres
driver_type: humanitec/terraform
driver_inputs:
  values:
    source:
      path: modules/postgres-in-cluster
    variables:
      db_name: ${context.res.id}
      namespace: ${context.app.id}-${context.env.id}

🔥 Cas réel : Chez un client fintech, l’adoption de Score a réduit le temps moyen de provisioning d’un nouvel environnement de 3 jours à 12 minutes. Les développeurs ne créent plus de tickets infra — ils pushent un score.yaml et l’environnement existe.

💡 Tip DevOps : Score est open-source et utilisable indépendamment de Humanitec. Tu peux commencer avec score-compose pour générer des docker-compose.yaml à partir de fichiers Score, sans engagement commercial.

Golden Paths — Guider sans contraindre

Un Golden Path est un chemin pré-défini et recommandé pour accomplir une tâche courante de développement. Attention au mot clé : recommandé, pas imposé. Si tu forces les devs à suivre un chemin unique, ils le contourneront. Si tu leur proposes un chemin qui leur fait gagner du temps, ils l’adopteront naturellement.

Sans Golden Path, voici ce qui se passe dans une organisation typique : le dev A fabrique un Dockerfile custom et déploie via Jenkins sur une VM, le dev B utilise des Buildpacks avec GitHub Actions vers Kubernetes, le dev C bricolé un docker-compose avec rsync sur du bare metal, et le dev D attend 3 semaines qu’un ticket Ops soit traité. Quatre chemins différents, quatre sets de compétences requis, quatre surfaces de maintenance.

Avec un Golden Path, les quatre devs utilisent le même template, le même pipeline GitHub Actions, le même déploiement ArgoCD vers Kubernetes. Résultat : 5 minutes au lieu de 3 semaines, et un seul chemin à maintenir.

Concrètement, un Golden Path “Nouveau Microservice” enchaîne automatiquement ces étapes : scaffold du repo via un template Backstage/Port, pipeline CI/CD pré-configuré (lint, test, build, scan de vulnérabilités, push vers le registry), déploiement en dev via ArgoCD, monitoring Prometheus + dashboard Grafana, et enregistrement dans le service catalog. Tout ça déclenché par un seul clic dans le portail.

Voici comment formaliser un Golden Path sous forme de définition structurée :

# golden-path-definition.yaml
name: "Microservice Python"
description: "Crée un microservice Python avec FastAPI"
maturity: stable
owner: platform-team

prerequisites:
  - Accès GitHub org
  - Namespace Kubernetes assigné

steps:
  - name: "Scaffold"
    tool: backstage-scaffolder
    template: fastapi-microservice
    outputs: [github-repo, catalog-entry]

  - name: "CI Pipeline"
    tool: github-actions
    workflow: python-ci.yml
    includes: [lint (ruff), test (pytest), build (docker), scan (trivy), push (ECR)]

  - name: "CD Pipeline"
    tool: argocd
    config:
      sync-policy: automated
      self-heal: true
      prune: true

  - name: "Observability"
    tool: prometheus-operator
    config: [ServiceMonitor, PrometheusRule, GrafanaDashboard]

guardrails:
  - max-container-cpu: "2"
  - max-container-memory: "4Gi"
  - required-labels: [app.kubernetes.io/name, app.kubernetes.io/owner]
  - required-annotations:
      prometheus.io/scrape: "true"

Remarque la section guardrails : c’est là que la platform team encode les bonnes pratiques de l’organisation sans bloquer les développeurs. Les labels sont obligatoires, les limites de ressources sont cadrées, mais le choix du framework, du langage ou de la logique métier reste entièrement libre.

⚠️ Attention : Un Golden Path doit couvrir 80% des cas d’usage. Si un dev a besoin de sortir du chemin pour un cas légitime, il doit pouvoir le faire. Si plus de 20% des devs sortent du chemin, c’est le Golden Path qui est mal conçu, pas les devs qui ont tort.

Mesurer la Developer Experience avec SPACE

Impossible d’améliorer ce qu’on ne mesure pas. Le framework SPACE, créé conjointement par GitHub, Microsoft Research et l’Université de Victoria, propose cinq dimensions pour évaluer la productivité développeur de manière holistique.

• S — Satisfaction & Well-being : les devs sont-ils contents de leurs outils et processus ? Mesuré par des surveys NPS et des index de burnout.
• P — Performance : la qualité du code livré. Fiabilité en production, densité de bugs, respect des SLOs.
• A — Activity : commits, PRs, déploiements. Utile comme indicateur secondaire, mais jamais comme métrique principale — sinon tu incites au commit-padding.
• C — Communication & Collaboration : temps de review des PRs, partage de connaissances, documentation.
• E — Efficiency & Flow : time-to-first-deploy, lead time, fréquence des blocages inter-équipes.

🧠 À retenir : SPACE insiste sur le fait qu’aucune dimension seule ne suffit. Une équipe peut avoir une activité élevée (beaucoup de commits) mais une satisfaction catastrophique (burnout). Mesure toujours au moins 3 dimensions sur 5.

Pour ton IDP, voici les métriques concrètes à tracker avec leurs objectifs :

# Métriques DevX — Baseline vs Objectif IDP
metriques:
  time_to_first_deploy:
    avant: "2-4 semaines"
    objectif: "< 1 jour"
  onboarding_nouveau_dev:
    avant: "1-2 semaines"
    objectif: "< 2 jours"
  provisioning_environnement:
    avant: "Jours"
    objectif: "Minutes"
  tickets_ops_par_dev_par_mois:
    avant: "15-20"
    objectif: "< 5"
  satisfaction_developpeur:
    avant: "5/10"
    objectif: "> 8/10"
  services_dans_catalog:
    avant: "0%"
    objectif: "> 95%"
  mttr:
    avant: "Heures"
    objectif: "Minutes"

La mise en place d’enquêtes DevX trimestrielles est indispensable. Chaque question doit être liée à une métrique actionnable : “Combien d’outils différents utilises-tu pour déployer un changement ?” mesure la charge cognitive, “Peux-tu déployer en production de manière autonome ?” mesure le self-service réel.

🔥 Cas réel : Spotify a inventé le concept de “Golden Path” justement pour répondre aux résultats de leurs enquêtes DevX internes. Les développeurs ne se plaignaient pas des outils — ils se plaignaient de ne pas savoir quel outil utiliser parmi la dizaine disponible.

Construire ton IDP — Les 4 phases

La construction d’une Internal Developer Platform n’est pas un projet avec une date de fin. C’est un produit avec une roadmap, un backlog, et des utilisateurs (les développeurs). Voici les quatre phases de maturité.

Phase 1 — Découverte (Semaines 1-4) : Interviews des développeurs, mapping des workflows actuels du commit à la production, inventaire des outils existants, mesure des baselines. Cette phase est critique — si tu construis une IDP qui ne résout pas les vrais pain points, personne ne l’utilisera.

Phase 2 — MVP (Semaines 5-12) : Commence petit. Un portail (Backstage si >50 devs, Port si <50), 2-3 Golden Paths maximum (microservice, frontend SPA, cron job), et du self-service basique (database, cache Redis, bucket S3). Pas plus.

# Checklist MVP — Ne lance PAS la Phase 3 sans cocher tout ça
# ✅ Au moins 2 Golden Paths fonctionnels
# ✅ Self-service pour les 3 ressources les plus demandées
# ✅ Catalog avec >80% des services existants
# ✅ Pipeline CI/CD standardisé et testé
# ✅ Documentation utilisateur complète
# ✅ Au moins 5 early adopters qui utilisent la plateforme quotidiennement

Phase 3 — Adoption (Semaines 13-24) : C’est le vrai défi. Les stratégies qui marchent : un programme de champions (2-3 devs enthousiastes par équipe), une migration progressive service par service, une documentation irréprochable (si un dev doit chercher sur Slack, c’est un échec), et des feedback loops toutes les 2 semaines.

Phase 4 — Scale (6 mois+) : Métriques avancées, A/B testing des Golden Paths, recommandations automatiques, optimisation proactive. C’est le niveau où l’IDP commence à anticiper les besoins plutôt que d’y répondre.

💡 Tip DevOps : Le modèle de maturité va de Level 0 (Tribal Knowledge — documentation orale et processus ad-hoc) à Level 4 (Intelligent — recommandations automatiques et optimisation proactive). La plupart des organisations qui réussissent leur IDP atteignent le Level 2 (Self-service) en 6 mois. Ne vise pas le Level 4 dès le départ.

Bonnes pratiques et pièges à éviter

Ce qui fonctionne :

• Traiter l’IDP comme un produit interne avec un vrai product owner
• Commencer par les pain points les plus douloureux (souvent le provisioning d’environnements)
• Mesurer la satisfaction développeur avant et après chaque feature
• Rendre les Golden Paths optionnels mais tellement pratiques qu’ils deviennent le choix naturel
• Documenter les décisions d’architecture (ADR) derrière chaque choix de la plateforme

Ce qui échoue :

• Construire une IDP en dessous de 10-15 développeurs (overkill)
• Tout construire from scratch au lieu de composer des solutions existantes
• Forcer l’adoption sans démontrer la valeur
• Mesurer l’activité (commits, PRs) comme métrique principale de productivité
• Ignorer le feedback des utilisateurs après le lancement

⚠️ Attention : L’erreur la plus fréquente est le “build trap” — l’équipe plateforme qui passe 6 mois à construire un outil parfait que personne n’utilise. Lance un MVP en 8 semaines maximum, mets-le dans les mains de vrais devs, et itère.

Résumé

Les Golden Paths transforment le chaos de déploiement en chemins balisés qui accélèrent tous les développeurs sans les contraindre. Humanitec et son format Score apportent l’abstraction d’infrastructure nécessaire pour que le même fichier déclaratif fonctionne du laptop à la production. Le framework SPACE donne les outils pour mesurer la Developer Experience de manière holistique, au-delà des simples métriques d’activité.

🧠 À retenir : Une IDP réussie se construit en 4 phases (Découverte → MVP → Adoption → Scale), se traite comme un produit interne, et se mesure par la satisfaction développeur — pas par le nombre de features de la plateforme. Commence petit, mesure tout, itère vite.

Prochain cours : On attaque le FinOps avec Kubecost — comment optimiser tes coûts cloud sans sacrifier la performance, avec du right-sizing et des stratégies de spot instances.