Internal Developer Platform : Backstage et Port

“On a adopté DevOps, mais les développeurs passent 40% de leur temps à configurer l’infrastructure au lieu d’écrire du code métier.” Ce constat, partagé par des centaines d’organisations, a donné naissance au Platform Engineering — la discipline qui construit des couches d’abstraction self-service au-dessus de Kubernetes, Terraform et les pipelines CI/CD. L’outil central de cette approche est l’Internal Developer Platform (IDP), un portail qui permet aux développeurs de provisionner, déployer et monitorer leurs applications sans comprendre toute la stack sous-jacente. Ce cours t’emmène dans l’implémentation concrète avec les deux outils de référence : Backstage (Spotify/CNCF) et Port (SaaS).

Pourquoi le Platform Engineering est devenu incontournable

DevOps a résolu le silo entre Dev et Ops. Mais il a créé un nouveau problème : la charge cognitive. Un développeur en 2026 doit potentiellement maîtriser son langage, Docker, Kubernetes, Terraform, les pipelines CI/CD, le monitoring, la sécurité, les Network Policies… C’est trop pour une seule personne.

L’évolution est claire : des Ops traditionnels (tickets, silos) → DevOps (tout le monde fait tout) → Platform Engineering (une équipe plateforme construit les abstractions, les développeurs les consomment en self-service). Le Platform Engineering ne remplace pas DevOps — il le scale.

L’IDP repose sur 5 piliers : un Service Catalog (inventaire de tous les composants et leurs propriétaires), le Self-service (provisioning autonome via templates), les Golden Paths (chemins pré-validés pour les cas courants), la Documentation intégrée, et l’Observabilité centralisée.

🧠 À retenir : Le CNCF a formalisé l’architecture d’une IDP en 5 plans : Developer Control Plane (portail, CLI), Integration & Delivery Plane (CI/CD, GitOps), Resource Control Plane (Crossplane, Terraform), Monitoring & Logging Plane (Prometheus, Grafana), et Security Plane (RBAC, OPA, scanning). Cette architecture en couches permet de construire l’IDP progressivement.

🔥 Cas réel : Spotify a créé Backstage en interne parce que ses 2000+ ingénieurs passaient un temps déraisonnable à chercher “qui possède ce service ?”, “où est la doc ?”, “comment je déploie ça ?”. Après l’adoption de Backstage, le temps d’onboarding d’un nouveau développeur est passé de 60 jours à 20 jours. C’est ça, le ROI d’une IDP.

Backstage : le Software Catalog et les Templates

Backstage est un framework open-source (CNCF Incubating) pour construire ton Developer Portal. Son architecture repose sur un frontend React, un backend Node.js/Express, une base PostgreSQL, et un système de plugins extensible.

Le Software Catalog est le cœur de Backstage. Il répertorie tous tes composants — services, librairies, pipelines, bases de données — via des fichiers catalog-info.yaml placés à la racine de chaque repo :

# catalog-info.yaml — déclaration d'un service dans le catalogue
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: payment-service
  description: Service de paiement principal
  annotations:
    github.com/project-slug: myorg/payment-service
    backstage.io/techdocs-ref: dir:.
  tags: [python, fastapi, production]
  links:
    - url: https://grafana.internal/d/payment
      title: Dashboard Grafana
spec:
  type: service
  lifecycle: production
  owner: team-payments
  system: checkout
  dependsOn:
    - resource:default/postgres-payments
    - component:default/user-service
  providesApis:
    - payment-api

Le Scaffolder (Software Templates) est le composant self-service. Il permet aux développeurs de créer de nouveaux projets en quelques clics via des templates définis par l’équipe plateforme — avec le repo Git, le pipeline CI/CD, le Dockerfile, le monitoring et l’enregistrement au catalogue, tout pré-configuré :

# template.yaml — Template pour un nouveau microservice
apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
  name: fastapi-microservice
  title: FastAPI Microservice
  description: Microservice FastAPI avec CI/CD, monitoring et K8s
  tags: [python, fastapi, recommended]
spec:
  owner: platform-team
  type: service
  parameters:
    - title: Informations du service
      required: [name, owner]
      properties:
        name:
          title: Nom du service
          type: string
          pattern: '^[a-z][a-z0-9-]*$'
        owner:
          title: Équipe propriétaire
          type: string
          ui:field: OwnerPicker
        database:
          title: Base de données
          type: string
          enum: ['none', 'postgresql', 'mongodb']
          default: 'none'
  steps:
    - id: fetch-template
      name: Génération du code
      action: fetch:template
      input:
        url: ./skeleton
        values:
          name: ${{ parameters.name }}
          owner: ${{ parameters.owner }}
    - id: publish
      name: Publication du repo
      action: publish:github
      input:
        repoUrl: github.com?owner=myorg&repo=${{ parameters.name }}
        repoVisibility: internal
    - id: register
      name: Enregistrement dans le catalog
      action: catalog:register
      input:
        repoContentsUrl: ${{ steps.publish.output.repoContentsUrl }}
        catalogInfoPath: '/catalog-info.yaml'

TechDocs complète le trio en intégrant la documentation technique (MkDocs) directement dans le portail. La doc vit à côté du code et se génère automatiquement — fini les wikis Confluence qui divergent du code réel.

💡 Tip DevOps : Commence Backstage par le Software Catalog seul. Importe tes services existants, établis les relations de dépendance, identifie les propriétaires. Cet exercice de cartographie a déjà une valeur énorme — tu vas découvrir des services orphelins, des dépendances inconnues et des docs manquantes. Ajoute les Templates et TechDocs dans un second temps.

