Platform Engineering : construire un IDP qui tient ses promesses

Pourquoi l'IDP est devenu incontournable

En 2024, le rapport State of DevOps de Puppet plaçait Platform Engineering parmi les trois priorités d'investissement des organisations tech matures. La raison est simple : la complexité accumulée depuis l'ère Kubernetes a transformé chaque développeur en demi-SRE. Un dev qui passe 30 % de son temps à débugger des pipelines GitLab, à comprendre les CRD Argo ou à chercher quel cluster héberge son service ne livre pas de valeur métier.

Une Internal Developer Platform (IDP) bien conçue inverse la tendance : elle expose des golden paths — des chemins préconçus, documentés, instrumentés — qui couvrent 80 % des cas d'usage sans imposer de cognitive load supplémentaire.

Ce qu'une IDP n'est pas

Avant d'aller plus loin, écartons trois confusions fréquentes :

• Une IDP n'est pas un wiki Confluence amélioré. Si votre portail se contente d'agréger des liens, vous avez un catalogue, pas une plateforme.
• Une IDP n'est pas une couche d'abstraction sur Kubernetes. Elle peut l'inclure, mais son périmètre est plus large : bases de données, secrets, observabilité, conformité.
• Une IDP n'est pas un projet, c'est un produit. Avec roadmap, utilisateurs internes, NPS et SLA.

L'architecture type d'une IDP en 2025

Le pattern qui s'impose combine quatre briques :

| Couche | Rôle | Outils typiques | |---|---|---| | Portail dev | Point d'entrée unique, catalogue de services | Backstage, Port, Cortex | | Orchestration | Provisionner ressources et environnements | Crossplane, Humanitec, Kratix | | Delivery | Pipelines standardisés | Argo CD, Flux, GitHub Actions | | Observabilité | Métriques, logs, traces unifiés | Grafana, OpenTelemetry, Pyrra |

Backstage reste la référence open source côté portail, avec plus de 1 800 contributeurs et une adoption confirmée chez Spotify (à l'origine du projet), American Airlines ou Expedia.

Concrètement : un golden path avec Backstage

Un golden path se matérialise souvent par un Software Template. Voici un extrait simplifié pour scaffolder un service Go avec pipeline CI, manifest Helm et dashboard Grafana préprovisionné :

apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
  name: go-microservice-v2
  title: Microservice Go (golden path)
  tags: [recommended, go, kubernetes]
spec:
  owner: platform-team
  type: service
  parameters:
    - title: Identité du service
      required: [name, owner]
      properties:
        name:
          type: string
          pattern: '^[a-z0-9-]+$'
        owner:
          type: string
          ui:field: OwnerPicker
  steps:
    - id: fetch
      action: fetch:template
      input:
        url: ./skeleton
        values:
          name: ${{ parameters.name }}
    - id: publish
      action: publish:github
      input:
        repoUrl: github.com?repo=${{ parameters.name }}&owner=acme
    - id: register
      action: catalog:register
      input:
        repoContentsUrl: ${{ steps.publish.output.repoContentsUrl }}

En moins de cinq minutes, le développeur obtient un dépôt fonctionnel, branché sur le catalogue, conforme aux standards de sécurité et déjà observable. C'est ça, la promesse d'un golden path.

Mesurer la DevEx, pas seulement la vélocité

L'erreur classique consiste à mesurer le succès de la plateforme via le nombre de déploiements. Le framework SPACE (Forsgren et al.) ou le plus récent DevEx framework (Noda et al., 2023) proposent une approche plus honnête. À combiner avec les métriques DORA :

• Flow : temps entre l'idée et la mise en production
• Feedback loops : latence des tests, du CI, des reviews
• Cognitive load : nombre de systèmes qu'un dev doit comprendre pour livrer

Un signal concret : si vos devs ouvrent encore des tickets Jira à l'équipe plateforme pour créer une base PostgreSQL, votre cognitive load est trop élevé. L'objectif est le self-service avec garde-fous, pas le ticket-driven development.

Checklist de maturité d'une IDP

• [ ] Un catalogue de services à jour automatiquement (via discovery, pas saisie manuelle)
• [ ] Au moins trois golden paths couvrant 70 % des nouveaux services créés
• [ ] Provisioning self-service des dépendances (DB, cache, queue) en moins de 10 minutes
• [ ] Politique-as-code (OPA, Kyverno) appliquée par défaut, pas par audit a posteriori
• [ ] Métriques DORA + DevEx publiées trimestriellement à l'équipe plateforme
• [ ] Backlog plateforme alimenté par des interviews utilisateurs, pas par les seuls SRE
• [ ] Documentation versionnée à côté du code (TechDocs ou équivalent)

Si vous cochez moins de quatre cases, votre IDP est probablement encore un projet d'infrastructure déguisé.

Les pièges à éviter

1. Construire avant d'écouter. Trop d'équipes plateforme livrent un Backstage vide pendant six mois. Commencez par un golden path, un seul, et itérez.
2. Sur-abstraire. Une IDP qui cache complètement Kubernetes empêche les seniors de débugger. Préférez des abstractions opt-out.
3. Confondre standardisation et uniformisation. Un golden path n'est pas une obligation, c'est l'option par défaut la plus simple.
4. Oublier le coût. Une équipe plateforme coûte cher. Justifiez son ROI via le temps gagné × nombre de devs servis.

À retenir

• Une IDP est un produit interne avec utilisateurs, roadmap et métriques de satisfaction, pas un projet infra ponctuel.
• Les golden paths matérialisent la valeur : un template Backstage qui scaffolde un service complet en cinq minutes vaut mieux qu'un wiki de 200 pages.
• Mesurez la DevEx (cognitive load, feedback loops) en parallèle des métriques DORA.
• Privilégiez les abstractions opt-out : ne cachez pas Kubernetes, simplifiez son usage par défaut.
• Démarrez petit : un golden path adopté vaut mieux que dix templates ignorés.