Backstage et l'essor des portails développeurs internes (IDP)
Créé par Spotify puis confié à la CNCF, Backstage popularise le concept de portail développeur interne. Pourquoi le platform engineering change la donne.
Dans une grande organisation d'ingénierie, un développeur passe une part surprenante de son temps non pas à écrire du code, mais à chercher : où est la documentation de ce service ? qui en est propriétaire ? comment en créer un nouveau qui respecte tous les standards maison ? quelle version tourne en production ? Cette friction quotidienne — la charge cognitive — est l'ennemie silencieuse de la productivité. Le platform engineering est né pour la combattre, et Backstage en est devenu l'outil emblématique.
Qu'est-ce que Backstage ?
Backstage est un framework open source pour construire des portails développeurs (Internal Developer Portal, IDP). Il a été créé en interne par Spotify pour dompter la complexité de ses milliers de microservices, rendu open source en 2020, puis donné à la Cloud Native Computing Foundation (CNCF). Il est aujourd'hui un projet en incubation de la CNCF (sorti du Sandbox en 2022), adopté par des centaines d'entreprises.
L'idée directrice : offrir un guichet unique où toute l'ingénierie retrouve ses services, sa documentation, ses outils et ses standards — au même endroit, avec une expérience cohérente.
1. Le Software Catalog : remettre de l'ordre
Le cœur de Backstage est son Software Catalog : un inventaire vivant de tout ce que produit l'ingénierie — microservices, bibliothèques, pipelines de données, sites web, modèles de ML. Chaque entité est décrite par un fichier catalog-info.yaml versionné avec le code (approche « as code ») :
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
name: facturation-service
description: Service de facturation
annotations:
backstage.io/techdocs-ref: dir:.
spec:
type: service
owner: team-finance
lifecycle: production
dependsOn: [resource:postgres-facturation]Chaque composant a un propriétaire explicite (owner) et ses dépendances déclarées. Fini les services orphelins que personne n'ose toucher, et le fameux « qui est responsable de ça ? » lors d'un incident à 3h du matin.
2. Software Templates : les « golden paths »
Backstage propose des Software Templates : en quelques clics et un formulaire, un développeur génère un nouveau service déjà conforme — dépôt Git créé, pipeline CI/CD branché, monitoring, sécurité et conventions maison inclus. On parle de golden path : le chemin recommandé est aussi le plus simple à emprunter. C'est un renversement subtil mais puissant : au lieu d'imposer les bonnes pratiques par des documents que personne ne lit, on les rend plus faciles que les mauvaises.
3. TechDocs et les plugins
TechDocs applique le principe « docs like code » : la documentation vit à côté du code (en Markdown), est versionnée avec lui, et s'affiche directement dans le portail — donc elle reste à jour. Autour de ce socle, un écosystème de plugins intègre Kubernetes, les pipelines CI/CD, les alertes PagerDuty, les tableaux de bord — le tout dans une seule interface.
4. Platform Engineering : la plateforme comme produit
Backstage n'est qu'un outil ; l'idée de fond est plus importante. Le platform engineering consiste à traiter la plateforme interne comme un produit, et les développeurs comme ses clients. Une équipe plateforme dédiée réduit la charge cognitive des équipes produit en leur fournissant des abstractions self-service. Cette approche est théorisée dans le livre Team Topologies (Skelton & Pais), qui décrit les « platform teams » et les interactions « X-as-a-Service ».
Un bon platform engineering, c'est rendre le juste chemin évident et sans friction — pas ajouter une couche de bureaucratie.
Ce qu'il faut garder en tête
Backstage n'est pas magique. Son adoption demande un vrai investissement : il faut le déployer, l'alimenter, écrire des plugins, et surtout accompagner le changement culturel. Déployé sans stratégie produit, il devient un catalogue vide de plus. Mais bien mené, il matérialise une idée aujourd'hui incontournable : l'expérience développeur se conçoit, s'outille et se mesure (via des indicateurs de DevEx).