Port : l’alternative SaaS

Port est une solution SaaS qui offre les mêmes fonctionnalités qu’un Developer Portal — catalogue, self-service, scorecards — sans avoir à gérer l’infrastructure Backstage. Son approche est plus opinionée et plus rapide à mettre en place.

Le modèle de données de Port s’organise autour de Blueprints (schémas qui définissent tes entités) et de Self-service Actions qui déclenchent des workflows GitHub Actions, GitLab CI ou webhooks :

{
  "identifier": "microservice",
  "title": "Microservice",
  "schema": {
    "properties": {
      "language": {
        "type": "string",
        "enum": ["Python", "Go", "Node.js", "Java"]
      },
      "tier": {
        "type": "string",
        "enum": ["critical", "standard", "internal"]
      },
      "on_call": { "type": "string", "format": "user" },
      "grafana_url": { "type": "string", "format": "url" }
    }
  },
  "relations": {
    "environment": { "target": "environment", "many": true },
    "team": { "target": "team", "required": true }
  }
}

Le choix entre Backstage et Port dépend de ton contexte :

• Backstage : open-source, très customisable, grande communauté de plugins, mais maintenance lourde (il faut des développeurs React/Node dans l’équipe plateforme)
• Port : SaaS managé, rapide à déployer, UI drag & drop, self-service no-code, mais vendor lock-in et coût par utilisateur

⚠️ Attention : Backstage est un framework, pas un produit fini. L’installer prend 5 minutes. Le rendre utile pour tes équipes prend des mois de développement de plugins, d’intégrations et de templates. Sous-estimer cet investissement est l’erreur numéro un des équipes plateforme.

Golden Paths et Developer Experience

Les Golden Paths sont des chemins pré-validés par l’équipe plateforme pour les cas d’usage courants. “Tu veux créer un nouveau microservice Python ? Utilise ce template, il inclut le Dockerfile optimisé, le pipeline CI, le monitoring Prometheus, les Network Policies, et le déploiement ArgoCD.” Le développeur n’a pas à réinventer la roue — et l’équipe plateforme garantit que les bonnes pratiques sont appliquées.

Les Golden Paths ne sont pas des contraintes rigides. Un développeur peut toujours sortir du chemin si son cas d’usage le nécessite. Mais 80% des cas sont couverts par les templates, et c’est là que le gain de productivité est massif.

Les métriques qui comptent pour mesurer l’impact de ton IDP :

# Métriques clés d'une IDP
developer_experience:
  onboarding_time: "Temps pour qu'un nouveau dev soit productif"
  time_to_first_deploy: "Du commit initial au premier déploiement prod"
  self_service_ratio: "% de provisioning sans ticket ops"
  cognitive_load_score: "Survey trimestriel auprès des développeurs"

platform_health:
  template_adoption: "% de nouveaux services créés via Golden Paths"
  catalog_coverage: "% de services enregistrés dans le catalogue"
  docs_freshness: "Âge moyen de la dernière mise à jour de docs"
  mttr_reduction: "Réduction du temps de résolution d'incidents"

🔥 Cas réel : Une entreprise fintech de 200 développeurs a mesuré que le provisioning d’un nouveau service prenait 5 jours (tickets Jira → équipe ops → config manuelle). Après l’implémentation de Backstage avec des Golden Paths, ce temps est passé à 15 minutes en self-service. Sur 50 nouveaux services par an, c’est 250 jours-homme récupérés — soit l’équivalent d’un développeur à temps plein pendant un an.

Bonnes pratiques et pièges à éviter

Comment réussir ton IDP :

• Traite ta plateforme comme un produit interne — avec des utilisateurs (les développeurs), des user stories, des feedbacks et des itérations
• Commence petit : catalogue + 1 template pour le cas d’usage le plus courant. N’essaie pas de tout abstraire d’un coup
• Mesure l’adoption et la satisfaction. Si les développeurs contournent ta plateforme, c’est qu’elle ne résout pas leur problème
• Les Golden Paths doivent être opinionated but escapable — des rails, pas des murs
• Documente le “pourquoi” de chaque choix d’architecture dans les templates

Les pièges classiques :

• Construire une IDP sans consulter les développeurs — c’est construire un produit sans écouter les utilisateurs
• Vouloir abstraire Kubernetes complètement — les développeurs doivent comprendre les concepts de base (pods, services, limites de ressources)
• Sous-estimer la maintenance de Backstage — les upgrades, les plugins qui cassent, les intégrations à maintenir
• Imposer la plateforme par la force au lieu de la vendre par la valeur

💡 Tip DevOps : Crée un canal Slack/Teams dédié à ta plateforme. Chaque question d’un développeur est un signal : soit ta doc est incomplète, soit ton abstraction est confuse, soit tu as un nouveau cas d’usage à couvrir. Les questions récurrentes deviennent des améliorations de la plateforme.

Résumé

Le Platform Engineering résout le problème de scaling de DevOps en construisant des abstractions self-service au-dessus de l’infrastructure. L’IDP, organisée en 5 piliers (catalogue, self-service, golden paths, docs, observabilité), est l’outil central de cette approche. Backstage (CNCF) est le framework open-source de référence — puissant et extensible mais exigeant en maintenance. Port offre une alternative SaaS rapide à déployer mais avec un vendor lock-in. Les Golden Paths sont le vrai levier de productivité : des chemins pré-validés qui couvrent 80% des cas d’usage et garantissent l’application des bonnes pratiques. La clé du succès : traiter la plateforme comme un produit, mesurer l’adoption, et itérer sur les feedbacks des développeurs.